Give Zed tools that are already a real backend.

Zed calls MCP servers context servers. Add the deployment there and its assistant can use your tools. The tools are your own interfaces — the same routes your apps call, with the same auth in front of them and the same traces behind them.

Set up Zed

Zed reads its MCP servers from Zed settings.json → context_servers. Add the deployment there. The endpoint is the one Air Pipe serves for that organisation and environment; the header carries whatever credential the interfaces behind it already require.

• { "context_servers": { "airpipe": { "url": "https://api.airpipe.io/<org>/<env>/mcp", "headers": { "Authorization": "Bearer <your-token>" } } } }
• Managed endpoint: https://api.airpipe.io/<org>/<env>/mcp
• Self-hosted endpoint: https://your-deployment/mcp
• Credential is forwarded as Authorization: Bearer — the same one the HTTP route requires

The tools are routes you already have

An interface becomes a tool with an mcp: block on it — no second implementation, no separate server to run. The tool's input schema is generated from the assert tests the interface already carries, so the signature an agent sees cannot drift from what the route actually validates.

• mcp: true on an interface publishes it as a tool
• Input schema derived from the route's own assertions
• mcp_servers declares the server's name and instructions for the client's UI
• list_authorizer scopes which tools a given caller can even see

Same auth, same traces, no new blast radius

Exposing a route to Zed does not open a side door. The forwarded credential is checked by the same JWT verification and network access control that guards the HTTP route, and every tool call produces the same OpenTelemetry trace and Prometheus metrics as an ordinary request. An agent that misbehaves is visible in the tooling you already run.

Frequently asked questions

• Do I have to build a separate MCP server for Zed? No. The MCP endpoint is served by the same deployment as your HTTP routes, from the same config. Marking an interface mcp: publishes it; there is no second process, no second container and no second thing to keep in sync.
• Can an agent see tools it is not allowed to call? By default a tool with mcp.enabled is publicly discoverable — anyone who can reach the endpoint sees its name, description and input schema, though calling it still requires whatever auth the interface enforces. When the catalogue itself is sensitive, list_authorizer names an interface that decides visibility per caller, run with the caller's forwarded credential.
• Does this work self-hosted? Yes. Self-hosted deployments serve the default MCP server at /mcp and named servers at /mcp/<id>; managed deployments serve them under /<org>/<env>/. Zed does not care which, and the config is identical either way.
• What happens when the API behind the tool changes? The tool signature changes with it, because the schema is generated from the route's assertions rather than hand-written alongside them. There is no second copy to forget.