Skip to main content

MCP

MCP is the surface for connecting Model Context Protocol servers — open-standard tool servers that expose capabilities (querying Notion, calling your internal admin panel, reading from a custom database, hitting Sentry, …) over a standard interface that AI Expedite agents can call alongside the built-in tools.

Once you connect an MCP server, every tool it exposes becomes available in the Available Actions drawer of the Agent Builder, so an agent can use it the same way it uses a terminal or a code-grep.

📷 Screenshot: MCP tab with one stdio server and one SSE server connected.

What you'll see​

The tab is a table of MCP servers connected to this workspace. Each row shows the server's name, transport, status (active / inactive), connection-pool size, and the action menu (refresh / edit / delete).

The table is empty by default — the platform doesn't ship pre-connected MCP servers.

Adding a server​

Click + Add MCP Server to open the form:

  • Name — workspace-scoped label (e.g. notion, internal-admin).
  • Description — free text; shown on the row and in the agent-builder action drawer.
  • Transport — stdio for a local-process server (the platform spawns it as a child process), or sse for a remote server reachable over HTTP with server-sent events.
  • Command + Args (stdio only) — the executable and its arguments. The form pre-fills sensible defaults (npx -y @modelcontextprotocol/server-filesystem /tmp); replace with whatever your server requires.
  • Server URL (sse only) — the HTTP endpoint your server is listening on.
  • Environment variables (stdio only) — JSON object with secrets and config the server needs at launch ({ "API_KEY": "...", "REGION": "us-east-1" }).
  • Status — active or inactive. Inactive servers stay in the table but agents can't see their tools.

Below those, the advanced controls:

  • Connection pool size (default 1) — how many concurrent connections to keep open. Bump this if multiple agents will hit the server in parallel.
  • Health check interval (default 60_000 ms) — how often the platform pings the server to confirm it's still up.
  • Timeout (default 30_000 ms) — per-request ceiling.
  • Retries (default 3) — how many times to retry a failed request before surfacing the error to the agent.

Save commits the server config to workspace/{workspaceID}/integrations/mcp/servers/{serverID} and the platform connects (or, for stdio, spawns) immediately.

Stdio vs SSE​

Two transports cover the common cases:

  • Stdio — best for self-hosted local tools where you trust the process and don't want a network hop. The platform launches the command as a child process on the host that owns this workspace's agent runtime, pipes JSON-RPC over stdin/stdout, and tears down the process when the workspace closes. Most of the official @modelcontextprotocol/server-* packages run this way.
  • SSE — best for remote tools, hosted services, or anything you don't want running inside the agent runtime. The platform makes HTTP requests with server-sent-event responses to the URL you configure.

Pick stdio for local file access, GitHub CLI wrappers, or in-house scripts. Pick SSE for a hosted Notion / Linear / Sentry integration, or anything behind your VPN that's already speaking MCP over HTTP.

Editing and removing​

The action menu on each row exposes:

  • Edit — re-opens the same form, pre-filled. Saving applies the change immediately; existing connections to the old config are torn down and re-established with the new one.
  • Refresh — force the platform to reconnect to the server right now (useful after you've redeployed it).
  • Delete — removes the server from the workspace. Any agents that referenced its tools will fail at runtime with a "tool not found" error until you either restore the connection or remove those tool references from the agent.

Per-tool control​

Every MCP server exposes one or more tools. Once a server is connected, the platform queries it for its tool list and surfaces those tools in the agent builder. You can choose to enable a server's tools wholesale, or pick specific tools to expose to specific agents — useful when an MCP server has a high-power surface (e.g. "delete table" alongside "list rows") and you only want agents to see the read-only subset.

Per-tool enable/disable lives on each agent's action configuration, not on the server row itself, so the same MCP server can be wide-open for one agent and tightly scoped for another in the same workspace.