Comparison

stitchkit vs tRPC vs ts-rest

All four tools give a TypeScript backend typed calls without code generation. They diverge on one question: how many surfaces does one definition feed?

How it compares

CapabilitystitchkittRPCts-restHono / Elysia
Contract is plain data — no decorators, no codegen●◐●○
Inferred typed client●●●◐
Plain HTTP REST routes●◐●●
MCP tools from the same contract●○○○
AI-agent tools from the same contract●○○○
No HTTP-framework dependency●●●◐

Where each one fits

tRPC

Closest in spirit, different reach

What overlaps
Both give you end-to-end types without code generation, and both remove the hand-written client.
What differs
In tRPC the contract is the router type itself — it exists only in TypeScript. In stitchkit the contract is plain data, so the same declaration can also be walked to produce MCP tools, agent tools and a CLI. tRPC also speaks its own RPC-style protocol; stitchkit emits ordinary REST routes.
Choose it when
Pick tRPC when the API has exactly one consumer — your own TypeScript frontend — and you never need to expose it to assistants or scripts.

ts-rest

Same idea, narrower scope

What overlaps
Contract as plain data, REST routes, inferred client, no codegen — the philosophies line up closely.
What differs
ts-rest stops at HTTP. It adapts to an existing framework (Express, Nest, Fastify) rather than serving on its own, and nothing in it produces MCP or agent tools. stitchkit runs directly on Bun.serve() or srvx and treats assistant-facing surfaces as first-class.
Choose it when
Pick ts-rest when you already have a framework you like and only need typed REST on top of it.

Hono / Elysia

Different layer entirely

What overlaps
Both are fast modern runtimes-first HTTP frameworks with good TypeScript support.
What differs
They are the layer stitchkit does not have — routing and middleware. There is no contract object to reuse: to expose the same operation as an MCP tool you describe it a second time. stitchkit has no framework under it at all; it calls the runtime's server directly.
Choose it when
Pick them when you want a general-purpose web framework and are happy to describe each surface separately.

The short version

If your API will only ever be called by your own frontend, the older tools are well-trodden and there is little reason to move. If the same operations also have to reach Claude, Cursor, an AI agent or a shell script, describing them once instead of four times is the whole argument for stitchkit.

Back to stitchkitDocumentationGitHub