MetaEngine ships a Model Context Protocol server that exposes every converter and batch type generator as a tool call. Connect it to Claude Desktop, Cursor, Cline, or any MCP-aware assistant — and let it turn "regenerate my billing client" into a real, typed, committed diff.
MetaEngine's MCP server is a thin boundary on top of the same compiler pipeline that powers the Converters page. Anywhere you'd open the Playground or run the CLI, an agent can do the same call structurally and get back the same byte-reproducible output.
stdio by default; specs and source never leave the sandbox unless you opt in.
Every call is self-contained — pass the spec inline (or by file path for generate_code), pick framework or language, get a text summary back. No handles, no context IDs to thread through the loop.
Generation is deterministic. Agents can retry without drift.
Auto-approve safe reads; require confirmation for writes. Standard MCP scope rules.
Claude Desktop, Cursor, Cline, Continue, Zed — wherever the protocol is spoken.
The converters surfaced through MCP are the same ones the Playground and CLI use. Versions stay in lockstep.
Every capability MetaEngine ships — loading a JSON spec, priming an agent, generating from OpenAPI / GraphQL / Protobuf / SQL, or composing structured types — is a single, stateless MCP call. Pass the spec inline (or by file path), get a write summary as text.
Drop the server into your MCP client's config and restart. No API key, no account — every converter in the registry is immediately addressable.
$ npx @metaengine/mcp-server add claude
{
"mcpServers": {
"metaengine": {
"command": "npx",
"args": ["@metaengine/mcp-server@latest"],
"env": {
"METAENGINE_SCOPE": "openapi,graphql,protobuf,sql"
}
}
}
}The MCP is a thin boundary. Heavy lifting is the same pipeline that powers the Converters page and the CLI — which is why output stays byte-reproducible across runs and across surfaces.
[14:02:18.441] INFO mcp transport=stdio ready pid=42811
[14:02:18.442] INFO tools registered · load_spec_from_file · metaengine_initialize · generate_code · generate_openapi · generate_graphql · generate_protobuf · generate_sql
[14:02:19.108] REQ metaengine_initialize { language: "csharp" }
[14:02:19.114] OK metaengine_initialize → guide returned · 5.2KB · 4ms
[14:02:19.301] REQ generate_openapi { framework: "csharp-httpclient", openApiSpecUrl: "…/openapi.yaml" }
[14:02:19.612] OK generate_openapi → 38 files written · 142.6KB · 309ms
[14:02:19.918] REQ load_spec_from_file { specFilePath: "./specs/billing-domain.json" }
[14:02:20.234] OK load_spec_from_file → 71 files written · 184.2KB · 314ms
[14:02:20.501] INFO idle · 0 in-flight · mem=34.1MBA small open harness compares two Claude agents producing the same DDD codebase: one using the MetaEngine MCP, one using Claude's built-in Write tool, file by file. It captures the result-event totals from claude -p, compiles the output, and runs structural verification on every entity.
Numbers below are illustrations from one author, one machine, N=5 per cell — not benchmarks of MetaEngine. They give the design tenets above some empirical shape. The harness, prompts, and result events are MIT-licensed; reproducing on your own setup is the only thing that tells you whether the patterns hold for you.
When the MCP writes every file in one call and returns a single summary, the agent's loop runs ~11–15× shorter than a Write-tool loop emitting one file per turn. cache_read accumulation drops correspondingly. The mechanism is loop topology, not the model — it reproduced across an Opus → Sonnet swap and across spec shape.
How the agent gets a spec to the tool changes its measured token cost. Embedding a large spec inline as JSON costs more output tokens than having the agent write a small Python transformer that produces the spec file at runtime, which the tool then reads from disk. ~70–77% output-token reduction across TS / Java / Python. The pattern only holds when the spec is computable from a smaller source.
I'm not claiming a fixed % cheaper or faster. I'm not claiming MCP is objectively the right way to do codegen. The dollar figures depend on Anthropic's current billing of tool_use input bytes — that's an implementation detail of one provider at one point in time.
The harness lives in a separate repo. It includes the warmup brief, the spec, the prompts, the verification suite, and the auto-generated summary.md with caveats inline. If you reproduce, falsify, or measure something that contradicts this — open an issue. Disagreement is more useful to me than confirmation.
The MCP is MIT, free, and ships with the same converters as the rest of the platform. The benchmark harness is also MIT, in a separate repo — fork it, run it, tell me what's wrong.