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.
Task
You have defined an API call once. You want to use it in app code, run it ad-hoc from the shell, and let an agent call it — without redefining it three times.
Example
One way: define the stitch once with a name, then reach it through each
surface.
// stitches.ts — define it once, export it by name.
import { } from 'stitchapi';
export const = <{ : number; : string }>({
: 'getUser',
: 'https://api.example.com',
: '/users/{id}',
});
// In app code: call it as a typed async function.
const = await ({ : { : 1 } });From the shell, the CLI loads the module and runs it by name:
stitch run getUser --id 1To an agent over MCP, the single run_stitch tool covers it:
{
"name": "run_stitch",
"input": { "name": "getUser", "input": { "params": { "id": 1 } } }
}How it works
One definition, four surfaces. The in-process function
awaits or .stream()s it; the CLI (stitch run) loads the
module and runs it by name; MCP exposes it to agents through
the single run_stitch tool; and it can be served over HTTP.
The export name, getUser, is what the CLI, HTTP and MCP resolve. The
configured name labels the stitch's traces. Nothing else about the definition
changes between front doors.
See also
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.
Scenarios
Real integration problems that have no one-line answer anywhere — what the usual fixes cost, what StitchAPI changes, and what it leaves to you.