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": {
        "name": "getUser",
        "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.

Programmatic API

The CLI is a thin wrapper. To run the MCP server in your own process, import serveStdio from the stitchapi/mcp subpath and hand it a registry of named stitches:

import * as stitches from './stitches';

import { serveStdio } from 'stitchapi/mcp';

// Reads newline-delimited JSON-RPC from stdin, writes responses to stdout.
const { close } = serveStdio(stitches);

// later
close();

serveStdio(registry, options?) wires the run_stitch / list_stitches server to stdio and returns a handle whose close() detaches the transport. Pass { input, output } to bind a different stream pair instead of stdio.

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.

The transport writes JSON-RPC to stdout and its startup notice to stderr, so keep stdout clean — don't log to it or pipe anything else through it, or the framing breaks.

See also