Give Claude Code tools that are already a real backend.

Add the deployment as a Streamable HTTP server and Claude Code can call your interfaces as tools while it works in your repo. 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 Claude Code

Claude Code adds remote MCP servers from the command line. Run this once against the deployment you want it to reach — the endpoint is the one Air Pipe serves for that organisation and environment, and the token is whatever credential the interfaces behind it already require.

• claude mcp add --transport http airpipe \ https://api.airpipe.io/<org>/<env>/mcp \ --header "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 Claude Code 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 Claude Code? 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>/. Claude Code 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.