1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@anvil forge a blueprint for a 5-stage 7nm CMOS ring oscillator" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

anvil

by The-Warl0ck

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

anvil-mcp

Anvil — a local physics/chemistry bench as an MCP server.

No cloud. No Bridge. No API key. No LLM.

Type plain words → Anvil's offline intent kernel forges a simulation blueprint → 12-domain physics solvers run it → you get back a simulation snapshot plus proof metrics (pass / warn / fail).

30 seconds

you:    anvil.forge  { intent: "5-stage CMOS ring oscillator at 7nm" }
anvil:  blueprint: silicon · 8 nodes · "Offline kernel: 5-stage ring at 7 nm, VDD 0.75 V."

you:    anvil.solve  { blueprint }
anvil:  [pass] Joule power = 0.0089 W — I²R on the extracted net.
        [pass] Junction temperature = 21.85 °C — lumped thermal node per device, 300 K ambient.
        [pass] EM MTTF (Black) = 1.58e15 yr — Black's equation, Ea = 0.9 eV, worst via.

you:    anvil.export { blueprint, format: "stl" }
anvil:  532 triangles of ASCII STL, ready for a slicer.

Related MCP server: cad-mcp-server

Install

Requires Node ≥ 20. No build step needed for use:

npx github:The-Warl0ck/anvil-mcp

Or clone and run:

git clone https://github.com/The-Warl0ck/anvil-mcp
cd anvil-mcp
npm install
npm run build
npm start

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "anvil": {
      "command": "npx",
      "args": ["github:The-Warl0ck/anvil-mcp"]
    }
  }
}

Tools

Tool	Input	Output
`anvil.domains`	`{}`	The 12 domains and what each simulates
`anvil.forge`	`{ intent, domain? }`	Blueprint JSON + rationale (offline, no LLM)
`anvil.solve`	`{ blueprint, steps? }`	SimSnapshot + ProofMetric[] with real numbers
`anvil.export`	`{ blueprint, format }`	STL (ASCII) or OBJ text for 3D printing / CAD

The 12 domains

silicon (nets, delay, heat, electromigration) · cellular (membranes, ions, morphogens) · quantum (wells, tunneling, decoherence) · neural (spikes, region flows) · mechanical (stress, modes, yield) · chemistry (mass-action kinetics, ΔH, equilibrium) · architecture (plans, interiors, circulation) · metallurgy (alloys, CE, melt, print window) · robotics (arms, torque, reach, payload) · machines (engines, gears, printable parts) · optics (geometry, gnomon, shadows, sundials) · sky (sun position / ephemeris)

How it works

anvil.forge — readIntent scores your words against per-domain keyword sets, picks a domain, and forgeOffline builds a schematic graph (nodes, edges, physical params) from templates plus your numbers (e.g. "7nm", "5-stage", "0.75 V"). Pure local compute.
anvil.solve — createSolver dispatches to the domain solver (Kirchhoff MNA for silicon, Euler–Bernoulli for mechanical, mass-action for chemistry, …), steps it, and returns a snapshot plus proof metrics — checks with real tolerances and statuses.
anvil.export — blueprint geometry meshed to ASCII STL or OBJ text.

Everything runs in-process. There is no network call anywhere in the default path.

Config

Optional — nothing is required to run:

ANVIL_HOME=~/.anvil   # where saved designs / assets / exports live (default ~/.anvil)

Notes

Any OpenAI-compatible "mouth" (LM Studio, etc.) is a future opt-in, not part of v1. The kernel speaks blueprints, not prose, and that's the point.
anvil.solve returns a deterministic snapshot after N steps of the solver's recommended dt — no wall-clock randomness.
Apache-2.0. See LICENSE.

Available Tools

4 tools

anvil.domainsA

List the 12 simulation domains Anvil supports and what each one simulates.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it discloses the core behavior: the tool is read-only ('List') and states exactly what is returned (the 12 domains plus what each simulates). For a zero-parameter catalog tool there are no side effects, auth requirements, or pagination behaviors left undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with every word earning its place. The verb is front-loaded, the specific count '12' adds precision without bloat, and there is no repetition of schema or annotation content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema listing tool, the description is essentially complete: it states the action, the scope, and the return content. The absence of an output schema is compensated by the description's explicit statement of what will be returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline of 4 applies; there is nothing for the description to document. The schema asserts an empty object (additionalProperties: false) and the description adds the only other semantic worth knowing: the nature of the returned data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('List'), a specific resource ('the 12 simulation domains Anvil supports'), and the content of the result ('what each one simulates'). The count '12' adds precision, and the informational nature clearly separates it from the action-oriented siblings (forge, solve, export).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the discovery/catalog tool to call when it needs to know which domains exist before running a simulation. However, there is no explicit when-to-use guidance and no mention of alternatives such as anvil.solve for the actual computation, so the agent must infer the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anvil.exportA

Export a blueprint's geometry as STL (ASCII) or OBJ text for 3D printing / CAD.

ParametersJSON Schema

Name	Required	Description	Default
`format`	Yes		stl
`blueprint`	Yes	Anvil blueprint: a schematic graph for one domain.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the output form ('STL (ASCII) or OBJ text') and implies a non-mutating export operation, but it does not explain error behavior, authentication needs, or whether the result is returned inline or as a file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence containing action, resource, output formats, and purpose. There is no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no output schema and no annotations, the description covers the essential behavior and output format but omits details such as return shape, handling of scale/units, and error conditions. It is adequate for basic invocation but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 50% schema description coverage, the tool description adds some value by mapping the 'format' enum to STL/OBJ and by indicating that the 'blueprint' parameter is the source of geometry. However, it does not explain how the blueprint's nodes, edges, or scale are converted into geometry beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Export'), a specific resource ('a blueprint's geometry'), and concrete output formats ('STL (ASCII) or OBJ text'). It also names the use case ('3D printing / CAD'), which clearly differentiates it from sibling tools that create, list, or solve things.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for 3D printing / CAD' gives clear context for when this tool should be used. It does not explicitly name alternatives or exclusion cases, but the intended use case is unambiguous enough for an agent to route to it correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anvil.forgeB

Forge a simulation blueprint from a plain-language intent. Fully offline — an intent kernel maps your words to a domain schematic (nodes, edges, params), no LLM involved.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	No	Optional domain hint; otherwise the kernel picks from the intent text.
`intent`	Yes	Plain words, e.g. "a simple RC low-pass filter" or "alloy of copper and tin".

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does add useful behavioral context: 'Fully offline' and 'no LLM involved' tell the agent this is a deterministic keyword/pattern-mapping tool, not a semantic engine — so complex or unusual phrasing may fail to map. However, it doesn't disclose failure behavior (what happens when the kernel cannot map the intent), the reversibility of the operation, or limitations of the mapping quality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with zero wasted words. Purpose is front-loaded ('Forge a simulation blueprint from a plain-language intent'), followed by the key behavioral constraint ('Fully offline — no LLM involved') and the output shape (nodes, edges, params). Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description must compensate. It does partially — mentioning the output structure (nodes, edges, params) gives agents a picture of the return value. But it omits failure modes (kernel mapping misses), error behavior, and any quality caveats about the mapping, which matter for an offline keyword-driven tool where free-form intents may not resolve.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters well-documented (domain lists a 12-value enum and its optional-hint semantics; intent includes concrete examples like 'a simple RC low-pass filter'). The tool description adds nothing beyond the schema — it only restates that words map to a schematic, which is consistent with intent's semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Forge') and resource ('simulation blueprint') and describes the mechanism ('maps your words to a domain schematic (nodes, edges, params)'). The purpose is clear and distinct from siblings anvil.domains, anvil.solve, and anvil.export, though it never names them explicitly. Loses a point for not drawing the sibling contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus anvil.domains, anvil.solve, or anvil.export. No exclusions, no conditional routing, no statement of what scenarios this tool is for vs. the others. The only usage hint is in the schema's domain description ('Optional domain hint'), which concerns parameter selection, not tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

anvil.solveA

Run the 12-domain physics solver on a blueprint and return a simulation snapshot plus proof metrics (pass/warn/fail).

ParametersJSON Schema

Name	Required	Description	Default
`steps`	No	Solver steps of recommended dt to run before snapshotting.
`blueprint`	Yes	Anvil blueprint: a schematic graph for one domain.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does disclose that the call is a solver run and that it returns a snapshot plus pass/warn/fail metrics, which is useful behavioral information. However, it does not state whether the call is read-only, whether the blueprint is mutated, or how failures manifest at runtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is one dense sentence with the action and resource front-loaded and the key output types at the end. There is no filler, no repeated schema text, and the proof-metric parenthetical adds compact, useful detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with a rich nested blueprint schema, the description plus schema covers the input side well, and the return value is summarized despite there being no output schema. It lacks an explicit safety/side-effect statement and more detail on proof-metric semantics, so it does not reach 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3: the schema already documents 'blueprint' as an Anvil blueprint and 'steps' with default/min/max semantics. The description only restates that a blueprint is the input and adds no meaning beyond the schema for either parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Run'), names the resource ('the 12-domain physics solver'), and specifies the input ('a blueprint') and outputs ('simulation snapshot plus proof metrics'). This makes it easy to distinguish from sibling tools like anvil.forge, anvil.domains, and anvil.export.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Run the 12-domain physics solver on a blueprint' establishes a clear context for when the tool applies, and the mention of proof metrics suggests it is the right choice when validation evidence is needed. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 26, 2026
- First observedanvil.domains
- First observedanvil.export
- First observedanvil.forge
- First observedanvil.solve

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-09-26 04:35 across 4 tools

Disambiguation5/5

Each tool has a unique, clearly defined responsibility: forge creates blueprints, domains lists available simulation types, solve executes the simulation, and export converts geometry to standard formats. There is no overlap or ambiguity between these four actions.

Naming Consistency5/5

All tool names follow a strict pattern of lowercase single words prefixed with 'anvil.', creating a consistent namespace. The verbs (forge, solve, export) are clear actions, and 'domains' acts as a noun but follows the same stylistic format, maintaining uniformity.

Tool Count5/5

Four tools is an ideal scope for this server's purpose—covering the full pipeline of intent-to-simulation-to-export without redundancy or bloat. Each tool serves a necessary, non-overlapping function in the workflow.

Completeness5/5

The toolset provides a complete lifecycle: discovery (domains), creation (forge), execution (solve), and output (export). There are no missing steps for the stated purpose; it covers all necessary operations from intent to deliverable.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OwlCADOAuth
com.owlcad
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Design Tools Developer Tools
1
agentstack-mcp A
io.github.inity13
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Autonomous Agents Agent Orchestration
241
metamodel A
io.github.joegra2003
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Developer Tools AI & Machine Learning
42
kernelcad A
com.kernelcad
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Design Tools Developer Tools
54225

Related MCP Servers

simple-3d-modeling-mcp
Design Tools Image & Video Processing
mazzanfar
A
license
A
quality
C
maintenance
Enables to create, iterate, and export 3D models through natural language conversations with an LLM by bundling OpenSCAD via WebAssembly for zero-setup 3D modeling.
Updated 3 months ago (2026-06-24 01:20 UTC)
10
42 npm
3
GPL 2.0
cad-mcp-server
Design Tools
mattmohandiss
A
license
Not graded
quality
A
maintenance
Give your AI assistant the ability to inspect, measure, and compare 3D CAD models by dropping in a STEP file and asking engineering questions. Runs entirely on your machine with no cloud, no CAD license, and no setup.
Updated 13 days ago (2026-09-13 22:38 UTC)
109 npm
5
MIT
mcp-fea
Agent Orchestration Developer Tools
benchwire
A
license
Not graded
quality
B
maintenance
Enables real finite element analysis from natural language: accepts STEP geometry and plain-English questions, validates setups deterministically, meshes and solves with CalculiX on Modal, and returns engineering verdicts (stress, safety factor, deflection, modal frequencies) with rendered plots and an interactive 3D viewer.
Updated 2 months ago (2026-07-31 19:05 UTC)
2
Apache 2.0
lucad
Ngoctrong102
A
license
Not graded
quality
B
maintenance
Enables agent-assisted CAD engineering, allowing users to create, validate, and export CAD designs through natural language, with a deterministic engine that has zero LLM runtime dependency.
Updated a month ago (2026-08-14 08:35 UTC)
Academic Free v1.1