>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3493170. --> Reported by: [jibla](https://www.drupal.org/user/1013184) >>> <h2>Problem Statement</h2> <p>The <a href="https://spec.modelcontextprotocol.io/specification/basic/transports/">specification</a> itself requires a bi-directional communication protocol as the transport layer, with STDIO or SSE being the suggested options. Apparently, Drupal can't work with STDIO. Initially we tried to communicate with SSE, but that didn't work out well. So, we decided to divide the module into two parts: the first is mcp-server-drupal, written on top of the official MCP TypeScript SDK, and the second is the Drupal module itself. </p> <h2>Proposed Approach</h2> <p>One approach which come from @Edward Burton is to: </p> <blockquote><p>Initial thoughts would be to open connections for operations (both server and client can close connections and have sensible timeouts), so essentially we stream responses from the server on request (HTTP), which is pretty common architecture in most AI implementations right now.</p></blockquote> <p>I also directly copied part of the conversation from the Drupal Slack (<a href="https://drupal.slack.com/archives/CDL2YPBNX/p1732613088420149">link</a>), where @Edward Burton summarized the discussion of why this approach is attractive.</p> <blockquote><p>For me the initialization phase is simply loading an LLM manifest (which is how I see the MCP server), it shouldn't be expensive and for large scale implementations caching is the solution.</p> <p>The devil is in the detail and essentially what I'm proposing is to rebuild the whole MCP server as a Drupal module (a lot of work), of course we then have the complexity of managing things like caching, performance, standardized error handling as well as keeping in sync with Anthropic etc, but we gain deep native integration into the Drupal ecosystem (can make prompts/tools/resources plugins direct to Drupal entities).</p> <p>If the Drupal community saw value it is the kind of undertaking that could be very valuable to the ecosystem (Python/Typescript/ Drupal) but is definitely a complex and expensive undertaking...</p> <p>My only concern about using the contrib SDKs as middleware is that the architecture becomes convoluted and I fear it may put people off using it due to complicated setup/deployment/maintenance. If it is native in Drupal it is much harder work but far more attractive...</p></blockquote> <h2>Questions for Discussion</h2> <p>In this issue, we need to decide on one of the general and critical architectural aspects of the module. Should we use the &ldquo;mcp-drupal-server&rdquo; as a standalone binary that utilizes the official TypeScript SDK, or should Drupal itself be exposed as the MCP server?</p> > Related issue: [Issue #3493167](https://www.drupal.org/node/3493167)