How dendra compares
dendra sits where a typed-API framework and the AI/MCP world overlap. Here’s how it compares to the pieces you’d otherwise assemble yourself.
| tRPC | ts-rest | MCP SDK | dendra | |
|---|---|---|---|---|
| Typed client, no codegen | ✓ | ✓ | — | ✓ |
| REST + OpenAPI 3.1 | — | ✓ | — | ✓ |
| RPC (nested procedures) | ✓ | — | — | ✓ |
| Streaming / WebSocket | ~ | — | — | ✓ |
| One definition (no separate contract) | ✓ | — | — | ✓ |
| Your API is also LLM tools | — | — | by hand | ✓ |
| MCP server (expose procedures) | — | — | ✓ | ✓ |
| Consume external MCP | — | — | — | ✓ |
| Context budget (memory + lazy tools) | — | — | — | ✓ |
vs tRPC
tRPC gives you typed procedures and a typed client. dendra does that and:
- REST + OpenAPI from the same procedures (tRPC is RPC-only).
.ai()tools + MCP server — your procedures become model tools with the same validation; tRPC has no AI/MCP story.- Standard Schema — use built-in
s.*, or Zod / Valibot / ArkType. - Zero-dependency core.
If you only need typed RPC between your own client and server, tRPC is great — the largest ecosystem and the mature React Query integration are real advantages. dendra is for when those same procedures also need to be REST endpoints and tools an agent (or Claude over MCP) can call.
vs ts-rest
ts-rest is contract-first typed REST: you declare a contract (routes + schemas), implement it separately, and get a typed client plus OpenAPI. dendra overlaps on typed REST + client, but differs in shape:
- One definition, not two. In ts-rest the contract and the implementation are
separate objects you keep in sync; in dendra the procedure is the definition —
the client type comes from
typeof appRouter. - RPC + streaming + an in-process caller, not REST-only.
- AI / MCP — the same procedures are tools and an MCP server; ts-rest has no AI/MCP story.
Choose ts-rest if you want a clean REST contract and nothing more. Choose dendra if those endpoints should also be RPC, streaming, and agent-callable from one spec.
vs Hono
Hono is a small, fast web framework — routing + middleware for any Web-standard
runtime — with an optional typed RPC client. It sits a layer below dendra: it’s
the HTTP layer, not the typed-procedure + AI/MCP layer. The two are complementary,
not competing — toFetchHandler(appRouter) mounts dendra on Hono (or Bun, Deno,
Workers). Use Hono alone if you just want fast routing; add dendra when those routes
should become typed procedures that are also REST, OpenAPI, and MCP tools.
vs the MCP SDK alone
The MCP SDK lets you stand up an MCP server by hand-writing tool schemas and handlers. With dendra, the MCP server is a projection of procedures you already have — no second definition, and those same procedures are still your typed API. dendra also handles the other direction (consuming external MCP servers and merging their tools with yours).
vs the Vercel AI SDK / TanStack AI
Those are AI SDKs — chat, streaming, provider adapters. dendra is the API +
tool + MCP layer underneath. It complements them: expose mergeToolsets() output
to whatever model stack you use. dendra’s optional runAgent / useAssistant
helpers are a convenience, not the point — the point is that your typed procedures
are the tools, and they’re also an MCP server.
Choose dendra when
Your API should be callable by agents and Claude with no parallel tool layer, you want one definition to stay the single source of truth, or you need to both expose and consume MCP.
- You’re on Next.js (or any Web-standard runtime) and want typed RPC and REST.
- Your procedures should also be tools an LLM or Claude (over MCP) can call.
- You want to consume external MCP servers and manage the model’s context (memory, lazy tool loading) without rebuilding that plumbing.