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 connects an agent to the same generation architecture used by the Converters page. The selected generator and engine versions determine the generated output.
The MCP server and stdio transport run on your machine. Generation payloads are sent over HTTPS to the MetaEngine API and processed ephemerally; specifications and generated code are not persisted or logged. Existing project source is not uploaded unless its content is explicitly included in a generation payload.
Read the public privacy policyEvery call is self-contained — pass a spec inline, load a full configuration from a file, or expand a recipe object or file locally. Pick a framework or language and get a text summary back.
The same input and selected engine version produce stable output. Version changes remain visible in the generated diff.
Your MCP client controls tool permissions and confirmation behavior. The server exposes all eight tools when it starts.
Claude Desktop, Cursor, Cline, Continue, Zed — wherever the protocol is spoken.
MCP and the browser converters use the hosted generation service. Standalone packages are versioned releases for local builds.
generate_from_recipe accepts exactly one recipe object or recipe file path. The local Node process expands compact property maps, references, reusable templates, and deterministic repetition into the existing MetaEngine configuration before hosted generation.
{
"recipeVersion": 1,
"language": "typescript",
"classes": [{
"name": "Order",
"id": "order",
"properties": {
"id": "string",
"note?": "string",
"items": { "ref": "order-items" }
},
"customCode": [{
"code": "first(): $item { return this.items[0]; }",
"templateRefs": [{
"placeholder": "$item",
"typeIdentifier": "order-item"
}]
}]
}, {
"name": "OrderItem",
"id": "order-item",
"properties": {
"sku": "string",
"quantity": "number"
}
}],
"arrayTypes": [{
"typeIdentifier": "order-items",
"elementTypeIdentifier": "order-item"
}]
}{
"recipeVersion": 1,
"language": "typescript",
"templates": {
"model": {
"parameters": ["name", "fields"],
"body": { "classes": [{
"name": { "$param": "name" },
"properties": { "$param": "fields" }
}]}
}
},
"instances": [{
"template": "model",
"values": [{
"name": "User",
"fields": { "id": "string" }
}]
}]
}Use "id": "string" for a primitive, a trailing ? for an optional property, and { "ref": "order-item" } when one generated type points to another. Recipes can omit repeated structure, while literal business code still has to be supplied; they do not guarantee token savings.
The MCP server resolves recipe references and expansions on your machine. Unknown fields, unresolved references, duplicate identifiers or member names, and expansion-limit failures stop before the hosted request; a valid recipe becomes the same full configuration used by generate_code.
Recipe types can still carry the existing target-language customCode, customFiles, and explicit templateRefs. Template values interpolate only through $param or $format; ordinary strings stay literal.
Each request can contain up to 250 counted types: classes, interfaces, and enums, minus concrete generic class and interface instances. Arrays, dictionaries, and custom files do not add to that count. The recipe plus input files actually read share a 5 MiB UTF-8 JSON limit. Template expansion and the normalized native payload each have a separate 5 MiB limit.
Load a full JSON spec, expand a compact recipe, prime an agent, or generate from OpenAPI, GraphQL, Protobuf, and SQL. Each capability is a single stateless MCP call that returns a write summary as text.
Add the stdio server to your MCP client's configuration and restart the client. No API key or account is required.
$ claude mcp add metaengine -- npx -y @metaengine/mcp-server@1.5.0
{
"mcpServers": {
"metaengine": {
"command": "npx",
"args": ["-y", "@metaengine/mcp-server@1.5.0"]
}
}
}The MCP is a local boundary over the same generation architecture used by the Converters page and CLI. The selected engine version still determines the generated bytes.
MCP receive generate_from_recipe LOCAL validate recipe · expand templates · resolve type refs HTTPS send expanded generation configuration ENGINE generate files for the selected language LOCAL write files · return summary
A 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.