MCP

Reach for the MCP surface when an agent should call your stitches: it exposes a single code-mode run_stitch tool over MCP, plus a list_stitches discovery tool — so the agent's tool list stays tiny no matter how many stitches you register, and never touches a credential.

Example

Start the server with the stitch CLI. It loads your stitches module and speaks JSON-RPC over stdio (newline-delimited), with a startup notice on stderr:

stitch mcp --module ./stitches.ts

The agent then calls one tool — run_stitch — passing the stitch name and its input. The tool call looks like this:

{
    "name": "run_stitch",
    "input": { "params": { "id": "42" }, "query": { "expand": "owner" } }
}

input carries { params, query, body, headers }; run_stitch runs the named stitch behind the capability boundary and returns its validated result.

Options

run_stitch takes { name, input } and covers every registered stitch with one tool — name selects the stitch, input is its { params, query, body, headers } object. This is code-mode: one tool, not one tool per path.

list_stitches is the discovery tool. It takes no arguments and returns each stitch's name, method, and path, so the agent knows what to pass to run_stitch.

Why one tool beats one-per-path: a tool per registered stitch floods the agent's context — every name, description, and input schema is re-sent on each turn. Code mode keeps the tool list at two entries however many stitches you register, so the agent spends its context on the task, not on a tool catalog. The full design of the tool lives in the agents section; see run_stitch & code mode.

The capability boundary holds here: the agent calls run_stitch by name and never sees the token, cookie, or signing key the stitch holds — it invokes a capability, not a credential.

See also