Skip to main content
Glama

spice simulate

spice_simulate

Run a SPICE circuit simulation directly in the worker. Accepts a standard SPICE netlist and performs operating-point (.op), DC sweep (.dc), AC frequency sweep (.ac), or transient (.tran) analysis using a built-in modified-nodal-analysis engine with Newton-Raphson nonlinear solving. Supports R, L, C, V, I sources (DC/AC/SIN/PULSE), diodes, BJTs (Ebers-Moll), MOSFETs (Shichman-Hodges level 1), controlled sources (E/G), .param expressions, .subckt/X hierarchical subcircuits, .measure and .four (Fourier/THD), and a built-in parts library (reference 2n3904/2n2222/1n4148/1n5819/2n7000/tl072/lm358/led_red etc. by name and the model is auto-injected), up to 150 components. Returns voltage vectors for all circuit nodes (magnitude + phase for AC). Use spice_template to generate netlists from parameterized templates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
certifyNoIf true, attach an a-posteriori existence certificate for the DC operating point (Newton–Kantorovich: proves a true solution exists within a computed radius, or refuses). Adds ~one extra back-solve.
netlistYesSPICE netlist (ngspice-compatible). Must include at least one analysis command (.ac, .dc, .tran, .op) and end with .end
optionsNoAdditional ngspice .options (e.g. { reltol: 0.001 })
analysisNoOverride analysis type (auto-detected from netlist if omitted)
tolerancesNoComponent-tolerance box, e.g. {"R1":0.05,"V1":0.02} (fractional). With output_node, returns a certified min/max interval for that node over all component variations. R/V/I elements only.
output_nodeNoNode whose voltage is certified over the tolerance box (required with tolerances).
temperature_cNoSimulation temperature in Celsius

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodesYesList of circuit node names
fourierNoPresent when the netlist has .four cards: Fourier harmonics + THD per node
vectorsYesNamed voltage/current vectors keyed by node name
measuresNoPresent when the netlist has .measure cards: {name: value}
warningsYesAny ngspice warnings generated during simulation
runtime_msYesSimulation wall-clock time in milliseconds
certificateNoPresent when certify=true: {certified, rho, eta, h, ...} existence certificate for the DC operating point
analysis_typeYesAnalysis type that was performed
component_countYesNumber of components in the netlist
tolerance_certificateNoPresent when tolerances+output_node given: {certified, interval, nominal, ...} certified output range over the component-tolerance box

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so description carries the burden. Details the built-in engine, supported components (diodes, BJTs, MOSFETs, etc.), analysis types, and optional certification features. Implicitly hints at potential convergence issues via 'Newton-Raphson nonlinear solving'.

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

Conciseness4/5

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

Description is detailed but efficiently structured, front-loading the core purpose. Could be slightly more concise, but every sentence adds value.

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?

Given the complexity of the tool, the description covers supported components, analyses, options, and certification. Output schema exists, so return values need not be detailed. Sufficient for an agent to select and invoke.

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 coverage is 100%, and the description adds context like auto-detection of analysis and reference to spice_template, but does not significantly elaborate beyond schema for each parameter. Baseline 3 is appropriate.

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?

Clearly states 'Run a SPICE circuit simulation directly in the worker' and lists supported analyses and components. Distinguishes itself from sibling tool spice_template by advising its use for netlist generation.

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?

Provides when-to-use context for simulation tasks and references spice_template as an alternative for netlist generation. Does not explicitly state when not to use this tool, but the description is sufficient for typical use cases.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Despite 89 tools, each has a clearly distinct purpose with detailed descriptions that often reference related tools. Overlap exists (e.g., multiple LoRa/RF tools), but the descriptions are sufficient to distinguish them. Some confusion possible among similar-sounding tools like attenuator_pi and attenuator_tee, but the descriptions explicitly compare them.

Naming Consistency4/5

Consistent underscore-separated lowercase naming. Most tools follow a verb_noun pattern (e.g., capacitor_charge, wire_gauge) or noun_noun (power_cost). Minor inconsistencies such as 'bmi_calculator' vs 'solar_sizing' but overall predictable.

Tool Count2/5

89 tools is far too many for a single MCP server. This scope is more appropriate for multiple specialized servers. The sheer number will slow agent selection and increase cognitive load, reducing coherence.

Completeness3/5

Covers many domains (RF, solar, PCB, networking, math, etc.) but lacks depth in some areas (e.g., no three-phase power, no airflow calculations). Some domains have comprehensive coverage (LoRa/Meshtastic), but others feel incomplete for the tool count.

Resources