Allow Extensions to Register In-Process MCP Servers via In-Memory Transport

[m-paternostro]

Summary: Enable extensions to register in-process MCP servers via an in-memory transport, improving cohesion, performance, and security for tool-rich extensions.

---

With the recent announcement of full MCP spec support, it would be powerful and natural to allow extensions to register an MCP server implemented directly in the extension itself.

Currently:

• Extensions can register tools via the existing API, but this relies on a different programming model from MCP and requires static registration of tools in package.json.
• Extensions can register external MCP servers via registerMcpServerDefinitionProvider.

However, what’s missing is a way for extensions to be an MCP server — allowing the extension to implement and run a server directly in-process.

---

Why this matters

• Shared Context: Extensions often manage authentication, workspace state, and tool lifecycles. If the MCP server is implemented separately, coordination becomes complex and fragile.
  • Authentication is particularly interesting: an extension already using the AuthenticationProvider can seamlessly authenticate its own MCP server, ensuring that both parts are always in sync.
• Better Developer Experience: Development-oriented tools benefit from direct access to the development environment — the extension context is ideal.
• Matching the MCP Programming Model: The MCP SDK is server-first — extensions implementing an McpServer can simply connect it to a Transport. A natural mechanism to do this inside VS Code would be an InMemoryTransport.

---

Proposed Feature

• Expose a registerInMemoryMcpServer(transport: Transport): Disposable or equivalent API.
  • This would wire the in-memory server to VS Code’s internal MCP client.
  • No need to expose the full MCP SDK - with this design, just the Transport interface.
  • The server should be disconnected when the extension is deactivated
  • The returned Disposable would allow the extension to unregister the server as needed
    • This is useful to implement controls like "only enable the server if the user is signed in and have a specific scope"

---

Prior Art

• The official MCP SDK already includes an in-memory transport
• The transport interface is minimal and well-isolated.

---

Benefits:

• Enables rich extension-powered tooling via MCP without external processes.
• Allows seamless integration with existing auth and config inside the extension.
• Reduces the overhead of hybrid tool definitions (some in extension, some in MCP).
• Low implementation cost thanks to the existing MCP SDK transport abstraction.

It is worth noticing that an extension could today run an express server to expose a SSE/Streamable server and use the current APIs to register it. However, this approach is inefficient and potentially insecure, as it exposes internal development tools over networked interfaces unnecessarily.