Introducing mcp-rune: turn your data model into a complete MCP server

I built a couple of production MCP servers over the past year. Along the way I kept extracting the same patterns into a library — model definitions, CRUD tools, prompt strategies, form generation, OAuth flows. Eventually I realized I wasn’t building servers anymore. I was building a framework.

That framework is mcp-rune: turn your data model into a complete MCP server.

The MCP scaling wall

The Model Context Protocol is spreading fast — Claude Desktop, VS Code, Cursor and more all speak it now. But every framework I tried stops at the transport level:

1. The official SDK — protocol primitives. You wire every tool by hand.
2. Protocol wrappers (FastMCP, mcp-framework) — nicer registration, still one handler per tool.
3. API converters (Stainless, FastAPI-MCP) — generate tools from OpenAPI specs, with no intelligence layer.

If your server manages models — books, projects, activities, anything with CRUD — you write the same handlers, the same validation, the same field docs, for every model. Ten models × five verbs = fifty hand-written tools, a picker that overflows, and an LLM that struggles to choose between them. Add prompts, forms and search and it’s hundreds of lines of boilerplate per model.

This is the problem Rails solved for web apps in 2004. Convention over configuration. The model is the source of truth. Write it once, derive the rest.

What mcp-rune is

mcp-rune is a model-driven framework. You declare a model once, and it derives the tools, prompts, forms, docs and interactive UI an agent needs — then indexes your data so the agent retrieves by meaning, not raw rows.

import { BaseModel } from '@mcp-rune/mcp-rune'

export class Book extends BaseModel {
  static override attributes = {
    title:  { type: 'string', required: true },
    author: { type: 'string', required: true },
    status: { type: 'enum', values: ['reading', 'done'] },
    rating: { type: 'integer', validation: { min: 1, max: 5 } }
  }
}

That’s the whole model. From it, the framework gives you the rest.

What it derives

• Polymorphic CRUD — a fixed core of generic tools (list_models, find_records, create_model, update_model, delete_model, bulk_action_models) serves every model you declare. The LLM passes the model name as a parameter, so the tool list never grows with your domain — register 10 models or 100 and tool selection stays accurate.
• Prompt strategies — agent-followable prompts with sections, validation, enum tables and turn-taking, all derived from your attributes, so the docs never drift from the model.
• Interactive MCP Apps — schema-driven create / edit / search / picker UIs rendered inside Claude Desktop and compatible hosts. No per-model HTML.
• Analysis & retrieval — opt-in semantic search and map-reduce aggregation over your records (vectors + a relationship graph + your domain vocabulary), backed by local pgvector, so the agent retrieves by meaning.
• Domain intelligence — encoded business rules and multi-step workflows, so the server understands your domain instead of generic CRUD.
• OAuth 2.1 — spec-compliant discovery and PKCE the way Inspector and strict clients expect, on both stdio (local) and Streamable HTTP (remote, multi-user) transports.

Everyone else works at the tool/transport level. mcp-rune works at the application level. The full breakdown lives at mcp-rune.dev.

Proof: engineer-mcp

A framework is only as convincing as what it ships. So here is a real one.

Engineer is a personal-development platform I run — track your growth, build better habits. engineer-mcp turns its data model into an MCP server with mcp-rune: 15 models — activities, domains, subdomains, roadmaps, books, problems, repositories and more — exposed to Claude with no bespoke tool handlers. The model definitions are the server.

Take the Activity model alone: a kind (deep work, reading, coding, lecture, review, pairing), a Bloom’s-taxonomy bloom_level (remember → understand → apply → analyze → evaluate → create), a domain and subdomain, target vs. actual minutes, and an optional roadmap stage. Here is that data in Engineer’s own UI:

Now I open Claude Desktop and ask, plainly: “Can you analyze all my activities and take conclusions about my activity sessions from different perspectives?” Claude discovers the engineer-mcp tools, ingests the activities with a few polymorphic queries, and renders a rich visual report:

That it’s a dashboard and not a wall of JSON is deliberate. engineer-mcp runs a chat profile that hides the raw data tools, so instead of echoing rows Claude reaches for one of mcp-rune’s Interactive Apps — overview tiles, distribution donuts by kind and by Bloom’s level, a duration chart — all driven by the same attributes that define the model.

Then Claude reasons over the data across several perspectives and, crucially, surfaces the data-quality gaps: activities with no duration set, every record with a null domain, nothing linked to a roadmap, zero sessions executed:

None of that required a single hand-written analysis tool. The semantic search and aggregation come from the analysis layer; the gap detection falls out of the model’s own schema — required fields, associations, enums. I described the domain once; mcp-rune did the rest.

Who it’s for

If you own a SaaS product, an API, an internal tool, or a data platform and you want it to be genuinely AI-accessible — not “we bolted on a chatbot,” but Claude can query, mutate, and reason over your real model — mcp-rune gets you there without months of custom MCP plumbing.

Try it

npm i @mcp-rune/mcp-rune

It runs on Node 24+, ships full TypeScript declarations (autocomplete and type-checking out of the box), and is MIT-licensed. It’s extracted from production servers that power real workflows daily — engineer-mcp is one of them — not a proof of concept.

Start at mcp-rune.dev.

Want to see how it’s actually wired? The next post takes engineer-mcp apart — the real model declarations, the polymorphic tool surface, the chat-vs-agent profiles, domain workflows, and the pgvector retrieval behind the analysis above: Inside engineer-mcp →