# stitchkit vs tRPC vs ts-rest

> How stitchkit compares to the closest alternatives for a contract-first TypeScript backend.

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

## Capability matrix

| Capability | stitchkit | tRPC | ts-rest | Hono / Elysia |
|---|---|---|---|---|
| Contract is plain data — no decorators, no codegen | yes | partial (router type) | yes | no |
| Inferred typed client | yes | yes | yes | partial (Eden / hc) |
| Plain HTTP REST routes | yes | partial (RPC-style) | yes | yes |
| MCP tools from the same contract | yes | no | no | no |
| AI-agent tools from the same contract | yes | no | no | no |
| No HTTP-framework dependency | yes | yes | yes | it is one |

## tRPC — closest in spirit, different reach

**Overlaps:** end-to-end types without code generation, no hand-written client.

**Differs:** in tRPC the contract *is* the router type — it exists only in TypeScript and
cannot be walked to generate other surfaces. stitchkit's contract is plain data, so the
same declaration also yields MCP tools, agent tools and a CLI. tRPC speaks its own
RPC-style protocol; stitchkit emits ordinary REST routes.

**Choose tRPC when** the API has exactly one consumer — your own TypeScript frontend —
and never needs to reach assistants or scripts.

## ts-rest — same idea, narrower scope

**Overlaps:** contract as plain data, REST routes, inferred client, no codegen.

**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`.

**Choose ts-rest when** you already have a framework you like and only need typed REST on top.

## Hono / Elysia — a different layer

**Overlaps:** fast, modern, runtime-first, good TypeScript support.

**Differs:** they are the layer stitchkit does not have — routing and middleware. There is
no contract object to reuse, so exposing the same operation as an MCP tool means describing
it a second time.

**Choose them when** you want a general-purpose web framework and are fine describing 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.

---

Project page: https://maxlistov.com/stitchkit.md
Repository: https://github.com/max-listov/stitchkit