FASTMEAN MCP

Overview Schema Source Related Servers Discussions Admin

fastmean_create_circuit

Create a native .scm schematic in a fresh folder from a node-based JSON circuit specification, including layout, component, and analysis settings.

Instructions

Create a native .scm in a fresh folder from a node-based JSON circuit spec.

Start from fastmean_example. R/C/L values must be positive. Ground is 0. Components connect through physical wires and junctions; ports are external I/O only. Optional spec.layout.placements maps names to {x,y,rotation}; x/y are multiples of 4 and rotation is 0=left/right,1=up/down,2/3=reversed. spec.layout.density is compact (default) or standard. Explicit coordinates stay unchanged; density controls automatic spacing only. ground_style is rail (default) or local. U nodes are [+,-]; I nodes are [from,to]. A single-terminal node gets one short wire and native CON endpoint, without an added electrical load or external PORT. All names used in analysis must be ASCII. Does not open a window. Fixed native primitives: D nodes=[anode,cathode], parameters={Ron,Roff,Uon}; G/VCCS, E/VCVS and F/CCCS use four native-ordered nodes and a numeric value. TR/TRANSFORMER nodes=[p1,p2,s1,s2], dotted pins1/3, n=Np/Ns>0; value=n or parameters={n}. SW/VCSWITCH nodes=[control+,control-,switch1,switch2], parameters={Ron,Roff,Uon,Uoff}, 0<Ron<=Roff, Uoff<=Uon; native hysteresis. See example(kind='flyback') and the guide for polarity and magnetic storage. spec.analysis.transient accepts stop, step and eps (0<eps<=0.1), saved in SCM. Use fastmean_create_project for X subcircuits and portable model files. All44 insertable classes are supported: call fastmean_catalog(detail=true) for nonlinear R/C/L, H, GYR, TR3, TUBE, NMOS_SMALL, NPN, OPAMP_SAT, PWM, PAM1/PAM2, BALMOD, THYRISTOR, MOSFET, LINE, BRIDGE, RS/DFF/JK/RSCLK, NOT/AND/OR/XOR/LATCH/COMP and SUM. Supply parameters by native key; omitted values use explicit adapter templates. Sources also support triangle/PWL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "spec": "<spec>"
    },
    "name": "fastmean_create_circuit"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No		circuit
`spec`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.6.0Oct 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations, the description discloses real behavioral constraints: R/C/L values must be positive, ground is 0, names must be ASCII, 0<Ron<=Roff and Uoff<=Uon, 0<eps<=0.1, coordinates must be multiples of 4, and no window is opened. It does not say what happens if the target folder or file already exists, which matters given idempotentHint=false.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense wall of technical facts that jumps between layout, node conventions, native primitives, analysis, and catalog classes without grouping or headers. Most sentences earn their place given the 0% schema coverage, but the structure is hard to parse and contains a typo ('All44 insertable classes').

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 high-complexity tool with a free-form spec object, the description supplies validation rules, layout semantics, node ordering, and pointers to examples/guides; an output schema exists so return values need not be explained. Remaining gaps are the `name` parameter semantics and failure behavior on an existing folder.

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?

Schema description coverage is 0% and the required `spec` param is a free-form object, so the description carries the entire burden — and it does substantially: spec.layout.placements shape, density, ground_style, spec.analysis.transient fields, node ordering conventions, and validation rules. The `name` parameter (default 'circuit') is never mentioned, and the full spec surface is deferred to example/guide/catalog rather than documented here.

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 opening sentence gives a precise verb and resource: creates a native .scm file in a fresh folder from a node-based JSON circuit spec. It also disambiguates from the most confusable sibling ('Use fastmean_create_project for X subcircuits and portable model files') and from window-opening tools ('Does not open a window').

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?

It names a starting point ('Start from fastmean_example'), a sibling for a different use case (fastmean_create_project), and where to go for advanced components (fastmean_catalog with detail=true). There is no explicit statement of when not to use this tool versus the edit/open family, so it falls short of a full 5.

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