Vyges MCP™
One local MCP server turns the silicon tools on your machine into callable, typed tools — so your assistant can actually run sign-off, timing, DRC, LVS, synthesis, and place & route. No port. No auth. No cloud.
Ships inside the Vyges CLI — nothing extra to install.
Local by design
No port
No auth
No cloud
No upload
The server speaks JSON-RPC over stdin and stdout to a process your own client starts. The engines are binaries on your disk reading files on your disk — which is what makes this usable against a PDK under NDA and IP you cannot send anywhere.
Every model will happily explain antenna rules, argue about hold margin, and write you a Tcl script it cannot execute. The gap is not knowledge. It is execution. Meanwhile the tools that do the real work sit on your disk behind a dozen different command lines, each with its own flags, file formats, and idea of what an error looks like.
vyges mcp is a local Model Context Protocol server that closes it. Run it once and every engine it resolves on your machine becomes a callable tool with a typed contract — so you ask in plain English, the model picks the right engine and the right arguments, and a deterministic binary does the actual work.
This is the part that makes it work. There is no Vyges-specific model and no prompt library you have to keep in step with our releases. Every engine ships a machine-readable contract — --describe — stating what it consumes, what it produces, and what its results mean. That description is the integration: the model reads it at connect time and routes from it, and it travels with the binary, so it cannot drift out of date.
Which makes bring your own model real rather than aspirational. If it can call MCP tools, it can drive the engines — hosted, open-weight, or domain-specific.
An agent is handed plain-English requests on a clean GitHub Actions runner, with nothing but the engines' own descriptions to work from, and has to choose the tools itself. The run report shows what it picked and what came back — read the latest one →
It is not only the Vyges engines. The open tools you already run are exposed through the same interface, so your assistant does not need to learn six invocation styles to get through a flow.
Timing and signal integrity, DRC, LVS, extraction, power, IR-drop and electromigration, thermal, CDC, glitch, equivalence, characterization, layout rendering, analog measurement — plus the optimizers that act on what they find.
OpenROAD, Yosys, Magic, Netgen, KLayout and Verilator are exposed as passthrough tools — the underlying tool stays in control of execution, with your arguments handed to it directly.
Ask vyges mcp tools what resolved on your host — it reports what it found and what it could not, rather than advertising tools that are not there.
Reading your design and rewriting your netlist are not the same risk, so they are not the same permission. Every tool is classified by what it does to your design — and the classification is derived from the engine's own description, not a list someone maintains by hand, so it cannot drift away from what the binary does.
Read
DRC, LVS, timing, extraction, power, thermal, CDC, glitch, equivalence, measurement. They produce findings. They never touch the design.
Mutate
The optimizers, the re-mapper, and every external tool that could write. Anything not provably read-only lands here — least privilege, deliberately.
Profiles
core · pro · fullcore exposes the read-only tools only — the agent can analyze all day and cannot alter anything. pro and full admit the mutating tools.
Which profile you get: the default is full, so that adding the gate did not change what already worked for existing users. Restricting the surface is one environment variable — VYGES_MCP_PROFILE=core — and that is what we would run when pointing an agent at a design that matters.
Where the line falls is a policy question, and it is rarely the same twice — analysis-only for contractors, mutation behind review for the ECO team, particular tools withheld entirely. Because the classification comes from the tools' own descriptions, the boundary is configuration rather than a fork. Talk to us about a profile that matches your policy →
The model is a driver, never a computation. Pull it out and the same engines run headless in CI, producing the same answers.
vyges mcp --list prints exactly what the server would advertise, before you connect anything to it.
Worth being precise, because "local" is easy to overstate. The MCP server does not upload your design or your PDK to a Vyges service — there is no Vyges endpoint in the path at all.
What your model sees is whatever your AI client sends it: your prompts, the tool descriptions, and the results and paths the tools return. That traffic is governed by the client and model you configure — a local model keeps it on the machine, a hosted one does not. Choosing that is yours, and the core profile bounds what an agent can do with it either way.
The reasoning is rented and replaceable. The engines, the data, and the answers are yours.
The design rationale is written up in our papers — deterministic core, agent tail →