Cline loads remote MCP servers from its settings file, so your interfaces show up as tools in its task loop. 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 Cline
Cline reads its MCP servers from cline_mcp_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.
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 Cline 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 Cline? 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>/. Cline 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.