[v3-beta] Integrate with MCP

[dlqqq]

Problem

The Model Context Protocol provides a standard interface for AI applications to access a set of externally-defined tools & context providers.

Proposed Solution

(NOTE: this is an early-stage proposal, so the plan may change. I will update this issue if that happens.)

• Add a new server extension (e.g. jupyter-ai-mcp) that provides a backend for registering MCP servers.

• Integrate this extension with jupyter-ai and allow personas to access tools.

• Build a UI for managing tool access available to each AI persona.

Open questions (research wanted!)

• How can we access LangChain model tool calls when they are integrated with MCP? The list of called tools is generally accessed from the tool_calls attribute, which only seems available on Anthropic models.

• What are some other features the MCP integration should support?

Additional context

• Helpful reference: https://wandb.ai/onlineinference/mcp/reports/The-Model-Context-Protocol-MCP-by-Anthropic-Origins-functionality-and-impact--VmlldzoxMTY5NDI4MQ

[dcieslak19973]

Selfishly, I would strongly suggest support for MCPs running SSE over HTTPS, including support for sending API Keys/Tokens/Secrets/Config in headers.

[dlqqq]

@dcieslak19973 We handle AI requests in the backend, so the server extension will make IPC calls to other MCP servers (or normal HTTPS calls for remote MCP servers). The server will reply via a secure Websocket, as usual.

To support MCPs over SSE & HTTPS, we would have to handle AI requests from the frontend. I don't think this is the direction we should pursue, since many of the most popular AI/agentic libraries are Python-only. What are your thoughts?

[dcieslak19973]

I would say the mix of MCP servers right now are about 40% Python, 40% TypeScript, 15% Docker and 5% HTTPS/SSE. Which begs the question, why am I advocating for the 5%? I think longer term, in corporate environments, running centralized/sanctioned MCPs over HTTPS will win out over having employees install their own local MCP, especially in environments where corporate IT places strict controls over what software employees may run on corporate hardware.

[dlqqq]

Yup, remote MCP server support is definitely being factored into our roadmap. It likely won't be using SSEs (as the requests can still be made from the backend instead of the frontend), but we will probably use HTTPS or some other equivalent to make RPCs.

[dcieslak19973]

Thanks; I think that covers my use case, and was maybe overly prescriptive in SSE support

[dcieslak19973]

Just one more thing, as I saw this issue with a separate MCP implementation - ensure that there is the ability to supply headers to the Streaming HTTP MCP; these are frequently used to supply authentication tokens / credentials to the backends that the MCP hits