n8n can consume your Air Pipe deployment as an MCP tool — which is the honest way to run both: n8n for the canvas, Air Pipe for the backend behind it. 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 n8n
n8n adds remote MCP servers through its own interface: MCP Client Tool node → HTTP Streamable. Give it the deployment's MCP endpoint and authorise it — there is no file to edit and no API key to paste into a config.
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 n8n 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 n8n? 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>/. n8n 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.