Skip to content

MCP Persistent Connections#2346

Open
ngafar wants to merge 3 commits into
devfrom
feat/mcp-persistent-connections
Open

MCP Persistent Connections#2346
ngafar wants to merge 3 commits into
devfrom
feat/mcp-persistent-connections

Conversation

@ngafar

@ngafar ngafar commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator

Description

Every time the AI needed to know what MCP tools were available — or actually call one — the code would:

  1. Spawn a new subprocess (starting the MCP server from scratch)
  2. Do a handshake
  3. Ask "what tools do you have?"
  4. Do the work
  5. Kill the process

This happened on every single AI message that involved MCP tools.

The old approach meant each agent loop was paying subprocess startup cost plus a tools/list round-trip on top of that. With many tools across several servers, this adds up fast and makes the agent feel sluggish.

What we've done is the same basic idea as a database connection pool: you pay the setup cost once, then reuse the connection for the lifetime of the session.

Testing

  1. Visit the MCP settings page, and confirm you can still connect to servers.
  2. Have the Agent use and MCP server.
  3. Have the Agent use the same sever a second time.

In theory, multiple calls to the same MCP server should be faster, this is hard to test without proper benchmarks. However, the logic behind the persistent connections is sound.

Documentation

N/A - BTS changes


Note

Medium Risk
Changes how long-lived MCP child processes are managed; stale sessions, leaked subprocesses, or incorrect invalidation could affect agent tool calls until reconnect, though errors trigger eviction and delete clears the pool entry.

Overview
Replaces per-call MCP subprocess spawn with a persistent connection pool keyed by server_id, so listing tools and invoking tools reuse one stdio ClientSession instead of starting the server on every agent message.

MCPConnectionManager holds sessions, configs, per-server locks, and a cached tool list; failures and timeouts evict the session so the next call reconnects. Short-lived connections remain only when server_id is omitted (e.g. validating a new server on POST).

Call sites now pass server_id from the JupyterLab tool executor, MCP settings GET, and get_available_mcp_tools. Deleting an MCP server is async and invalidates the pooled connection for that id.

Reviewed by Cursor Bugbot for commit 151baa3. Configure here.

ngafar added 2 commits June 22, 2026 12:58
…g logic. Modified `list_server_tools` to accept `server_id` for session reuse, added `MCPConnectionManager` for managing persistent sessions, and updated relevant handlers to support these changes.
…troduced methods to get, set, and invalidate tool cache based on server_id, enhancing the tool listing logic in `list_server_tools` to utilize cached results when available.
@vercel

vercel Bot commented Jun 22, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
monorepo Ready Ready Preview, Comment Jun 22, 2026 5:32pm

Request Review

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 151baa3. Configure here.

Comment thread mito-ai/mito_ai/mcp/mcp_client.py Outdated
…eter. Modified MCPConnectionManager to invalidate tool cache based on session config, ensuring accurate tool listings when necessary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant