FASTMEAN MCP

Overview Schema Source Related Servers Discussions Admin

fastmean_create_project

Creates portable native root and fixed numeric subcircuit files from a JSON spec, returning .scm schematics, original specs, hashes, and a manifest for schematic project generation.

Instructions

Create a portable native root circuit and fixed numeric subcircuit files.

spec={name?,models:{MODEL:{pins:{Left:[B],Top:[C],Right:[],Bottom:[E]}, circuit:{components:[...],ports:{B:b,C:c,E:e}}}},circuit:rootCircuit}. X components use {kind:X,name:Q1,model:MODEL,connections:{B:base,C:col,E:0}}. Side lists determine native terminal numbering Left,Top,Right,Bottom. A definition may float; ports must match declared pins exactly. All models must exist and be acyclic; instance parameters and .parameter headers are unsupported. Other components use the create_circuit schema. Each circuit supports compact/standard density and explicit coordinates independently. Return main.scm, models/*.scm, original JSON specs, hashes and a manifest. To edit definitions, modify the saved project.spec.json and call this tool again: every call creates a new project and preserves the previous files. Does not launch FASTMEAN, calculations, GUI or desktop automation.

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_project"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No		project
`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

A3.7/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false. The description adds genuinely non-obvious context beyond those hints: every invocation creates a new project while preserving prior files (explaining the non-idempotent behavior), what files are emitted, and an explicit list of side effects the tool does not perform. That is real added value on top of the structured hints.

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 critical scoping statement is front-loaded, which is good, but the body degenerates into a dense run-on block mixing schema syntax, constraints, and lifecycle rules without headers or hierarchy. Every clause carries information, yet the presentation makes the spec grammar hard to parse on first read.

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?

An output schema exists, so the return-value sentence is somewhat redundant, but the description still covers the parts structured fields cannot: the nested spec grammar (0% schema coverage), the edit-by-rerunning lifecycle, and explicit non-goals. For a complex project-creation tool with a free-form object argument, this is close to complete despite the gaps around the 'name' parameter and full component schema.

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 spec parameter is a free-form nested object, so the description must carry the burden, and it largely does: it spells out the models/pins/circuit/ports shape, means of the B/C/E connection keys, the meaning of Left/Top/Right/Bottom terminal ordering, and constraints (ports must match pins, models must exist and be acyclic, no instance parameters). The 'name' parameter is never discussed, and the spec grammar uses shorthand ellipses ('components:[...]') that leave gaps, so it is strong but not complete.

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?

The opening sentence names a specific verb and a concrete artifact set: 'Create a portable native root circuit and fixed numeric subcircuit files.' That is meaningfully more specific than the tool name alone. It references the sibling fastmean_create_circuit ('Other components use the create_circuit schema') but never states which tool an agent should pick, so sibling differentiation stops short of a 5.

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?

It gives one clear workflow rule — 'To edit definitions, modify the saved project.spec.json and call this tool again' — plus a negative scope statement ('Does not launch FASTMEAN, calculations, GUI or desktop automation'). However, it never says when to use this versus fastmean_create_circuit, fastmean_edit_values, or fastmean_relayout, leaving the main routing decision implied rather than stated.

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