run_stitch & code-mode

Drive stitches from an agent sandbox with a single run_stitch tool — pass { name, input } and it covers every stitch you register, so the model's tool list (and its context) stays tiny no matter how many stitches there are. A companion list_stitches tool discovers the available names.

Example

The agent first discovers what is available, then runs one by name. Both are plain MCP tool calls — there is no library import on the agent side.

{ "name": "list_stitches", "input": {} }

list_stitches returns the registered stitches with their method and path, so the agent knows what to pass to run_stitch:

{
    "name": "run_stitch",
    "input": { "name": "getUser", "input": { "params": { "id": 1 } } }
}

Here the inner input is the stitch input — { params?, query?, body?, headers? } — and the stitch runs against api.example.com behind the capability boundary. The agent never sees the credential.

Options

Two tools make up the whole surface. run_stitch takes { name, input }, where input is the stitch input { params?, query?, body?, headers? }; list_stitches takes no arguments and returns the names, methods, and paths.

This is code-mode: one tool for every stitch, rather than one MCP tool per endpoint. One-tool-per-endpoint floods the model's context — every registered stitch adds another schema the model must carry — while run_stitch keeps the tool list at a constant two no matter how many stitches you register.

The agent calls run_stitch and never touches the credential: it names a capability, the server holds the secret. That is capability, not credential applied to the agent boundary.

If you author the stitch that backs a name like getUser, it is an ordinary stitch from stitchapi:

import { stitch } from 'stitchapi';

const getUser = stitch({
    baseUrl: 'https://api.example.com',
    path: '/users/:id',
});

See also