Language Optimization using MCP

[TolinSimpson]

Just found this project, I worked on something similar with different architecture that used a mid layer between the LLM and the user's dev environment (language agnostic, they just add a small interpreter) The LLM works with super small token-efficient instructions:

Example:

// x = 10
0.11("x", 10)
// x = x + 5
0.17($x, 5)
0.11("x", $result)
// print x, then stop
0.13($x)
0.1()

These instructions would then be run inside javascript, python, or whatever language (I have a template for generating new interpreters). Very different approach than zerolang but may have some tricks you guys can draw inspiration from for saving tokens.

https://github.com/TolinSimpson/LLMVCS

[Alemusica]

The title says MCP but the body is about token-efficient encoding. Worth separating, because Zero arguably already has the first.

On tokens: query / patch --op is functionally what the LLMVCS opcodes reach for — a compact structured edit channel where the compiler, not regenerated text, is ground truth. The graph already hands the agent node ids, graphHash, types, effects and call edges, and zero patch rejects a stale hash or invalid shape before the store is written. That transactional boundary is the part an opcode stream lacks, and it's exactly what makes an MCP wrapper safe.

On MCP: since the --json contract is already stable, a server is a thin adapter, not new semantics. What tends to work in agent-facing MCP servers:

• Resources (read-only, cacheable): a graph projection, query?fn=…|find=…|refs=…, and diagnostics from zero dev --json. Reads never mutate, so agents can poll them cheaply.
• Tools (effectful, intent-named): apply_patch(ops[], expectGraphHash), check, test(filter), run(args), explain(code). apply_patch should require the caller to echo the graphHash it read, so a stale edit fails closed instead of racing.

Three pitfalls from building agent-facing MCP servers:

1. Don't ship one run_zero(cmd) passthrough. It defeats the schema — the model loses the typed errors that make Zero legible, and you can't gate mutation from inspection.
2. Return diagnostics as structured {code, span, message} (which check --json / dev --json already emit), not rendered prose. Models repair far better against fields, and explain(code) becomes a real follow-up tool.
3. Keep the boundary at the projection: tools touch the graph, never .0 text, so import / export stay the only entry for human edits — the invariant the CLI already enforces.

Open question for maintainers: is an MCP server in scope, or is the intended path the version-matched skill + plain CLI? If skill-first, the real "MCP optimization" may just be tightening which --json fields the skill tells agents to request. Happy to prototype a reference server against the current --json shapes if that'd be useful.

[TolinSimpson]

MCP wraps a vectorizer and is just an example of how an LLM can interact with the main layer using a tool call. A more intentional implementation would be required. I speculate something could be learned from the pattern. The above AI generated reply isn't helpful since it lacks full context of the repo I cited.