Dendra: Open Source TypeScript API and MCP Framework

A single business operation can appear in several places: a web application, a REST endpoint, API documentation and an AI assistant. Maintaining each surface separately creates repeated definitions and more places for input rules or business logic to diverge. I built Dendra around a practical question: how can developers define an operation once, then expose it through the interfaces their application needs? The goal was to make those interfaces share a contract while preserving the application’s control over data, permissions and deployment.

I made the procedure the core building block. Each procedure combines its input schema and handler with optional middleware, HTTP metadata and AI tool metadata. Procedures are grouped into a router that provides the foundation for the supported interfaces. In the notes example, a create operation declares its title and body inputs, opts into AI exposure with .ai(), and calls the application’s database through its request context. The typed client calls that same operation. This gives developers one place to express the operation’s contract instead of maintaining a separate handler for every integration.

I built the framework to support typed clients, REST routes, OpenAPI 3.1 documentation, streaming and Model Context Protocol integration primitives. Client types are inferred from the router, so the TypeScript client does not require a separate code generation step. HTTP adapters connect the procedure model to the application runtime. MCP integration provides a path for exposing selected operations to compatible AI tools. Applications choose which adapters to mount and which procedures to make available; using the framework does not mean enabling every interface.

One of my key design decisions was to make AI exposure explicit. Only procedures marked with .ai() enter the generated AI toolset. Input validation and middleware remain in the shared execution path when a tool invokes an operation. I kept authentication, authorization, tenant checks and external credentials under application control. That boundary matters: a typed input or a tool description does not grant permission to access a record. The application still decides who can invoke an operation and what data they may access.

I kept the core free of required runtime dependencies and separated optional integrations from the central procedure model. The reviewed implementation includes an optional Anthropic agent loop and a React assistant hook. A Next.js notes example demonstrates how the router, client and AI integration fit together. Developers can inspect the public source and documentation before adopting it, and evaluate the parts relevant to their stack without treating the framework as a replacement for their database, interface or authorization policy.

The result is a publicly available framework with documentation and a reference application, released under the MIT license. The delivered work includes the shared procedure and router model, typed client access, HTTP and REST interfaces, OpenAPI generation, streaming support and selected AI and MCP integration paths. This case study demonstrates my work on developer tooling, API architecture and explicit AI integration boundaries. The product page, architecture diagram and procedure example shown here are real project materials, so readers can connect the design decisions to the implementation.

The implementation review for this case study is pinned to Dendra 0.7.0 on 17 October 2026. Dendra is a pre 1.0 open source project, and its interfaces may evolve. The outcome reported here is the framework and its supporting developer experience. Customer adoption, revenue and performance improvements have not been measured for this case study.

Product and documentation · Public source · Full TechFoundry case study