Use from an agent

StitchAPI is agent-native because of two choices that fall out of the stitch primitive: an agent receives a capability, not a credential — it invokes a stitch and gets back structured, validated, traceable data without ever touching the secret — and it works through one context-frugal tool, not one tool per endpoint, so adding APIs never floods the model's context window.

The rest of this section is three things an agent does with a stitch: it invokes them, it authors them, and it reasons over them.

Invoke

An agent drives stitches from a sandbox through a single code-mode tool, run_stitch, rather than a generated tool per endpoint. The agent writes a small TypeScript snippet that imports stitchapi, calls the stitch, and returns the result — and list_stitches tells it what is available to call.

import { stitch } from 'stitchapi';

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

// The agent writes this in the sandbox; run_stitch executes it.
const user = await getUser({ params: { id: 7 } });

One tool keeps the context budget flat as the catalog grows, and the credential stays behind the boundary — the agent sees the user, never the token.

Author

An agent does not need a spec to add an API. Hand it a single example — a curl command, a HAR entry, or a snippet from a vendor's docs — and it emits a stitch declaration: the URL, the input shape, and an output schema inferred from the one response it saw. The declaration is committable code the agent (or you) can review.

Reason over

Two outputs let an agent reason about stitches cheaply. The docs build emits an auto-generated llms.txt and a per-page llms.mdx, so an agent pulls just the one page it needs into context instead of the whole manual. And every call is a typed event stream — start → progress → drift → result → done — so the agent reads not just the final value but the retry that succeeded, the throttle that paused, and the field that drifted.

See also