Give Gemini CLI tools that are already a real backend.

Gemini CLI reads MCP servers from its settings file and can then call your interfaces as tools from the terminal. 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 Gemini CLI

Gemini CLI reads its MCP servers from ~/.gemini/settings.json. 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.

• { "mcpServers": { "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 Gemini CLI 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 Gemini CLI? 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>/. Gemini CLI 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.