Let an agent call your API without handing it the key
Expose your stitches over MCP through one run_stitch tool — the agent invokes a capability and never sees the credential.
Task
You want an LLM agent to call your APIs, but you cannot give it the API key — and you do not want to flood its context with one tool per endpoint.
Example
One way: author named stitches that hold their own auth, then serve them over MCP.
// stitches.ts — author each stitch with its auth and a name.
import { , , } from 'stitchapi';
export const = ({
: 'getUser',
: 'https://api.example.com',
: '/users/{id}',
: (('API_TOKEN')),
});Serve the module over MCP from the shell:
stitch mcp --module ./stitches.tsThe agent discovers names with list_stitches, then calls one through the single
run_stitch tool:
{
"name": "run_stitch",
"input": { "name": "getUser", "input": { "params": { "id": 1 } } }
}How it works
run_stitch covers every registered stitch with one tool — name selects
it, input is its { params, query, body, headers } — so the agent's tool list
stays at two entries (run_stitch + list_stitches) no matter how many stitches
you register, keeping its context flat. The auth runs inside the runtime: the
agent names a capability, the server
holds the bearer(env('API_TOKEN')) secret, and the result returns without the
token. To run the server in your own process, import serveStdio from the
stitchapi/mcp subpath.
See also
Authenticate without the token touching your code
Declare auth on the stitch so callers get a capability, not a credential — the secret is read per call and never returned.
Call one stitch as a function, a CLI command, and an agent tool
One definition, four front doors — in-process, shell, HTTP, and MCP — with nothing about the stitch changing.