The ltspice-mcp server connects LLM assistants to real SPICE circuit simulators (LTspice, ngspice, QSPICE, Xyce) for full design-simulate-iterate workflows on actual circuit files.
Simulation & Job Management
Run simulations on .cir, .net, or .asc files (transient, AC, DC, .op, noise); short runs complete synchronously, long runs return a job ID for async tracking
Check, cancel, and recover jobs; state persists across server restarts
Validate netlists statically before simulation
Waveform & Result Analysis
Signal statistics (mean, RMS, min/max, peak-to-peak), value queries at specific time/frequency points, full CSV waveform export, interactive HTML charts, and simulation summaries (.MEAS results, Fourier, warnings)
Time-Domain Measurements
Rise/fall time, slew rate, overshoot/undershoot, settling time, propagation delay, period/frequency/duty cycle/jitter, THD
Frequency-Domain & AC Analysis
Bode metrics (filter type, cutoffs, slope, crossings), stability margins (all phase/gain margin crossovers), resonance detection (Q factor, bandwidth), noise integration, pole/zero structure, return loss/VSWR
DC Operating Point
All node voltages, branch currents, and per-device small-signal parameters (gm, gds, vth, etc.) for LTspice and ngspice
Sweeps & Monte Carlo
Multi-dimensional linear/log parameter sweeps and Monte Carlo analyses with component tolerances, .MODEL process variation, and Pelgrom MOSFET mismatch
Aggregate results: mean/std/min/max/median/histograms across runs; per-run raw data and convergence warnings
Schematic & Netlist Editing
Create, read, and modify LTspice .asc schematics and SPICE .cir/.net netlists
Add/move/remove components, wire pins (orthogonal routing with collision checks), add net labels/ground flags, set attributes and .PARAM values, add/remove directives
Batch multiple schematic operations in a single transaction; revert to pre-session snapshot
Auto-generate schematics from netlists; export schematics to netlists via LTspice
Trace nets (connection inspection, short detection) and diff circuits structurally
Library & Model Management
Fuzzy/exact search for SPICE models and subcircuits across loaded libraries
Load/unload .lib/.mod files or directories; list libraries with model enumeration
Server & Session Management
Server status (detected simulators, sandbox paths, configuration), recent circuits/jobs with interrupted-job recovery, symbol/component introspection (pin positions, bounding box, attributes)
Provides tools for circuit simulation, schematic editing, and analysis using LTspice, including transient, AC, DC, Monte Carlo, and parameter sweep analyses with structured numeric results.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ltspice-mcp Check the phase margin of this op-amp circuit."
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.
WIP 0.6.0 was a breaking release: the tool surface consolidated to six operations plus a waveform widget and a code runner, and the same engine became importable as a Python API. Pin
ltspice-mcp==0.5.*if you need the old 49-tool surface.
ltspice-mcp lets LLM assistants run LTspice and ngspice simulations and edit LTspice .asc schematics. It returns structured measurements such as cutoff frequency, overshoot, phase margin, rise time, and per-device small-signal operating-point parameters (gm, gds, vth, …). Callers access these values by name without parsing raw files. It works on the same files you open in LTspice. Built on spicelib.
Claude Code — two commands, and the tools are there in your next session:
/plugin marketplace add cognitohazard/ltspice-mcp
/plugin install ltspice-mcpClaude Desktop — build the extension in packaging/mcpb/
and drag the .mcpb file onto Claude Desktop. It installs in one click and
asks which folder your circuits are in.
Any other MCP client — Cursor, Windsurf, Gemini CLI, Continue, Cline, Zed and others. Install the server, then add it to that client's MCP config file (each client's own docs say where that file lives):
uv tool install ltspice-mcp # or: pipx install ltspice-mcp{
"mcpServers": {
"ltspice": { "command": "ltspice-mcp", "args": [] }
}
}Needs Python 3.11 or newer; ltspice-mcp --help confirms it installed. In
Claude Code you can skip the JSON with
claude mcp add -s project ltspice -- ltspice-mcp. The same server is also
published as circuit-mcp and ngspice-mcp — same program, in case one of
those names is easier to remember.
You also need a simulator on the same machine. LTspice or ngspice —
auto-detected on Windows, Linux and macOS; on WSL you point at LTspice
yourself (WSL notes). Install LTspice if you can: .asc
schematic work needs its symbol libraries. Reading and checking netlists works
with no simulator at all. The plugin and the extension fetch the server for
you, so those two routes need uv installed.
If your assistant ignores it. Some clients don't show an assistant what a
tool does until it picks one, so it may reach for the command line instead.
Start with the name: the assistant sees every tool prefixed with it
(mcp__ltspice__run_experiments), so a name carrying the domain reads as a
SPICE tool even before anything else loads. That name is the key in the JSON
above, or the word after claude mcp add; the plugin and the extension already
use ltspice. If yours is something like sim1, rename it. Then say so
outright, in your project's CLAUDE.md (or whatever your client calls it):
Always use the ltspice MCP server for any SPICE/circuit simulation, sweep, or analysis. Do not invoke ngspice or LTspice from the shell, and do not hand-parse
.rawfiles orwrdataoutput.
That rule is absolute on purpose. An assistant invited to weigh it up will usually reach for the shell it already knows, which is the behaviour you are trying to correct. If you would rather it judge case by case, when to shell out instead gives the real boundary.
Related MCP server: ltspice-mcp
Once connected, you ask for circuit work in plain language. The assistant designs the circuit and decides what to measure; the server runs the simulator, parses the binary output, and returns the numbers. You and the assistant decide whether the results are acceptable.
"Bias this NMOS common-source stage into saturation at the target drain current and report gm/ID."
The assistant writes the netlist, solves the bias point on LTspice, and reads the device's operating point back by name — drain current, gm, gds, VDS against VDSAT to confirm it's in saturation, and the gm/ID that analog designers size to. If the bias is off, it adjusts the gate reference or W/L and re-runs, a couple of seconds per pass.
Other requests that work the same way:
"What's the overshoot and settling time of this regulator's step response?" — runs a transient analysis and measures both from the waveform, plus rise time, ringing frequency, and the final value.
"Run a 200-run Monte Carlo with 5% resistors and tell me the output spread." — perturbs components per run, simulates the batch, and reports mean, sigma, and worst-case values per measurement.
"Sweep the load from 100 Ω to 10 kΩ and find where efficiency drops." — parameter sweep with per-run results.
"Characterize this NMOS: gm and gm/ID vs VGS." — writes a .dc Vgs deck with .save @m1[gm] @m1[id], runs it on ngspice, and returns the gm/ID table as one CSV (no .control block, no rawfile parsing).
"Find an N-channel power MOSFET for a low-side switch and measure the on-state drop." — searches the libraries the deck pulls in for a part (inspect(kind="model")), puts it into a pulsed-gate transient, and reads Vds(on) and load current back from the .meas results.
"Build this differential pair as a schematic I can open in LTspice." — places and wires the components into a real .asc, with orthogonal routing and pin-collision checks.
"Is this loop stable?" — AC analysis of the loop gain; reports phase and gain margin at every crossover, not just the first.
"What's the resonant frequency and Q of this series RLC?" — runs an AC sweep and reports each peak's center frequency, Q, and −3 dB bandwidth.
Warnings are returned with the measurements they affect. A simulator such as ngspice can report a "singular matrix" warning in its log and still finish the run and write plausible values. The server includes that diagnostic in an observations field next to the returned value.
Everything operates on ordinary LTspice and SPICE files. You and the assistant can edit the same files:
Sketch a schematic in LTspice, then ask the assistant to work on it: "what's the bias point?", "why doesn't the output move?", "add compensation and check the phase margin."
Or the reverse: the assistant designs and verifies the circuit and writes the .asc; you open it in LTspice, inspect it, and tweak by hand. Your manual edits are simply the file's new state, which the assistant reads on the next request.
Either of you can change the file mid-design: adjust a value in the GUI and ask for re-verification, or have the assistant sweep a change you're considering before you commit to it.
The rule in the quick start forbids the shell outright, which is the right default for an assistant that would otherwise never find the server. The real boundary is narrower, and it matters if you drop the rule.
An agent with a shell can run quick one-off ngspice simulations directly. Local ngspice runs are scriptable and usually take under a second, so MCP adds little in that case. Use the server when you need LTspice execution, named values parsed from binary raw files, declared sweep and Monte Carlo matrices with durable idempotent submission, jobs that outlive a call, or geometry-checked .asc editing. analyze_results can also read a bare raw_path produced outside the server, so a simulation can run in the shell and be analyzed here.
Simulation and measurement. Runs LTspice or ngspice and parses the binary output directly. Measurements are computed server-side and returned as numbers: time-domain (rise/fall, overshoot, settling, delay, period/duty/jitter, RMS, THD), frequency-domain (filter cutoffs and roll-off, gain and phase at any frequency, stability margins, resonance peaks with Q, integrated noise), DC operating points, and .MEAS directive results including the ones that failed. Per-device small-signal operating-point parameters (gm, gds, vth, …) come back by name on both simulators — LTspice via an auto-added .options logopinfo block in the log, ngspice via .save @dev[param] traces. Read the set across a .dc sweep as a gm/ID table with the waveform recipe in format: "csv", or a single bias point with the operating_point recipe (address them as m1.gm / @m1[gm], no rawfile parsing).
Schematic editing. Creates and edits LTspice .asc files by placing components, wiring pins, and labeling nets. It rejects wires that collide with pins, overlap junctions, or run diagonally, and reports floating pins and dangling labels. Every edit to a file that already exists carries that file's expected_sha256; if the file changed since you read it, the call is refused and nothing is written. Plain netlists (.cir/.net/.sp) are read and checked rather than edited — you write them with your own file tools, and a static validation pass catches malformed cards before simulation begins.
Sweeps and Monte Carlo. Multi-dimensional parameter sweeps and Monte Carlo with per-component tolerances, .MODEL process variation, and Pelgrom W·L device mismatch. Per-measurement statistics are aggregated across runs, and any single run can be pulled out and analyzed like a standalone simulation.
Jobs and trust. Simulations run as cancellable jobs with timeouts and a concurrency cap; long runs return a job ID immediately and job state survives a server restart. Results include simulator warnings, missing measurements, and extreme node values as structured observations. The server does not assign a trust rating; the caller evaluates these observations.
Simulator | Status |
LTspice | Primary. Windows native, WSL2 (Windows LTspice.exe via interop), Linux via Wine. Required for |
ngspice | Supports simulation, parsing, diagnostics, and analysis. Does not require LTspice. |
QSPICE, Xyce | Supported but secondary. |
No configuration is required. To customize, copy ltspice-mcp.example.toml to ltspice-mcp.toml; any setting can be overridden with an LTSPICE_MCP_-prefixed environment variable, and --config PATH or LTSPICE_MCP_CONFIG picks the file. Key options:
[simulator]
default = "ltspice" # ltspice, ngspice, qspice, xyce (null = auto-detect)
path = "" # explicit executable path (required on WSL)
ngbehavior = "hsa" # ngspice compat mode; unset = spicelib default, "hsa" fixes sectioned .lib corner select
[security]
# allowed_paths = ["."] # sandbox; unset = working dir + the Claude Code scratch dir (<tempdir>/claude-<uid>)
[simulation]
# max_parallel = 4 # default: number of CPU cores, capped at 8
timeout = 300.0 # seconds
[tools]
listing = "compact" # "full" serves every per-argument description on the wire, about 45% more to load
run_code = true # false removes run_code; the snippet has the server's own authority, not the sandbox
[state]
persist_jobs = truelisting = "compact", the default, keeps about 45% off what a session loads before it can call anything; the tools accept exactly the same calls, inspect(kind="reference", query="...") looks up a branch's arguments with their descriptions when you need them, and a rejected call ends with the branch's field table. listing = "full" puts every description back on the wire.
run_code, on by default, runs a Python snippet in a worker process holding the engine as api (the same six ops as methods, complete results), for loops over runs and numpy on samples. The snippet runs with the server process's own file and process authority, not inside allowed_paths: permission mcp__ltspice__run_code in your client the way you permission a shell, and never blanket-allow it as part of mcp__ltspice__*. Set run_code = false when the server is reachable by more than one trusted client, for example through a proxy in front of it; the change takes effect at the next start, and inspect(kind="capabilities") reports whether the tool is on.
See src/ltspice_mcp/config.py for the full option list ([analysis], [schematic], [logging], ...).
On WSL, LTspice.exe runs via Windows interop (not Wine), and spicelib can't auto-detect it across the WSL boundary. Set the Windows-side path explicitly:
[simulator]
path = "/mnt/c/Program Files/ADI/LTspice/LTspice.exe"Simulation output is automatically redirected to a Windows temp directory: LTspice's .MEAS results go through SQLite .db files that fail on UNC paths (\\wsl.localhost\...), and without the redirect measurement data silently disappears from the logs.
.asy symbol paths for .asc editing are auto-detected on Windows and WSL; override with [schematic] symbol_paths or LTSPICE_MCP_SYMBOL_PATHS.
The server exposes 8 tools: six arranged over three planes, the waveform widget, and run_code, which is registered always and served unless the operator turns it off:
Plane | Tool | What it does |
Execute |
| Run one deck, or a grid of value assignments, model swaps, and Monte Carlo runs, in one declarative call — optionally returning the measurements with the receipt |
Execute |
| Follow, wait on, cancel, list, or page the runs of a submitted job |
Understand |
| Measure a finished job (or a bare |
Understand |
| Read decks, schematics, symbols, nets, models, and server capabilities — never results |
Author |
| Create and mutate |
Author |
| Syntax, symbol, layout, and quality checks, schematic-vs-netlist equivalence, and rendering |
— |
| Interactive chart of a run's waveforms, in-chat where the client renders widgets, otherwise opened on your desktop |
— |
| Run a Python snippet in a warm worker that holds the engine as |
Netlists are written and edited with the agent's own file tools; the server does not wrap text edits. The same six operations are importable as ltspice_mcp.api (Api(working_dir=...)), so a Python script can drive the same engine without an MCP client.
The skills/ directory carries the domain knowledge that pairs with the surface: skills/spice-experiments/SKILL.md (the experiment workflow), skills/ltspice/SKILL.md and skills/ngspice/SKILL.md (SPICE syntax per engine), skills/spice-bench-craft/SKILL.md (bench archetypes). Copy the relevant skill into your client's persistent-instructions location.
Migration from 0.5. The full (49-tool) and agentic (41-tool) profiles were removed in 0.6.0; the consolidated surface above replaces them. [tools] profile is no longer a key the server reads — a config that still sets it loads with the key ignored. Keep the [tools] section rather than deleting it: it now holds listing, above. Pin ltspice-mcp==0.5.* if you need the old per-operation tools.
Where it runs. The server shells out to a local LTspice/ngspice and reads circuit files from disk, so it must run where the simulator and the files are. Two setups work: a local MCP host (Claude Desktop, Claude Code, Cursor, Gemini CLI, Codex, …) on your own machine, or a browser-based cloud agent whose sandbox can install ngspice and register the server (verified with Claude). LTspice is local-only (a Windows app); ngspice is open-source and works in either place. Consumer web chat with no sandbox has no simulator and no file access, so it can't run this server directly; bridge it to a machine you control with a stdio→HTTP bridge such as mcp-proxy if you want that UI. Only expose the server on a network you fully control: it writes files and spawns processes inside allowed_paths.
You can use the same six operations as an MCP server or as a Python API. Both run the same engine: the same code handles each operation, reads the same files, and writes the same job records to disk.
MCP server | Python API | |
Who calls it | an assistant in Claude Code, Claude Desktop, Cursor, or another MCP client | a script, notebook, or CI job — usually one an assistant wrote |
What a call looks like | a tool call in the conversation; large results are split into pages and continued with a cursor | a method call; results are returned in full, with waveforms as numpy arrays |
Long runs | the server keeps the job running; check on it with | the process owns the job; |
Good for | interactive work: explore, edit, run a few checks per turn | code: optimizers, custom post-processing, pipelines, full result sets |
A sweep or Monte Carlo matrix is one call through either interface. Use the
Python API when each run depends on code that processes the previous result,
such as an optimizer, curve fit, or CI check. The API returns the complete
result set, while MCP paginates large results. Both interfaces use the same
working directory and job records. An assistant can start a sweep over MCP,
and a script can read the completed job by its job_id. A script can also
run a batch for an assistant to analyze later.
An assistant can use either. Over MCP it calls the six tools; where it can
execute code it can drive the same engine in Python instead, through run_code
or an installed package (see below). Either way it can read the full argument
tree for itself — inspect(kind="reference") over MCP, api.reference() in
Python.
To write your own script against the engine, or to have an assistant write one that outlives the conversation, install the package:
pip install ltspice-mcp # or: uv add ltspice-mcpThis is a separate step from the quick start. The plugin and the Desktop
extension run the server in an environment of their own, so neither one puts
the package where your code can import it. An assistant working inside a
session does not need this install to write Python against the engine —
run_code runs its snippet in the server's own process, with api already
bound — but a standalone script does.
from ltspice_mcp.api import Api
with Api(working_dir="circuits") as api:
result = api.run_experiments(
circuits=[{"path": "rc.cir"}],
variations=[{"kind": "assign", "assign": {"R1": ["1k", "2k", "4k"]}}],
analyze={"recipes": [
{"key": "fc", "metric": "bode_filter", "signal": "V(out)",
"field": "cutoff_high_hz", "reduce": ["min", "max"]},
]},
)
print(result["analysis"]["result"]["results"]["fc"]["reduced"])run_experiments defines a three-case sweep, measures each case, and returns
the minimum and maximum cutoff frequencies with their assignments. rc.cir is
the RC low-pass deck printed under
the tool-level loop above.
api.reference() lists the six operations. api.reference("run_experiments")
prints that operation's full argument tree. From a shell, use
python -m ltspice_mcp.api reference [op]. api.load_raw() returns numpy
arrays for direct waveform access.
The two run side by side. The MCP server is the long-lived process: it owns jobs that must outlive a call, serves the
packaged guide and job resources, and renders the waveform widget on hosts
that support it. A script using the Python API works in the same directory
against the same job records, so a job started by either can be read by the
other by its job_id. A job the script submits belongs to the script, and
exiting cancels it — unless it asks for a detached owner
(run_experiments(wait=False, detach=True)), which hands that one job to a
process spawned to supervise it. The script can then exit, and the job, the
server and any later script all still see the same record.
Api starts the same engine in the caller's process and does not require an
MCP server. Its interface differs from MCP:
Complete results. Large MCP responses may be paginated or capped. The API collects every page and returns the complete result. It rejects MCP-only controls such as response budgets, pagination cursors, and wait dwells instead of rewriting them. This keeps replayed calls consistent between MCP and Python.
The Python process owns its jobs, unless you detach them.
run_experiments(wait=False) returns a receipt immediately, and unfinished
jobs are cancelled by api.close(), at the end of a with block, or during
normal interpreter shutdown. Adding detach=True gives that job its own
supervising process instead: the call still returns as soon as the
submission is durable, the receipt names the owner and its log, and the job
runs on after this process exits. Read it back or cancel it later by
job_id, from here, a later script, or a server.
One live engine per process. An Api created inside a running server
process raises an error. A cold Api() starts in well under a second; the
heavy imports are loaded by the first call that needs them.
api.load_raw() / api.measurements() return numpy-backed data for your
own post-processing, and api.reference(op) prints any operation's full
argument tree.
What the assistant actually does for "design a 1 kHz RC low-pass and verify it". It writes the netlist (R=1k, C=159.155n → fc = 1 kHz):
* rc.cir — RC low-pass
V1 in 0 AC 1
R1 in out 1k
C1 out 0 159.155n
.ac dec 50 1 1Meg
.endthen drives two tools:
verify_circuit(path="rc.cir", checks=["syntax"])
→ outcome "complete", no findings: directives valid, element arities check out
run_experiments(
circuits=[{"path": "rc.cir"}],
analyze={"recipes": [{"key": "lp", "metric": "bode_filter", "signal": "V(out)"}]},
)The lp recipe returns these scalar results:
{
"signal": "V(out)",
"filter_type": "lowpass",
"passband_gain_db": 0.0,
"passband_ripple_db": 0.02,
"cutoff_low_hz": null,
"cutoff_high_hz": 1000.4,
"stopband_rejection_db": 59.97,
"rolloff_slope_db_per_decade": -19.9,
"estimated_order": 1,
"warnings": []
}(abridged — the full response also includes passband bounds and transition bandwidth)
If the result is off target, edit the netlist, run it again, and repeat the measurement. Long simulations return a job ID instead of blocking. Use jobs with action="status", action="wait", or action="cancel" to manage them. Job metadata persists in per-circuit sidecars ({dir}/.ltspice-mcp/jobs/ — add .ltspice-mcp/ to your .gitignore), and MCP resources (spice://results/..., spice://netlists/..., spice://config) expose jobs, signals, measurements, and config for browsing.
Every tool declares MCP annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and an outputSchema for structuredContent introspection. The capabilities live one level down, as the named values each tool accepts:
Surface | Values |
|
|
|
|
|
|
|
|
|
|
Sweeps and Monte Carlo are not separate tools: they are run_experiments variations, of which there are two kinds.
assign sets values — a grid across entries, or lock-step lists within one entry. A target is a declared .param, a component reference (so a supply level is an assignment to the source's value), REF@model, which swaps one device's model card, or X1:delvto, a per-instance offset on the FET inside a subcircuit instance. That model swap is what "corners" means here.
random adds Monte Carlo runs: component tolerances, .param and .MODEL parameter spread, and Pelgrom W·L device mismatch.
There is no temperature axis. Temperature is a simulator setting, so it goes in the deck (.temp, .step temp, .options temp=); a .param TEMP is rejected by the deck lint, because SPICE never reads it as the simulation temperature and every point of such a sweep would solve at the same temperature.
Three published studies by other groups support the main design choices.
Measurements come back as named numbers. SPICEAssistant (Nau, Krummenauer, Zimmermann, arXiv:2507.10639) hands the model scalar LTspice results instead of raw output, and reports o3's solve rate on a 269-task power-supply benchmark rising from 25.4% to 84.9%, against 18.7 points for retrieval-augmented prompting alone. Here the measurement recipes return scalars and plot_waveform is for shape.
Schematic edits are typed and validated. NetlistBench (Ma et al., arXiv:2608.12197) put 2,342 LLM netlist edits through a benchmark: for the strongest model, accuracy on compound edits fell from 80% at 3 dependent steps to 26% at 15, and the authors conclude models should not be relied on as netlist editors without verification. It measured unassisted edits on text netlists, so this is a response to that finding rather than a measured fix for it: edit_schematic takes a batch of typed operations, validates before writing, and returns the resulting geometry, and verify_circuit compares the schematic against an exported netlist.
The tool interface is typed. An RTL-to-GDS agent benchmark (arXiv:2607.17528) attributes 31.7% of physical-design errors to tool-interface failures: valid commands defeated by tool state or version. Different domain, so it is supporting context rather than evidence; its recommendations — registered APIs, persistent sessions, structured results instead of log parsing — are what the server does.
uv sync # install runtime + dev dependencies
uv run pytest tests/ -v # tests
uv run pyright # type checking
uv run ruff check src/ tests/ # lint
uv run ltspice-mcp # run the server (stdio)Release with scripts/release.sh 0.6.2. The script refuses a dirty tree or a version with no dated CHANGELOG.md section, stamps the plugin manifests, commits, and creates an annotated tag. The package version comes from hatch-vcs. Push the tag to publish to PyPI.
More: docs/DESIGN.md (scope, architecture, non-goals) and docs/spice_lex.md (SPICE parser internals).
The tool-surface and Python API contracts are in docs/design/, the architecture in docs/DESIGN.md, and the test practice in docs/TESTING.md. Vendored components are listed in THIRD_PARTY_NOTICES.md. The project is not taking outside contributions at this stage; bug reports with a reproduction are welcome as issues.
GPL-3.0-or-later
Add a new component to an .asc schematic at a specified grid position.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| reference | Yes | Reference designator (e.g., 'M1', 'R3', 'VDD') | |
| symbol | Yes | Symbol name (e.g., 'nmos', 'pmos', 'res', 'cap', 'voltage') | |
| x | Yes | X coordinate (LTspice grid units) | |
| y | Yes | Y coordinate (LTspice grid units) | |
| value | No | Component value (e.g., '10k', 'NMOS_3V3') | |
| rotation | No | Rotation/mirror (PMOS typically M180, NMOS typically R0) | R0 |
| attributes | No | Optional attributes to set (e.g., {'SpiceLine': 'W=10u L=0.5u', 'Value2': '...'}) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| reference | No | |
| symbol | No | |
| position | No | |
| rotation | No | |
| pins | No | |
| bounding_box | No | |
| warnings | No | |
| validation_warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation but no destructive behavior. Description adds no details about error conditions (e.g., duplicate reference), side effects, or need for prior schematic existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence, front-loaded. Efficient but could benefit from a brief note on behavior or response format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and output schema present, description covers basic purpose but lacks constraints, error handling, and output description. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add), the resource (component to .asc schematic), and the positioning (at specified grid position). It distinguishes from siblings like remove_component and move_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., set_component_value, create_schematic). No prerequisites or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a net label or ground flag to an .asc schematic at a wire junction.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| net | Yes | Net name ('0' for ground, or a name like 'VDD', 'outp') | |
| x | No | X coordinate (required unless pin is specified) | |
| y | No | Y coordinate (required unless pin is specified) | |
| pin | No | Component pin reference (e.g., 'M3.S') — places label at the pin's coordinates | |
| action | No | add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context that the label is placed 'at a wire junction' beyond annotations (idempotentHint, non-destructive). However, it lacks details on side effects, error conditions, or behavior of removing a label. Annotations already indicate idempotency and non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently states purpose and resource. Could include brief usage hint but remains front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes core action adequately but misses guidance on coordinate vs. pin usage, action parameter behavior, and no output schema. Sufficient for a simple tool but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but description does not elaborate on parameters beyond schema. For example, 'path' parameter lacks schema description and is not mentioned in tool description. The description ties 'net' parameter to 'ground flag' but adds no new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Add', resource 'net label or ground flag', and context 'to an .asc schematic at a wire junction'. It distinguishes from sibling tools like 'connect' or 'trace_net' by specifying the operation on net labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like 'connect' or 'trace_net'. Does not mention when to use 'add' vs. 'remove' action, nor any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply many .asc edits in one transaction. Loads the schematic once, runs each op against the in-memory editor in order, and saves once at the end. Cuts the typical 25+ tool calls to build a real circuit (add_component × N + connect × N + add_net_label × N + edit_directive × N) down to a single round-trip.
Supported ops (each tagged via the op field): add_component, set_component_value, set_component_attribute, remove_component, move_component, add_net_label, connect, add_directive.
By default, the first op that raises aborts the whole transaction and nothing is written to disk. Set stop_on_error=false to run every op and persist whatever subset succeeded — useful when each op is independent and partial progress is acceptable. Errors are recorded under each op's error field; successes carry the per-op result keys (e.g. wire_count).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| ops | Yes | List of edit operations applied in order against a single in-memory AscEditor. The file is saved once at the end iff every op succeeded (or stop_on_error=false). Each op is tagged by its ``op`` field; see the schema for per-op fields. | |
| stop_on_error | No | When true (default), the first op that raises aborts the transaction and nothing is saved. When false, every op runs and per-op errors are recorded in ``results``; the file IS saved with whatever ops did succeed — set false only when failures are recoverable. |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| applied_count | Yes | |
| failed_count | Yes | |
| saved | Yes | |
| results | Yes | |
| validation_warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses transactional behavior: loads once, applies ops in memory, saves once. Explains error handling (abort on first error vs. continue) and that results include per-op errors. Annotations already indicate mutation, so description adds context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with an opening statement, a list of supported ops, and error handling details. Every sentence contributes useful information, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of batching many ops, the description covers the key behavioral aspects. Output schema likely handles return values, so the omission is acceptable. Could mention prerequisites like file existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by summarizing the ops array structure and the stop_on_error behavior. It contextualizes the parameter semantics beyond the schema's per-op descriptions, such as explaining the transaction concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Apply many .asc edits in one transaction.' It explicitly lists all supported ops and contrasts with the alternative of multiple individual calls, effectively distinguishing it from siblings like add_component and connect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Cuts the typical 25+ tool calls to build a real circuit... down to a single round-trip.' Also explains the stop_on_error flag and when to use false for partial progress, offering clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a batch simulation job (sweep or Monte Carlo). Without signal: returns job status and progress. With signal: returns aggregate statistics or per-run data for that signal.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Batch job ID from run_sweep or run_montecarlo | |
| signal | No | Signal name for per-signal stats (e.g., 'V(out)') | |
| filters | No | Filter runs by parameter values (e.g., {'R1': '10k'}). Applies in both aggregate and raw mode (requires signal). | |
| at | No | Optional time (transient) or frequency (AC) point in SPICE notation (e.g., '1k', '100u'). When given, each run is sliced to a single sample at that point before aggregating. Without this, the per-run peak across the full waveform is used, which conflates startup/roll-off with run-to-run variation on AC sweeps. | |
| offset | No | Pagination offset for raw data | |
| limit | No | Max raw data rows to return (server caps at 50; page with offset) | |
| raw | No | Return per-run raw data instead of aggregate stats | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| job_id | No | |
| job_type | No | |
| status | No | |
| netlist | No | |
| total_runs | No | |
| completed_runs | No | |
| failed_runs | No | |
| mode | No | |
| signal | No | |
| run_count | No | |
| stats | No | |
| max_case_run | No | |
| min_case_run | No | |
| runs | No | |
| pagination | No | |
| convergence_warnings | No | Per-run convergence-fallback markers (Gmin stepping, source stepping, etc.) detected in the per-run logs. Present only when at least one run hit a fallback. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, idempotent=true. The description adds valuable behavioral details: mode switching based on signal, pagination via offset/limit, and the effect of the 'at' parameter on data slicing. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with main purpose. Every word is informative; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (1 required), existing output schema, and the tool's complexity, the description covers essential behavior: two modes, pagination, and parameter interactions. It is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial context beyond the schema. For example, it explains how the 'at' parameter changes aggregation behavior and warns about waveform peak conflation without it. This extra guidance significantly aids parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a batch simulation job (sweep or Monte Carlo). It specifies two modes: without signal returns job status/progress, with signal returns aggregate or per-run data. This specificity distinguishes it from sibling tools like check_job and run_sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the signal parameter vs not, but does not mention when not to use this tool or explicitly list alternatives (e.g., check_job for job status). Usage context is implied but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AC / Bode-plot analysis in one tool, selected by mode. The response shape depends on the mode:
mode='filter' — filter type, cutoffs (at ref_db below passband), passband gain/ripple, stopband rejection, transition BW, pole-order.
mode='slope' — magnitude slope (dB/decade + dB/octave) between f_low and f_high; pick endpoints ≥1 decade past any knee.
mode='point' — magnitude (dB + linear) and phase at each of frequencies (log-axis interpolation; out-of-range clamps + warns).
mode='crossing' — every frequency where quantity crosses level (phase is UNWRAPPED first); the escape hatch for custom queries like unity-gain (0 dB) or phase-margin (-180°) frequencies.
Pass all_steps=true to compute the chosen mode for every step of a .step sweep in one call (returns a steps list instead of a single result) — e.g. the -3 dB cutoff at every value of a stepped component.
To analyze a run of a completed sweep/MC job, pass job_id + run_index instead of raw_file (combine with all_steps to also sweep the .step axis within that run).
For loop-gain stability margins use stability_metrics; for resonant peaks & Q use resonance.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | No | Path to AC analysis .raw result file. Pass this OR ``job_id``, not both. | |
| job_id | No | Analyze a specific run of a completed sweep/MC (or single) job instead of a raw_file path; pair with ``run_index``. Combine with ``all_steps`` to sweep the .step axis WITHIN that run. | |
| run_index | No | 0-based run to analyze when ``job_id`` is given (default 0). | |
| signal | Yes | Signal name (e.g. 'V(out)') | |
| mode | Yes | Which view of the AC response to compute: 'filter' — LPF/HPF/BPF/BSF type, cutoffs, ripple, rejection (args: ref_db, flatness_db, passband_range, stopband_range) 'slope' — magnitude slope between two frequencies (args: f_low, f_high — both required) 'point' — magnitude (dB + linear) and phase at specific frequencies (args: frequencies — required; include_unwrapped_phase) 'crossing' — every frequency where magnitude/phase crosses a level (args: quantity + level — required; direction, f_start, f_end, max_results, min_separation_decades) | |
| step | No | Step index for .step sweeps | |
| all_steps | No | Compute the metric for EVERY step of a stepped (.step) sweep in one call, instead of the single `step`. Returns `steps`: a list of per-step results (each tagged with its `step` index). A step whose computation fails is returned with an `error` field rather than aborting the whole call. On a non-stepped raw this returns a single entry. Use this for 'give me the cutoff/slope/gain at every step'. | |
| quantity | No | crossing: 'magnitude_db' | 'magnitude_linear' | 'phase_deg'. | |
| level | No | crossing: level to cross, in the units of `quantity`. | |
| direction | No | crossing: edge direction. | any |
| f_start | No | crossing: lower frequency bound. | |
| f_end | No | crossing: upper frequency bound. | |
| max_results | No | crossing: cap on returned crossings. | |
| min_separation_decades | No | crossing: merge crossings within this many decades. | |
| frequencies | No | point: frequencies to query (SPICE notation). | |
| include_unwrapped_phase | No | point: also return cumulative unwrapped phase. | |
| ref_db | No | filter: cutoff reference below passband (dB). | |
| flatness_db | No | filter: passband flatness tolerance (dB). | |
| passband_range | No | filter: optional [f_lo, f_hi] passband override. | |
| stopband_range | No | filter: optional [f_lo, f_hi] stopband region. | |
| f_low | No | slope: low frequency bound (required). | |
| f_high | No | slope: high frequency bound (required). | |
| format | No |
| Name | Required | Description |
|---|---|---|
| filter_type | No | |
| passband_gain_db | No | |
| passband_low_hz | No | |
| passband_high_hz | No | |
| passband_ripple_db | No | |
| cutoff_low_hz | No | |
| cutoff_high_hz | No | |
| ref_db | No | |
| cutoff_level_db | No | |
| stopband_rejection_db | No | |
| transition_bandwidth_hz | No | |
| rolloff_slope_db_per_decade | No | |
| estimated_order | No | |
| warnings | No | |
| signal | No | |
| f_low_hz | No | |
| f_high_hz | No | |
| gain_low_db | No | |
| gain_high_db | No | |
| delta_db | No | |
| span_decades | No | |
| slope_db_per_decade | No | |
| slope_db_per_octave | No | |
| nearest_pole_order_estimate | No | |
| points | No | |
| quantity | No | |
| level | No | |
| direction | No | |
| crossings | No | |
| mode | No | |
| all_steps | No | |
| step_count | No | |
| steps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, destructiveHint, idempotentHint. Description adds mode-specific behavior: response shape depends on mode, out-of-range clamping with warnings for point mode, and all_steps returns steps list with error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with mode descriptions in a clear list, front-loaded purpose. Slightly long but every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 23 parameters and output schema, the description covers all key aspects: modes, parameter combinations, error handling, use cases, and alternatives. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 96%, but the description goes beyond by detailing each mode's required arguments (e.g., ref_db for filter, f_low/f_high for slope), explaining all_steps behavior, and clarifying job_id/run_index use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs AC/Bode-plot analysis selected by mode, and explicitly distinguishes from siblings stability_metrics and resonance. Each mode is defined with specific output details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use each mode, when to use all_steps, when to use job_id vs raw_file, and directs to sibling tools for other analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running simulation job (single run, or a sweep/Monte-Carlo batch). Kills the simulator process(es) and marks the job as cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID of the running simulation to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing that it kills the simulator process(es) and marks the job as cancelled. This provides useful behavioral insight, though it does not elaborate on potential side effects such as resource cleanup or data loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that directly state the operation and its effect without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and no output specification, the description fully covers the tool's purpose and effect. It is complete for the agent to understand what the tool does and what input is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, job_id, is fully described as the identifier of the running simulation to cancel. This matches the schema and provides all necessary meaning for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool cancels a running simulation job, and it distinguishes between single runs and batch jobs. It explicitly mentions killing simulator processes and marking the job as cancelled, which is specific and unique among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a running simulation needs to be stopped) but does not explicitly discuss alternatives or when not to use it. However, the purpose is clear enough that an agent would understand the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check status of a simulation job by ID, or list all jobs. Without job_id: lists active jobs (filter with status param). With job_id: returns detailed status or completion results.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | Job ID returned by run_simulation. Omit to list jobs. | |
| status | No | Filter by status when listing jobs. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| job_id | No | |
| status | No | |
| netlist | No | |
| simulator | No | |
| elapsed | No | |
| sim_type | No | |
| duration | No | |
| step_count | No | |
| raw_file | No | |
| log_file | No | |
| signals | No | |
| warnings | No | |
| errors | No | |
| meas_errors | No | |
| measurements | No | |
| fourier | No | |
| range | No | |
| point_count | No | |
| failed_measurements | No | |
| observations | No | |
| error | No | |
| job_type | No | |
| total_runs | No | |
| completed_runs | No | |
| failed_runs | No | |
| jobs | No | |
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which align with the description. The description adds value by explaining the two operational modes and that 'completion results' are returned with job_id, but does not significantly exceed what annotations convey about safety and behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. Every sentence is essential and no extraneous details are included. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (read-only query with three optional parameters and an output schema present), the description is complete. It covers both modes, the filter, and implies the output includes status/results. The output schema handles return value details, so no further elaboration is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds contextual meaning (e.g., job_id is returned by run_simulation, status filter options), but this is largely redundant with the schema descriptions. It does not provide new semantic information beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two distinct functions: check status by job_id or list all jobs. It uses specific verbs 'Check' and 'list', and the resource 'simulation job' is clear. This distinguishes it from sibling tools like cancel_job or run_simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each mode (with/without job_id) and explains the optional status filter. It doesn't explicitly state when not to use the tool, but the context of a read-only query is evident from the annotations and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a placed component's pin positions, bounding box, value, and attributes from an .asc schematic.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| reference | Yes | Component reference (e.g., 'M1', 'R1') | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| reference | No | |
| symbol | No | |
| position | No | |
| rotation | No | |
| value | No | |
| pins | No | |
| bounding_box | No | |
| attributes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is well covered. The description adds that it reads from an .asc file and returns specific fields, but it does not disclose error handling or other behavioral details beyond what annotations imply. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with the verb 'Get' front-loaded. All words are meaningful and it avoids redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and presence of an output schema, the description is sufficient for this read-only tool. It lists the key data returned and the input context, though it could optionally mention behavior when components are missing, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter (path, reference, format) is already described. The description does not add additional meaning or constraints to the parameters beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (get), the resource (placed component), and the data retrieved (pin positions, bounding box, value, attributes) from an .asc schematic. It is distinct from siblings like symbol_info or list_components, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (placed component, .asc schematic) that implies when to use it, but it does not explicitly mention alternatives or when not to use it. No user guidance is provided regarding comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure a Monte Carlo analysis with component tolerances and return a config_id for later execution.
| Name | Required | Description | Default |
|---|---|---|---|
| netlist | Yes | Path to the netlist file (.cir, .net, .asc) | |
| tolerances | No | R/C/L (and V/I type-level) component tolerance specifications. | |
| model_tolerances | No | Process-variation rules: per-.MODEL parameter perturbations sampled once per run. All instances of the model see the same perturbation (correlated). | |
| mismatch | No | Pelgrom-law mismatch rules per device prefix. Sampled INDEPENDENTLY per instance per run. Requires explicit AVT/AK — defaults are 0 (no mismatch) since coefficients are technology-specific. | |
| param_tolerances | No | Sample-once-per-run perturbation of .PARAM directives. Use this when the netlist already wires {param} substitutions into model cards or component values. | |
| num_runs | No | Number of Monte Carlo iterations | |
| seed | No | Optional RNG seed for reproducible runs. None = fresh entropy each call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds it returns a config_id but doesn't elaborate on side effects, persistence, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded with the verb and resource, but could be slightly improved by noting the sibling relationship.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema), the description is too brief. It lacks an overview of the tolerance types and workflow, relying entirely on parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough parameter descriptions, so the description doesn't need to add detail. It provides no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'configure' and the resource 'Monte Carlo analysis', and distinguishes from the sibling 'run_montecarlo' by noting it returns a config_id for later execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used before 'run_montecarlo', but lacks explicit guidance on when to use vs. alternatives (e.g., configure_sweep) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure a multi-parameter sweep for a netlist and return a config_id for later execution.
| Name | Required | Description | Default |
|---|---|---|---|
| netlist | Yes | Path to the netlist file (.cir, .net, .asc) | |
| parameters | Yes | Sweep dimensions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds the key behavioral detail that the tool returns a config_id for later execution, which is not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose without any wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's purpose and output given its two required parameters and no output schema. It could mention that the config_id is used with run_sweep, but the sibling tool list provides that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents both parameters. The description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a multi-parameter sweep for a netlist and returns a config_id for later execution. It uses a specific verb and resource, and distinguishes itself from execution tools like run_sweep and configure_montecarlo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for configuration, not execution, by mentioning 'return a config_id for later execution.' However, it does not explicitly state when to use this tool versus run_sweep or configure_montecarlo, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect two component pins with wire(s). Resolves pin positions automatically. Waypoints define the wire route through intermediate points. For a straight horizontal or vertical connection, waypoints can be omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| from_pin | Yes | Source pin as 'Reference.Pin' (e.g., 'M1.D', 'VDD.+') or 'net:name' for a net label | |
| to_pin | Yes | Target pin as 'Reference.Pin' (e.g., 'M4a.D', 'VDD.+') or 'net:name' for a net label | |
| waypoints | No | Intermediate points for wire routing. For L-shaped routes, provide the corner point. For straight connections (same x or same y), omit. |
| Name | Required | Description |
|---|---|---|
| from | No | |
| to | No | |
| wire_count | No | |
| points | No | |
| warnings | No | |
| validation_warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate modifying nature (readOnlyHint=false), but description doesn't mention potential side effects such as overwriting existing connections or changing netlist. Lacks explicit warning about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description adequately covers the function, parameters, and behavior. It explains the conditions for waypoints sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are detailed with examples for pin references and waypoints. The description reinforces the meaning of waypoints and when they are needed, adding clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Connect two component pins with wire(s)' and notes automatic position resolution. It distinguishes from other tools by focusing on wiring, though no explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides details on when to use waypoints and when they can be omitted, guiding the user on the proper invocation. No explicit alternative guidance, but sufficient context for a schematic editing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new SPICE netlist file from content string. Automatically appends .END if missing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | File name without extension | |
| content | Yes | Complete SPICE netlist content | |
| overwrite | No | Overwrite an existing file at this path. Default is to refuse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true; description adds key behavior: automatic appending of .END if missing. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point with two sentences, no wasted words. Could front-load more detail about overwrite behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool but lacks mention of error handling, return value, or how it relates to sibling tools like validate_netlist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, description does not add significant meaning beyond the schema for parameters like name, content, overwrite. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new SPICE netlist file from content string, and adds specific behavior (auto-appending .END). Distinguishes from sibling tools like export_netlist and schematic_from_netlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating netlist files, but does not explicitly clarify when to use this vs other creation methods or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an empty .asc schematic ready for incremental editing via add_component / connect / add_net_label. Tip: prefer create_netlist + .cir for design iteration; use this only when a visual schematic is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | File name without the .asc extension | |
| width | No | Sheet width (LTspice grid units). 880 matches LTspice's default. | |
| height | No | Sheet height (LTspice grid units). 680 matches LTspice's default. | |
| overwrite | No | Overwrite an existing file at this path. Default is to refuse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true and readOnlyHint: false, so the description correctly implies a mutation. It adds context about creating an empty file and the overwrite parameter's default behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's core purpose, the second provides usage guidance. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 4 parameters, no output schema, and present annotations, the description sufficiently covers purpose, usage context, and basic behavior. Minor missing details like file path handling are acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear default descriptions. The description adds value by noting that default width/height match LTspice defaults, which aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an empty .asc schematic' with a specific verb (create) and resource (.asc schematic). It also mentions the tool's role as a starting point for incremental editing via sibling tools, distinguishing it from creation tools like create_netlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip explicitly advises preferring 'create_netlist' + .cir for design iteration and using this tool only when 'a visual schematic is the deliverable'. This provides clear when-to-use guidance and contrasts with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structural diff between two circuit files: reports added/removed components, components whose value or attributes (Value2/SpiceLine/SpiceModel) changed, and added/removed .PARAM/.MEAS/.MODEL directives. Use after set_component_value, set_component_attribute or edit_directive to confirm that the intended change actually landed.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | Path to the first circuit file (.cir, .net, or .asc) | |
| path_b | Yes | Path to the second circuit file (.cir, .net, or .asc) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the safety profile is covered. The description adds meaningful behavioral detail beyond that by specifying the categories of changes detected (components, attributes, .PARAM/.MEAS/.MODEL directives), giving the agent a concrete sense of the tool's output scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in sentence one and usage context in sentence two. Every word contributes value; no fluff or repetition of the schema. This is a model of efficient tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only diff tool with no output schema, the description provides the key output categories and a usage trigger, which gives the agent enough context to invoke it correctly. It does not describe exact return formatting, but the format parameter and listed report categories cover the essentials, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents path_a, path_b, and format. The description adds little parameter-specific semantic beyond implying two file paths; it focuses on the diff behavior rather than explaining the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'diff' and names the resource ('two circuit files'), then enumerates exactly what it reports: added/removed components, changed values/attributes, and added/removed directives. This clearly distinguishes it from sibling tools like read_circuit or validate_netlist, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly tells the agent when to use this tool: after set_component_value, set_component_attribute, or edit_directive, to confirm a change landed. This is clear context, though it stops short of naming when-not-to-use or alternative diff tools, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need to quantify HOW FAST one transition happened: rise time, fall time, slew rate. Inputs a transient .raw plus a time window around the edge of interest.
Returns: transition_time (10→90% by default, configurable via low_pct/high_pct), slew_rate (V/s or A/s), detected low/high levels, and the three crossing times.
Levels are auto-estimated from the first/last 10% of the window — NOT global min/max — so overshoot/undershoot doesn't poison the level estimate. Crossings are sub-sample-accurate via linear interpolation. Rejects AC analysis.
PICK THE WINDOW. If the transient has startup glitches or multiple edges, set t_start/t_end tightly around the edge you care about — otherwise you get the first edge in the full waveform, which is often the power-up artifact. Use edge_index only when multiple edges in the window are intentional.
For settling/overshoot after the edge, use pulse_response. For delay between two signals' edges, use timing_between.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw transient result file | |
| signal | Yes | Signal name (e.g. 'V(out)') | |
| step | No | Step index for .step sweeps | |
| t_start | No | Window start time in SPICE notation (e.g. '1m', '100u'). Strongly recommended when the transient contains startup transients or multiple edges — otherwise the first edge in the full waveform is measured (often the power-up glitch). | |
| t_end | No | Window end time in SPICE notation | |
| edge | No | Edge direction. 'auto' infers from window endpoints. | auto |
| edge_index | No | Which matching edge in the window (0 = first). Use with tight t_start/t_end for determinism. | |
| low_pct | No | Low threshold percent (default 10%) | |
| high_pct | No | High threshold percent (default 90%) | |
| low_level | No | Absolute low rail level, overriding auto-detection. Use when the auto estimate (mean of first/last 10%) is biased — e.g. a rise-from-rail where early samples cluster in the fast ramp. | |
| high_level | No | Absolute high rail level, overriding auto-detection. | |
| format | No | 'json' or 'text' |
| Name | Required | Description |
|---|---|---|
| transition_time | Yes | |
| slew_rate | Yes | |
| low_level | Yes | |
| high_level | Yes | |
| t_low_crossing | Yes | |
| t_high_crossing | Yes | |
| t_mid_crossing | Yes | |
| edge_direction | Yes | |
| is_rise_time | Yes | |
| low_pct | Yes | |
| high_pct | Yes | |
| num_edges_in_window | Yes | |
| warnings | Yes | |
| signal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's safe. The description adds valuable behavioral details: level estimation from first/last 10% (not global min/max), sub-sample accuracy via linear interpolation, rejection of AC analysis, and potential power-up glitch issue. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with purpose, lists returns, explains behavioral details, and ends with usage tips and sibling references. Every sentence adds value, though it is somewhat lengthy. Could be slightly more concise but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 2 required, output schema exists), the description is highly complete. It explains key parameters, limitations, and how to use effectively. The output schema covers return values, so no need to repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: explains auto-detection of levels, when to override with low_level/high_level, and provides examples (e.g., signal 'V(out)'). This extra guidance pushes the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'quantify HOW FAST one transition happened: rise time, fall time, slew rate.' It also explicitly distinguishes from sibling tools pulse_response and timing_between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use when you need to quantify HOW FAST one transition happened'), when-not-to-use (rejects AC analysis), and alternatives (pulse_response for settling/overshoot, timing_between for delay). Also gives specific guidance on window selection and edge_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or remove a SPICE directive or .asc free-text comment. Set kind=comment for annotation text; default is a SPICE directive. Works on .cir/.net and .asc; kind=comment is .asc-only. remove matches against directives AND comments, so callers can delete either kind without knowing which it is.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to circuit file (.cir, .net, or .asc) | |
| action | Yes | Whether to add or remove the directive | |
| instruction | Yes | SPICE directive text (e.g., '.tran 10m', '.ac dec 100 1 1G'). For ``kind='comment'`` this is the comment text instead. For remove: literal exact match by default — copy the line verbatim from ``read_circuit``. Pass ``regex:<pattern>`` to use a regex (matches against directives AND comments). Raises an error when nothing matched, so a typo can't silently leave the directive in place. | |
| kind | No | ``directive`` (default) — emit a SPICE directive line. ``comment`` — emit a free-text annotation. .asc-only; the tool refuses ``kind='comment'`` on .cir/.net since plain netlists already accept ``*`` / ``;`` comments inline. | directive |
| x | No | Optional X coordinate when adding to an .asc schematic. Default: directives are auto-placed in free space near the schematic's lower-left; comments default to the sheet origin (0,0). | |
| y | No | Optional Y coordinate (see ``x``). | |
| size | No | Font size (.asc only). 1=small, 2=normal (default), 3=large. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool modifies files (add/remove) and specifies constraints like .asc-only for comments and remove behavior. However, with annotations providing no safety hints (all false), the description could add more about idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the main action, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (3 required) and no output schema, the description covers the essential high-level behavior and constraints. The schema fills in parameter details, making the overall definition adequately complete for an LLM agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds little beyond the schema: it reiterates default kind and remove matching behavior, but does not provide new semantics for parameters not already covered in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or removes a SPICE directive or .asc free-text comment, with specific verbs and resources, distinguishing it from sibling tools that deal with components or other schematic elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context on when to use the tool, such as file type restrictions (.cir/.net vs .asc) and behavior differences for 'remove' action (matches both directives and comments). However, it does not explicitly compare with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an .asc schematic to a SPICE netlist (.net) using LTspice.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic to export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered by structured data. The description adds the 'using LTspice' context but does not explain what may be destroyed (e.g., overwriting an existing .net file) or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately states the core conversion action, and contains no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with annotations covering side-effect safety, the description is mostly complete. It would benefit from mentioning the output destination or that LTspice must be available, but it gives sufficient context for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the single 'path' parameter is fully documented as 'Path to .asc schematic to export.' The description adds no additional meaning beyond matching that parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resources: 'Export an .asc schematic to a SPICE netlist (.net) using LTspice.' This clearly identifies the tool's function and distinguishes it from siblings like validate_netlist or export_waveform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_netlist or validate_netlist. It implicitly assumes the agent will know this is the export path, but gives no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find model/subcircuit candidates across loaded (and optionally built-in) libraries. Default is fuzzy matching — finds typos, case variants, and near-neighbour part numbers (e.g., '2N3905' → '2N3904'); pass exact=true to only return the exact case-insensitive match. Returns ranked candidates with similarity score and ready-to-paste .include directive. Each candidate carries ports (the .SUBCKT port list, empty for .MODEL) and params (default parameter values from the body / params: clause).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Model/subcircuit name to match (case-insensitive) | |
| exact | No | Only return the exact case-insensitive match (score=1.0) if any; skips fuzzy scoring. | |
| limit | No | Max suggestions to return (1-25). Ignored when exact=true. | |
| cutoff | No | Minimum fuzzy similarity ratio (0.0-1.0). Lower = more matches, noisier. Ignored when exact=true. | |
| include_builtin | No | Also walk built-in simulator libraries (slower; lazy-parses all built-ins on first call). | |
| full | No | Include the full SPICE definition text + parameter list of every returned candidate. Folds the old ``model_info`` tool into this one — call ``find_model(name=X, exact=true, full=true)`` for a single model's body. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| query | No | |
| results | No | |
| include_builtin | No | |
| exact | No | |
| cutoff | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, but the description adds critical behavioral details: fuzzy matching behavior, return structure (ranked candidates with similarity score and .include directive), port and parameter inclusion, and a performance warning for include_builtin. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and front-loaded with the primary purpose. Every sentence adds value, and the structure flows logically from purpose to behavior to parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still covers return values adequately (candidates, similarity score, .include directive, ports, params, optional full content). All 7 parameters are fully documented in schema, and the description provides necessary behavioral context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant meaning beyond the schema: it explains how fuzzy matching works, that exact=true bypasses fuzzy scoring, that limit/cutoff are ignored when exact=true, and that full=true merges the old model_info tool. This reduces cognitive load for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and clearly identifies the resource ('model/subcircuit candidates across loaded and optionally built-in libraries'). It distinguishes between fuzzy and exact modes, making the tool's primary function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use fuzzy matching (default) vs exact matching (pass exact=true), and explains parameters like limit and cutoff are ignored when exact=true. It does not directly contrast with sibling tools, but the usage context is clearly implied within the domain of component search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List components in a circuit file, optionally filtered by type prefix, or return a single component value by reference.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to circuit file (.cir, .net, or .asc) | |
| prefix | No | Filter by reference prefix (e.g., 'R', 'M', 'C') | |
| reference | No | Look up a single component by reference (e.g., 'R1') | |
| offset | No | Pagination offset | |
| limit | No | Max results to return (server caps at 50; page with offset) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| components | No | |
| pagination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint, indicating safe operations. The description adds that limit is capped at 50 and pagination is possible, which is behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the primary purpose and two optional behaviors. It is concise with no fluff, though it could be more explicit about the two modes of operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return formats are covered. The description is sufficient for a read-only listing tool with 6 parameters, but could better explain the difference between 'reference' mode vs 'prefix' mode and when to use each.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well documented. The description adds little: it mentions 'type prefix' and 'single component value by reference' which clarifies the 'prefix' and 'reference' fields slightly, but mostly redundant with schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists components in a circuit file, with optional filtering by prefix or returning a single component by reference. It distinguishes from siblings like component_info (which presumably provides details on a known component) and set_component_value (mutation), but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing or reading components, but doesn't explicitly state when to use this vs component_info or other query tools. It mentions optional filtering and single lookup, which hints at usage scenarios, but lacks clear guidance on when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List loaded libraries. With detail=true, also shows the .SUBCKT and .MODEL names defined in each library (so foundry .bjt/.mod files with hundreds of .MODEL cards are discoverable without guessing).
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Include model names from each library | |
| path | No | Filter to a specific library path | |
| offset | No | Pagination offset | |
| limit | No | Max results to return (server caps at 50; page with offset) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| libraries | No | |
| pagination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description adds value by explaining the behavioral context of the detail flag (exposing .SUBCKT and .MODEL names). This helps the agent understand the tool's non-destructive, read-only nature beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every sentence adds value. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (return values documented elsewhere) and comprehensive annotations, the description covers the essential behavior of listing libraries and the detail feature. It does not discuss pagination or the path filter, but those are already present in the schema, so the description is complete for its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds meaningful context for the detail parameter by providing a concrete use case example (foundry .bjt/.mod files with hundreds of .MODEL cards), which clarifies why one might use it and what benefit it provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List loaded libraries' with a specific verb and resource, and highlights the optional detail flag to show .SUBCKT and .MODEL names. It distinguishes itself from sibling tools like load_library and unload_library by focusing on listing rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool to discover loaded libraries and internal models, but does not explicitly state when to use it versus alternatives (e.g., find_model). It lacks explicit when-not or exclusion guidelines, so it meets only a minimal standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a SPICE library file (.lib, .mod) or directory of library files into the session.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to library file or directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries full weight. It only says 'load into the session' but does not disclose whether loading replaces existing libraries, is idempotent, has side effects, or what happens on errors. This is minimal disclosure for a state-modifying operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded, with no redundant words. Every element adds meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the core action but omits behavior like replacement policy, existence checks, or interaction with other tools (e.g., whether loaded libraries are automatically used by simulations). Given the minimal annotations, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Path to library file or directory'. The tool description adds file extensions (.lib, .mod) and clarifies that a directory is accepted, providing marginal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Load' clearly specifies the action (loading a SPICE library file or directory), and it explicitly names the resource types (.lib, .mod). It distinguishes from siblings like unload_library and list_libraries by stating the purpose of making libraries available to the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('into the session') but does not explicitly state when to use this tool versus alternatives like find_model or unload_library, nor does it mention any exclusions or prerequisites. Usage is 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.
Use to AGGREGATE .MEAS scalar results across a .step sweep or Monte Carlo run. Answers questions like 'across 100 MC trials, what's the worst-case rise time?' or 'how does gain vary as R sweeps 1k..10k?'. Inputs the .log file produced by the run.
Returns per-measurement: min, max, mean, median, std, p10, p90, best_step_index (argmin) and worst_step_index (argmax), failure count, and an optional histogram (set histogram_bins=0 to skip).
Accepts any job id: a sweep/MC batch aggregates across its runs; a single-simulation job aggregates its own log (one value per step for a .step run). Axis choice differs by shape: a batch detects WHEN-style .MEAS (constant level, varying crossing) and swaps to aggregating the 'at' field; a stepped single-run log always aggregates the 'value' field. The aggregated_field output says which was used. On a plain single run there's only one value per measurement, so stats collapse to n=1 — use simulation_summary instead to just read the scalars.
Works with .MEAS from any analysis type (.tran/.ac/.dc/.op) — the measurement directives themselves embed the analysis context. Pass measurement=NAME to aggregate just one; otherwise returns all .MEAS in the log.
| Name | Required | Description | Default |
|---|---|---|---|
| log_file | No | Path to .log file from a single ``.step`` run that already concatenates every step's .MEAS results. For Monte Carlo / multi-run sweep jobs that emit one log per run, pass ``job_id`` instead and the aggregator walks every run's log. | |
| job_id | No | Job ID. For a batch job (``run_montecarlo`` / ``run_sweep``) the tool loads each completed run's log, concatenates the .MEAS results (one row per run), and aggregates. For a completed single-simulation job it aggregates that run's log (per-step values for a .step run). Mutually exclusive with ``log_file``. | |
| measurement | No | If given, stats for only this .MEAS; otherwise all measurements. | |
| histogram_bins | No | Histogram bin count. Set to 0 to skip histogram computation. | |
| format | No | 'json' or 'text' |
| Name | Required | Description |
|---|---|---|
| stats | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: what outputs are returned (min, max, mean, etc.), how axis choice works, and edge cases (single run with n=1). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is well-structured. However, it is somewhat verbose; minor tightening could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, annotations, and output schema, the description fully covers all behavioral nuances, edge cases, and alternatives. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant extra meaning: explains the difference between log_file and job_id, clarifies the measurement parameter, and describes histogram_bins' effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'aggregate' and resource '.MEAS scalar results', and distinguishes from sibling tools like simulation_summary by noting when to use each. Example questions ('worst-case rise time?') provide concrete context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (aggregating across sweep or Monte Carlo) and when not to (use simulation_summary for plain single runs). Also explains axis choice and job type handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move and/or rotate a component in an .asc schematic. Warns if the new position overlaps another component's bounding box, and lists wire endpoints orphaned by the move (the component's old pin coordinates are no longer connected to anything).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| reference | Yes | Component reference to move (e.g., 'R1', 'M3') | |
| x | Yes | New X coordinate (LTspice grid units) | |
| y | Yes | New Y coordinate (LTspice grid units) | |
| rotation | No | New rotation (omit to keep current) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint=false, destructiveHint=false), leaving the description to carry behavioral disclosure. The description adds key traits: it warns on overlap and lists orphaned wire endpoints, providing insight into the tool's side effects beyond simple mutation. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It front-loads the core action and immediately adds valuable behavioral details, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description implies the return value (warnings, orphaned wire list) and covers the operation fully for a 5-parameter tool with 100% schema coverage. It provides all necessary context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds overall context but does not provide per-parameter meaning beyond what the schema states. The baseline is 3 for high coverage, and the description does not elevate it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (move and/or rotate), the target (component in .asc schematic), and distinguishes from siblings like add_component or remove_component by detailing its unique side effects (overlap warnings, orphaned wires). It is a specific verb+resource pairing with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear when to use the tool (to reposition a component) and provides context about warnings and orphaned wires, but it does not explicitly state when not to use it or suggest alternatives. The need for the tool is implied by the action, but exclusive guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read DC operating point data showing all node voltages and branch currents.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw result file from simulation | |
| step | No | Step index for stepped .OP runs (e.g. ``.step temp ...`` + ``.op``). Default 0 returns the first step. Out-of-range values raise a structured error rather than silently returning the wrong step. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| step | No | |
| step_count | No | |
| voltages | Yes | |
| currents | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds the scope of data returned, but no further behavioral traits (e.g., error handling beyond the schema note on 'step', performance, or output size). With strong annotations, the description does not need extensive behavioral disclosure, but it does not add significant value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's core function. No wasted words, and it is front-loaded with the action and result. It is appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but sufficient given the existence of a thorough input schema and annotations. It covers the essence of what the tool does. However, it could mention the requirement for a .raw file (though schema already marks 'raw_file' as required) or clarify the context of 'operating point' (e.g., from .OP simulation). The presence of an output schema helps, but a small addition would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the three parameters thoroughly ('raw_file', 'step' with default and error behavior, 'format' with enum options). The tool description does not add any parameter-specific information beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and resource 'DC operating point data showing all node voltages and branch currents', clearly indicating what the tool returns. It is distinct from sibling read tools like 'component_info' or 'simulation_summary' by specifying the scope of the data. However, it does not explicitly differentiate from similar tools, and the title is null, so a slight deduction for not leveraging the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or situations where another tool (e.g., 'simulation_summary' for summary metrics) might be more appropriate. The agent must rely on context and sibling names to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read or write .PARAM directive values in a circuit file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to circuit file (.cir, .net, or .asc) | |
| name | No | Parameter name to set (omit to read all params) | |
| value | No | Parameter value (required when name is specified) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| parameters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotency and non-destructiveness, but the description adds no behavioral context beyond 'read or write'. It fails to disclose side effects like whether writing creates new directives or requires existing ones, leaving the agent unaware of important constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the core functionality with no wasted words. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and schema coverage is complete, the description is adequate but lacks important behavioral distinctions. It does not explain the conditional behavior of reading vs writing based on parameter presence, which is relevant for a dual-purpose tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; the interaction between 'name' and 'value' (e.g., reading vs writing) is not clarified beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads or writes .PARAM directive values in circuit files, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'edit_directive' which might handle similar operations on other directives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios such as creating new parameters vs updating existing ones, or how it differs from editing directives via 'edit_directive'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for an oscillating transient signal (clock, oscillator output, switching waveform) when you need period, frequency, duty cycle, pulse widths, and period-to-period jitter.
Returns: period (mean across measured periods), frequency (1/period), jitter_rms (std-dev of period lengths — timing jitter, NOT signal amplitude variance), duty_cycle_pct, mean high/low pulse widths, edge counts. duty_cycle_pct / pulse_widths are null if no full periods could be paired.
Uses threshold crossings; threshold defaults to the midpoint of window min/max. For a signal with DC drift, set an explicit threshold — the auto midpoint moves with the drift and the edge detection gets unstable. min_periods guards against accidentally running on 1-edge windows.
Skip the startup transient via t_start/t_end; the first cycle is often wider than steady state. Rejects AC analysis. For a single edge (not periodic), use edge_metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw transient result file | |
| signal | Yes | Signal name (e.g. 'V(clk)') | |
| step | No | Step index for .step sweeps | |
| t_start | No | Window start — recommended to skip the startup transient. | |
| t_end | No | Window end in SPICE notation | |
| threshold | No | Absolute threshold level. Auto = midpoint of window min/max. For drifting signals, set explicitly. | |
| min_periods | No | Minimum complete periods required; error if window has fewer. | |
| format | No | 'json' or 'text' |
| Name | Required | Description |
|---|---|---|
| period | Yes | |
| frequency | Yes | |
| jitter_rms | Yes | |
| duty_cycle_pct | No | |
| pulse_width_high | No | |
| pulse_width_low | No | |
| num_rising_edges | Yes | |
| num_falling_edges | Yes | |
| num_periods_measured | Yes | |
| threshold_used | Yes | |
| warnings | Yes | |
| signal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, idempotentHint. The description adds crucial behavioral context: threshold crossing algorithm, auto midpoint behavior, rejection of AC analysis, and conditions for null duty_cycle_pct. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections. Each sentence adds value, though slightly verbose. No redundancy with schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, output schema exists, and complexity of periodic measurements, the description covers purpose, usage, edge cases, and behavioral details comprehensively. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds practical meaning beyond schema: e.g., threshold auto = midpoint, min_periods guards against 1-edge windows, t_start/t_end intended to skip startup transient. Adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for oscillating transient signals to extract period, frequency, duty cycle, pulse widths, and jitter. It explicitly differentiates from the sibling tool edge_metrics ('For a single edge... use edge_metrics').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (periodic signals) and when-not (single edge), along with practical tips like skipping startup transient via t_start/t_end, setting explicit threshold for DC drift, and using min_periods to avoid insufficient data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need step-response quality metrics: overshoot %, undershoot %, settling time, peak value and peak time. Inputs a transient .raw covering ONE step transition — ideally with the stimulus edge near t_start and enough tail to see settling.
Returns: direction (rising/falling), initial/steady-state values, peak (absolute and pct), settling_time (to within settling_tolerance_pct band; null if never settled in window).
Definitions: overshoot is excursion BEYOND final in the step direction; undershoot is excursion beyond initial opposite the step direction. overshoot_pct = 0 means MEASURED overdamped, not missing data. settling_tolerance_pct defaults to 2% of |final - initial|; 1% and 5% are also common.
If the auto-detected initial/final (mean of first/last 10% of window) is contaminated by ringing, pass explicit initial_value/final_value. Rejects AC analysis.
For just rise/fall time without overshoot, use edge_metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw transient result file | |
| signal | Yes | Signal name (e.g. 'V(out)') | |
| step | No | Step index for .step sweeps | |
| t_start | No | Window start — ideally the stimulus edge. Defaults to full transient. | |
| t_end | No | Window end in SPICE notation | |
| initial_value | No | Pre-step steady value. Auto = mean of first 10% of window. Set explicitly if the start is contaminated by ringing. | |
| final_value | No | Post-step steady value. Auto = mean of last 10% of window. | |
| settling_tolerance_pct | No | Settling band as percent of |final - initial|. 2% is standard; 1% or 5% also common. | |
| format | No | 'json' or 'text' |
| Name | Required | Description |
|---|---|---|
| direction | Yes | |
| initial_value | Yes | |
| steady_state_value | Yes | |
| peak_value | Yes | |
| peak_time | Yes | |
| overshoot_pct | No | |
| undershoot_pct | No | |
| settling_time | No | |
| settling_tolerance_pct | Yes | |
| quality | Yes | |
| warnings | Yes | |
| signal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses essential behaviors: expects a one-step transition in a transient .raw file, auto-detects initial/final values but allows explicit override if contaminated by ringing, defines metrics (overshoot/undershoot concepts), and notes that settling_time may be null if never settled. This adds substantial value beyond the readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: it opens with the purpose, then covers inputs, returns, definitions, and special notes. Every sentence adds value, and it is not verbose. It effectively front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 2 required, output schema present), the description is comprehensive. It covers input requirements, output fields, definitions of metrics, edge cases (auto-detection contamination, AC rejection), and alternatives. With an output schema existing, the description does not need to detail return structure but does so adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions are already detailed, but the tool description adds meaning by explaining the auto-detection logic (first/last 10% of window), the definition of overshoot and undershoot, and the interpretation of overshoot_pct=0 as measured overdamped. It also clarifies the role of settling_tolerance_pct with common values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides step-response quality metrics (overshoot, undershoot, settling time, peak value and peak time). It distinguishes itself from the sibling tool edge_metrics by noting that tool is for rise/fall time without overshoot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (need step-response metrics) and when not (for rise/fall time without overshoot, use edge_metrics). It also mentions that it rejects AC analysis, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the value of a signal at a specific time point (transient) or frequency (AC). Returns the nearest data point without interpolation.
To pick a step of a .step/.DC sweep by its axis VALUE (rather than a raw step index), pass step_axis + step_value (e.g. step_axis='temp', step_value='27'); at then selects the inner-axis point within that step (optional). AC samples also return magnitude_linear alongside magnitude_db/phase_deg.
To query a run of a completed sweep/MC job, pass job_id + run_index instead of raw_file — the run is analyzed like any standalone raw.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | No | Path to .raw result file. Pass this OR ``job_id`` (a job run), not both. | |
| job_id | No | Analyze a specific run of a completed sweep/MC (or single) job instead of a raw_file path; pair with ``run_index``. Lets you query a sweep run the same way you'd query a standalone raw. | |
| run_index | No | 0-based run to analyze when ``job_id`` is given (default 0). | |
| signal | Yes | Signal/trace name (e.g., 'V(out)', 'I(R1)'). | |
| at | No | Time or frequency to query in SPICE notation (e.g., '1m', '100u', '1G', '2.5k'). Required unless ``step_axis`` is given (then it picks the inner-axis point within the chosen step; optional). | |
| step | No | Step index for .step directives (ignored when ``step_axis`` is used). | |
| step_axis | No | Select the step by a .step/.DC sweep-axis VALUE instead of an index: the parameter name (e.g. 'temp', 'Rval'). Pair with ``step_value``. The nearest step is chosen and flagged with ``exact_match``. | |
| step_value | No | Target value of ``step_axis`` in SPICE notation (e.g. '27', '1k'). Required when ``step_axis`` is given. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| signal | No | |
| requested_x | No | |
| actual_x | No | |
| value | No | |
| magnitude_db | No | |
| magnitude_linear | No | |
| phase_deg | No | |
| axis | No | |
| requested_value | No | |
| actual_value | No | |
| exact_match | No | |
| step_index | No | |
| requested_at | No | |
| actual_at | No | |
| warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent. Description adds key behaviors: no interpolation, exact_match flagging, AC return structure (magnitude_linear). Minor omission: no mention of response format constraints beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs front-loading core purpose and behavior, then handling specific modes. No redundant text; every sentence adds essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all major usage modes (standalone, step sweeps, AC, job runs) for a 9-parameter tool. Output schema exists, so return value details are adequately supplemented by the description's AC specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description explains parameter relationships (e.g., step_axis+step_value, job_id+run_index) and runtime behavior (nearest step selection, AC return details), adding significant value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a signal value at a specific time or frequency, with 'nearest without interpolation'. It distinguishes from siblings by specifying the exact query operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use step_axis+step_value vs step index, and raw_file vs job_id+run_index, providing clear alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and parse a circuit file (.cir/.net or .asc). For netlists: returns content and component values. For schematics: returns layout and directives.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to circuit file (.cir, .net, or .asc) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| file | No | |
| type | No | |
| components | No | |
| content | No | |
| labels | No | |
| wire_count | No | |
| directives | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing the different return contents for netlists vs schematics, and notes supported file extensions. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with no redundant information. The first sentence front-loads the main action, and the second explains the two cases. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters), excellent annotations, and presence of an output schema, the description fully covers what the tool does for both netlist and schematic inputs. It mentions file extensions and return types, which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both path and format have descriptions). The description does not add parameter-level meaning beyond the schema, but it does provide context about the tool's output types which indirectly aids understanding. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reads and parses circuit files (.cir/.net/.asc) and distinguishes between netlists (returns content/component values) and schematics (returns layout/directives). This is a specific verb+resource and clearly differentiates from sibling tools like validate_netlist or trace_net.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what the tool does but does not provide guidance on when to use it versus alternatives (e.g., trace_net, component_info, or validate_netlist). No when-not-to-use or prerequisites are mentioned, though the read-only nature is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call on session start to find circuits the user was last working with, including jobs that were still running when the server stopped. Needs no inputs.
Returns a list of recent circuits, each with its absolute path, whether the file still exists, last-touched timestamp, total persisted job count, status_counts (completed/failed/interrupted/etc.), and the IDs of any interrupted jobs.
'interrupted' means a simulation was in flight when the server stopped — recovery path is check_job(job_id) to see whether results are recoverable or the run needs to be re-kicked. Does NOT start or cancel anything; purely read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| circuits | No | |
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining the meaning of 'interrupted' (simulation in flight when server stopped), the recovery path (check_job), and explicitly states it does not start or cancel anything. This aligns perfectly with the readOnly, idempotent, and non-destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (mentions 'jobs still running' and later explains 'interrupted'), but each section contributes necessary details about output structure and semantics. It is not overly verbose and remains focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: what the tool returns (list with fields), the meaning of a key status, and explicit non-actions. Combined with the input schema and annotations, it is fully sufficient for the agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'format' has a clear description explaining the difference between 'json' and 'text' outputs, adding meaningful semantics beyond the schema's enum. It also notes the default and optional nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find circuits and jobs the user recently worked with, using the verb 'find' and specifying the resource. It distinguishes from siblings by focusing on recent items and session-start context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage context ('Call on session start') and clarifies no inputs are required, though an optional format parameter exists. It does not explicitly mention alternatives, but the context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a component from an .asc schematic by reference designator.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| reference | Yes | Component reference to remove (e.g., 'R1', 'M3') | |
| cleanup_wires | No | When true, also delete every wire whose endpoint touches one of the removed component's pins (Fr7). Default false keeps the v2 behaviour of leaving wires in place and surfacing a warning, so callers can opt in once they've confirmed the removal is clean. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description confirms the removal action. The description adds no contradictions but also does not elaborate on side effects beyond what the cleanup_wires parameter description covers. It is sufficiently transparent for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three parameters and no output schema, the description adequately states the core purpose. However, it could be improved by noting its relationship to sibling tools or specifying that removal is permanent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add any additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a component from a schematic by reference designator, which is a specific verb-resource pair that distinguishes it from sibling tools like add_component or move_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revert an .asc schematic to the state it had BEFORE the first edit this session — a recovery escape hatch for when a sequence of edits went wrong. The server snapshots each .asc file's bytes just before its first in-session mutation (add_component, set_component_value, move_component, connect, apply_schematic_ops, etc.); this restores that snapshot exactly and drops it (so a later edit establishes a fresh restore point). Because add_component is a trigger, the first add_component on a freshly created schematic snapshots the empty file — so reset can revert all the way back to the empty post-create state, dropping every component added this session. Returns reverted=false (not an error) when the file has no recorded in-session edits. Note: the snapshot lives only for the current server session — it does not persist across restarts, and it is not a substitute for version control.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic to revert to its pre-session state | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| path | No | |
| reverted | No | |
| bytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly supplements the annotations. It explains the snapshot mechanism, that the snapshot is dropped after reset, that add_component on a new schematic snapshots the empty file, that repeated calls with no edits return reverted=false, and that snapshots do not persist across server restarts. This goes well beyond destructiveHint and idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, every sentence earns its place: purpose, snapshot mechanics, edge cases, return behavior, and persistence limitations are all relevant. It is front-loaded with the core recovery purpose before diving into details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive recovery tool, the description is exceptionally complete. It covers the snapshot lifecycle, the empty-file edge case, the reverted=false return value, and the non-persistence caveat. The presence of an output schema means return-value details beyond reverted=false are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both 'path' and 'format'. The description adds context about how the server snapshots each .asc file, but it does not add new parameter-level meaning beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reverts an .asc schematic to its pre-session state, using a specific verb ('Revert'), a specific resource ('.asc schematic'), and a clear scope ('BEFORE the first edit this session'). It also positions itself as a 'recovery escape hatch,' distinguishing it from siblings like apply_schematic_ops or create_schematic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'when a sequence of edits went wrong.' It also gives a when-not scenario by noting it returns reverted=false when there are no in-session edits, and warns it is 'not a substitute for version control,' which clarifies limitations and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect magnitude peaks in an AC sweep and estimate Q factor + -3 dB bandwidth for each. Useful for RLC resonators, crystal oscillators, peaking amps, or any response with distinct resonant modes.
Q = f_peak / Δf(-3 dB from peak). Q is returned as null for peaks without two flanking -3 dB crossings inside the swept range — widen the sweep if you need Q for a boundary peak.
min_prominence_db=3 rejects the gentle hump of a filter's passband (which isn't a resonance). Tight resonances (Q > 30) need dense sampling near f_peak — log sweeps with <50 pts/decade will under-sample the peak and give inflated Q/bandwidth.
For overall filter characterization use bode_metrics(mode='filter'); for stability margins use stability_metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to AC analysis .raw result file | |
| signal | Yes | Signal name (e.g. 'V(out)') | |
| min_prominence_db | No | Minimum peak prominence in dB. Smaller = more sensitive but also catches gentle humps. 3 dB rejects filter-passband shoulders. | |
| min_separation_decades | No | Merge peaks closer than this many decades (find_peaks can emit duplicates on shoulders). | |
| max_peaks | No | Maximum peaks returned (1..1000) | |
| step | No | Step index for .step sweeps | |
| format | No |
| Name | Required | Description |
|---|---|---|
| peaks | Yes | |
| num_peaks_detected | Yes | |
| warnings | Yes | |
| signal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds value by explaining that Q is returned as null for boundary peaks without flanking crossings and warns about under-sampling causing inflated Q/bandwidth. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with purpose first, then usage notes and parameter tips. It is somewhat verbose but each sentence adds value. Could be slightly more concise, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, output schema exists), the description is fairly complete. It covers the Q calculation formula, null case, and practical advice. With an output schema, return values need not be detailed here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86% or more), so baseline is 3. Description adds extra context: explains min_prominence_db in detail and mentions min_separation_decades for merging duplicates, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detects magnitude peaks in AC sweep and estimates Q factor and -3 dB bandwidth. This specific verb+resource combination distinguishes it from sibling tools like bode_metrics and stability_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (RLC resonators, crystal oscillators, peaking amps) and when not to use (for filter characterization use bode_metrics; for stability margins use stability_metrics). Also provides parameter advice like min_prominence_db and sampling density.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a previously configured Monte Carlo analysis asynchronously and return a job_id immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| config_id | Yes | Configuration ID from configure_sweep or configure_montecarlo | |
| max_parallel | No | Max concurrent simulations (default: server config) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, but the description explicitly states 'asynchronously and return a job_id', which discloses non-blocking behavior and output. This adds information beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, includes all essential elements: execute, previously configured, asynchronous, job_id. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mentions the output (job_id) despite no output schema, covering the immediate result. Does not detail job polling but that is not required for the action itself. Adequate for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes both parameters (config_id from configure functions, max_parallel with default). The description does not add further parameter-specific details; baseline applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (execute) and resource (Monte Carlo analysis), distinguishing it from siblings like run_sweep or configure_montecarlo. Mentions async and job_id, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates that the analysis must be 'previously configured', implying a prerequisite step (configure_montecarlo). While it doesn't explicitly contrast with alternatives, the name and context make its intended use clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SPICE simulation on a netlist file. Automatically runs synchronously for short simulations (<=30s timeout) or asynchronously for longer ones. Use wait=true to force synchronous execution. Returns raw/log file paths and simulation summary on completion, or a job ID for async tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| netlist | Yes | Path to the netlist file (.cir, .net, .asc) | |
| timeout | No | Timeout in seconds. Simulations exceeding 30s run asynchronously unless wait=true (which enforces a 600s hard cap — the run is killed at the cap). | |
| wait | No | Force synchronous execution. Blocks until completion or hard timeout. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| job_id | No | |
| status | No | |
| netlist | No | |
| simulator | No | |
| sim_type | No | |
| duration | No | |
| step_count | No | |
| raw_file | No | |
| log_file | No | |
| signals | No | |
| warnings | No | |
| errors | No | |
| meas_errors | No | |
| measurements | No | |
| fourier | No | |
| range | No | |
| point_count | No | |
| failed_measurements | No | |
| observations | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic sync/async behavior, timeout handling, hard cap (600s), and return types (file paths, job ID). No annotation contradictions; annotations are neutral, and description adds significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences clearly convey purpose, behavior, and usage. No wasted words; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, return values, and key parameters. Lacks prerequisites or permission details, but adequately complete given schema and output schema exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions; description repeats and elaborates slightly but adds no new semantics beyond what schema provides. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Run a SPICE simulation on a netlist file', clearly differentiating from sibling simulation types like run_montecarlo and run_sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on execution mode (sync vs async) via wait parameter and timeout handling, but does not explicitly compare with alternatives or state when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a previously configured parameter sweep asynchronously and return a job_id immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| config_id | Yes | Configuration ID from configure_sweep or configure_montecarlo | |
| max_parallel | No | Max concurrent simulations (default: server config) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false, etc.) and provide no safety profile. The description discloses that it runs asynchronously and returns a job_id immediately, which is useful behavioral context. It doesn't mention what happens on failure, or that it may consume resources, but given the annotations are sparse, the description adds some value but could be more explicit about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that packs in key details: 'previously configured', 'asynchronously', 'return a job_id immediately'. No fluff, front-loaded with the action, and completely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity is low (2 params, no output schema, no nested objects), the description adequately covers the essential aspects: what it does, the async nature, and the return. It could mention that it returns a job_id for tracking, but it already does. It doesn't explain how to use the job_id, but that's likely covered by other tools like check_job. Overall, it's reasonably complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the description adds little beyond what the schema already provides. The description mentions 'previously configured' which reinforces the config_id parameter's role, but doesn't add extra detail about max_parallel. With full schema coverage, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a previously configured parameter sweep and returns a job_id asynchronously. It uses a specific verb (execute) and resource (parameter sweep), and it distinguishes from siblings like run_montecarlo by focusing on 'parameter sweep' rather than Monte Carlo. However, it doesn't explicitly name the alternative, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: 'previously configured' and 'config_id' from configure_sweep or configure_montecarlo. It doesn't explicitly say when not to use it or mention alternatives, but the context of requiring a config_id implies it should be used after configuration. Sibling tools like run_montecarlo exist, but no contrast is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an .asc schematic from SPICE netlist text. Parses the netlist, grid-places each supported component (R/C/L/V/I/D) on its LTspice symbol, and connects pins by net label (FLAGs carrying the node name) so the result is electrically identical to the netlist — no manual pin-by-pin placement. Directives (.model/.tran/.ac/.param/.meas/...) are carried over. Multi-terminal / controlled / subcircuit elements (M, Q, J, X, E, G, F, H) can't have their symbol inferred from the instance line and are returned in skipped for manual placement. Round-trips through read_circuit. Connection is label-based, not routed wires, so the layout is functional rather than pretty.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Output file name without the .asc extension | |
| content | Yes | SPICE netlist text. Supported elements (R/C/L/V/I/D) are placed on a grid and wired by net label; per SPICE convention the first non-blank line is treated as the deck title and ignored. Directives (.model, .tran, .ac, .param, .meas, ...) are carried over verbatim. | |
| overwrite | No | Overwrite an existing file at this path. Default is to refuse. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| file | No | |
| placed | No | |
| components | No | |
| skipped | No | |
| directive_count | No | |
| nets | No | |
| warnings | No | |
| validation_warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond the destructiveHint annotation: it parses netlists, places components on a grid, connects via net labels, carries over directives, and notes label-based rather than routed wiring. It also explains the round-trip capability and how unsupported elements are handled. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the main purpose, then covers process, limitations, and round-trip capability in logical order. Every sentence adds value without redundancy, achieving high conciseness while maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, output schema exists), the description covers all essential aspects: what it does, input format, supported/unsupported elements, output characteristics, and response format options. The mention of skipped elements and round-trip integration with read_circuit provides adequate context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the first non-blank line of 'content' is treated as a title and ignored, and lists supported element types. It also clarifies the 'name' parameter exclusion of '.asc' extension and the default behavior of 'overwrite'. This exceeds the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an .asc schematic from SPICE netlist text, specifying verb (Generate), resource (.asc schematic), and input (SPICE netlist text). It distinguishes itself from siblings like 'create_schematic' by detailing its automated placement and connection process, and explicitly lists unsupported elements that are returned for manual handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to automatically generate a schematic from a netlist) and when not (for multi-terminal/subcircuit elements that require manual placement). It mentions round-tripping with read_circuit but does not explicitly compare to sibling tools like 'create_schematic' or provide 'when not to use' guidance, though the limitations are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive server status including detected simulators, configuration settings, security sandbox paths, and runtime state. Use this to check what capabilities are available before attempting operations.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| simulators | No | |
| default_simulator | No | |
| requested_simulator | No | |
| diagnostics | No | |
| tool_profile | No | |
| tool_count | No | |
| configuration | No | |
| allowed_paths | No | |
| runtime | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by detailing what status information is returned (simulators, config, security sandbox, runtime state). No contradiction, and the description aligns with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains what the tool does, second provides usage guidance. No unnecessary words, and the description is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one optional parameter, rich annotations, and an output schema, the description is complete. It explains the tool's purpose and when to use it, leaving no gaps for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'format' parameter described in the schema. The tool description does not add any additional meaning beyond what the schema provides, so it achieves the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets comprehensive server status including simulators, configuration, security sandbox paths, and runtime state. It distinguishes from sibling tools by being a general status check, unlike other tools that perform specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using it to check capabilities before attempting operations, providing clear when-to-use context. However, it does not mention when not to use it or alternatives, but for a status tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a schematic-only component attribute. The standard LTspice slots are Value, Value2, SpiceLine, SpiceLine2, SpiceModel, InstName — anything else is rejected, since LTspice silently ignores unknown SYMATTR keys at netlist time. To set arbitrary KEY=val pairs (e.g. W=10u L=0.5u), pass them as the SpiceLine value.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to .asc schematic | |
| reference | Yes | Component reference (e.g., 'M1', 'R1') | |
| attribute | Yes | Attribute name (e.g., 'SpiceLine', 'SpiceModel', 'Value2') | |
| value | Yes | Attribute value (e.g., 'W=10u L=0.5u') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation and idempotency. Description adds constraints (only specific slots accepted) and netlist behavior (silently ignores unknown SYMATTR keys). No contradiction. Misses noting that setting an attribute overwrites previous value, but idempotent hint mitigates this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and add crucial details. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive enough for a constrained set operation. With 4 required parameters fully described, and no output schema needed for a side-effect tool, the description covers key behavioral constraints and usage tips. Could mention if attribute names are case-sensitive, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have schema descriptions (100% coverage). Description adds meaning by listing valid attribute values and giving examples like 'W=10u L=0.5u' for SpiceLine, enriching understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set a schematic-only component attribute' with specific verb and resource. Lists standard LTspice slots (Value, Value2, etc.) and indicates what is rejected, distinguishing it from siblings like set_component_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (to set standard slots) and what not to use (anything else rejected). Provides alternative: for arbitrary KEY=val pairs, pass as SpiceLine. This is clear guidance on when and how to use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set component value(s) in a circuit file. Supports single or batch mode.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to circuit file (.cir, .net, or .asc) | |
| reference | No | Component reference for single mode (e.g., 'R1') | |
| value | No | New value for single mode (e.g., '10k', '100n') | |
| values | No | Batch mode: {reference: value} dict (e.g., {'R1': '10k', 'C1': '100n'}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with annotations (idempotentHint true, destructiveHint false). No additional behavioral context provided (e.g., permissions, file mutation details). Annotations already shed some light, so description adds minimal new insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with key info. Could be slightly more structured but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters fully described in schema and no output schema, the description captures the core purpose. However, lacks details like file modification behavior or return value, which would improve completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds context about single vs batch mode, which maps to the parameters (reference/value vs values dict). Provides some added meaning but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Set' and the resource 'component value(s) in a circuit file'. Mentions two modes (single or batch), differentiating it from sibling tools like add_component or list_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies batch vs single mode usage but lacks explicit guidance on when to use this tool over alternatives like set_component_attribute or batch_results. With many siblings, more direction would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scalar summary of one signal in a .raw result. Use this when you need a single number per metric (average, RMS, peak, etc.) — not a waveform or a trend.
Transient: time-weighted mean, RMS, std, abs-mean, and min/max/pk-pk using trapezoidal integration (RMS = sqrt(∫ y² dt / T)). This is correct on LTspice's adaptive timestep — simple np.mean(y) would overweight densely sampled regions. Optionally restrict to [t_start, t_end]; passing no window averages the whole waveform including any startup transient, which is usually wrong for RMS/mean.
DC: returns min/max/pk-pk and the simple/abs mean over the swept axis, plus sweep_start_used/sweep_end_used/sweep_span. RMS and std are deliberately omitted — they're meaningless on a non-time axis. Use t_start/t_end to restrict the sweep range.
AC: returns magnitude (dB) min/max/mean and phase (deg) min/max. t_start/t_end are rejected for AC — use query_value for a point at a specific frequency.
Noise: returns min/max/pk-pk and the simple/abs mean of the noise spectral density over the frequency axis, plus freq_start_used/freq_end_used. RMS/std/duration are omitted; t_start/t_end are rejected — pass them via query_value at specific frequencies instead.
Related tools: for rise/fall times use edge_metrics; for overshoot/settling use pulse_response; for period/duty use periodic_metrics; to aggregate .MEAS values across a sweep use measurement_stats.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw result file from simulation | |
| signal | Yes | Signal/trace name (e.g., 'V(out)', 'I(R1)'). | |
| step | No | Step index for .step directives | |
| t_start | No | Window start in SPICE notation (e.g. '1m', '100u'). Transient only. Strongly recommended when computing RMS or average — the startup transient otherwise biases the result. Rejected for AC analysis (time-windowing a frequency sweep is an error). | |
| t_end | No | Window end in SPICE notation. Transient only; rejected for AC. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| signal | No | |
| analysis_type | No | |
| min | No | |
| max | No | |
| mean | No | |
| rms | No | |
| std | No | |
| abs_mean | No | |
| peak_to_peak | No | |
| point_count | No | |
| t_start_used | No | |
| t_end_used | No | |
| duration | No | |
| sweep_start_used | No | |
| sweep_end_used | No | |
| sweep_span | No | |
| freq_start_used | No | |
| freq_end_used | No | |
| min_db | No | |
| max_db | No | |
| mean_db | No | |
| min_phase | No | |
| max_phase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains transient integration method, why np.mean is wrong, details for DC/AC/Noise analyses, and which parameters are rejected for which types. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary followed by per-analysis sections, front-loading the purpose. While somewhat lengthy, the detail is justified by the complexity of four analysis types. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (four analysis types), full schema coverage, and presence of an output schema, the description covers all necessary aspects: what each analysis returns, parameter validity, and integration details. It is complete and reduces ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra semantic value by explaining how parameters like t_start/t_end behave differently depending on analysis type (e.g., rejected for AC), which goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'scalar summary of one signal in a .raw result' and distinguishes it from sibling tools by mentioning specific use cases (single number per metric vs waveform/trend) and listing alternative tools for other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('when you need a single number per metric') and provides a list of related tools with their purposes, giving clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive simulation summary including type, signal list, data size, .MEAS results, Fourier analysis, AC bandwidth metrics, and warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw result file from simulation | |
| log_file | No | Optional path to .log file. Defaults to ``raw_file`` with the extension swapped to ``.log`` — pass an explicit value only if the log lives somewhere unusual. | |
| signal | No | Signal for AC bandwidth metrics (e.g., 'V(outp)'). Required for AC analysis. | |
| step | No | Step index for ac_bandwidth_metrics on a stepped (.step) run. Default 0 (first step). On a multi-step run the metric is computed for this step only — a warning notes it. | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| sim_type | No | |
| range | No | |
| point_count | No | |
| step_count | No | |
| signals | No | |
| measurements | No | |
| fourier | No | |
| ac_bandwidth_metrics | No | |
| warnings | No | |
| errors | No | |
| meas_errors | No | |
| failed_measurements | No | |
| observations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of 'Get' aligns. It adds that warnings are included but no further behavioral traits (e.g., about data freshness, caching, or performance). Given annotation coverage, the description provides modest additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key purpose and content list. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema exists), the description adequately lists all major output components. No critical gaps for a summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are documented there. The description does not add extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a comprehensive simulation summary with specific content types (type, signal list, data size, etc.), making the purpose evident. However, it does not explicitly distinguish itself from related sibling tools like bode_metrics or measurement_stats, which are more specialized.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. The description implies it is for obtaining a broad summary after simulation, but lacks explicit context about preferred scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find EVERY unity-gain and -180° phase crossover in a loop-gain AC sweep, report phase margin at each unity-gain crossing and gain margin at each -180° crossing. Replaces the single-crossing approximation in simulation_summary, which returns wrong margins on conditionally-stable systems.
Run this on a LOOP-GAIN signal (typically a dedicated middlebrook probe or .AC of the open loop). Running on a closed-loop output gives meaningless margins — if the DC phase starts near ±180° (a closed-loop / inverting output rather than a loop probe, which starts near 0°), a warning says so in warnings.
Returns: dc_gain_db, high_freq_gain_db, stability classification (stable / unstable / conditional / unconditional / always_below_unity), all crossings, per-crossing margins, and the worst-case values.
Nuances:
Phase is UNWRAPPED first, so systems whose phase drops past -360° are handled correctly (otherwise the raw wrap hides the crossing).
If phase NEVER crosses -180°, gain margin is 'infinite' (returned as null with stability='unconditional'). That's stable, not an error.
If gain NEVER reaches unity, phase margin is undefined (returned as null with stability='always_below_unity').
Multiple crossovers trigger stability='conditional' and a warning — each one needs its own review.
For -3 dB filter cutoffs use bode_metrics(mode='filter'); for custom crossings use bode_metrics(mode='crossing').
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to loop-gain AC analysis .raw file | |
| signal | Yes | Loop-gain signal (e.g. 'V(loop)') | |
| min_separation_decades | No | Merge near-duplicate crossovers closer than this many decades. | |
| step | No | Step index for .step sweeps | |
| format | No |
| Name | Required | Description |
|---|---|---|
| dc_gain_db | Yes | |
| high_freq_gain_db | Yes | |
| stability | Yes | |
| unity_gain_crossovers | Yes | |
| phase_180_crossovers | Yes | |
| phase_margins | Yes | |
| gain_margins | Yes | |
| phase_margin_worst_deg | No | |
| gain_margin_worst_db | No | |
| warnings | Yes | |
| signal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true, and the description adds rich behavioral details such as phase unwrapping, handling of never-crossing cases (returning null with stability strings), and multiple crossovers triggering a conditional stability warning. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first paragraph stating the main purpose, followed by bullet points for nuances. It is somewhat verbose but still efficient and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool dealing with stability analysis and multiple crossovers, the description thoroughly covers usage scenarios, return fields (dc_gain_db, stability classification, etc.), and edge cases. The presence of an output schema allows the description to focus on behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 80% coverage with descriptions for all parameters. The description does not add extra semantic detail beyond the schema, except for reinforcing the 'signal' parameter context. Given high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: finding unity-gain and -180° phase crossovers in a loop-gain AC sweep and reporting margins. It explicitly distinguishes itself from the sibling tool 'simulation_summary' by noting that the sibling returns wrong margins on conditionally-stable systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (on a loop-gain signal) and when not to (closed-loop output, which gives meaningless margins). It also directs the user to alternative tools 'bode_metrics' for filter cutoffs or custom crossings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get symbol pin positions, bounding box, and description. Optionally compute absolute positions for a given placement and rotation.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Symbol name (e.g., 'nmos', 'pmos', 'res', 'cap', 'voltage') | |
| x | No | Placement X coordinate (for computing absolute positions) | |
| y | No | Placement Y coordinate (for computing absolute positions) | |
| rotation | No | R0 | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| name | No | |
| description | No | |
| bbox_width | No | |
| bbox_height | No | |
| pins | No | |
| placement | No | |
| absolute_pins | No | |
| absolute_bounding_box | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true digital matching the non-destructive nature. The description adds that it returns pin positions, bounding box, and description, and indicates optional computation behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence stating the tool's function. The input schema is well-organized with defaults, enums, and descriptions. No redundant or excessive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and optional behavior. However, it doesn't specify what 'absolute positions' means precisely or when it's useful, and doesn't mention alternatives or edge cases. Still, context is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter has a clear description: 'symbol' with examples, 'x'/'y' as placement coordinates, 'rotation' with enum values, 'format' with choices. Required parameter is specified. Meaning and purpose are unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' with specific resources: 'symbol pin positions, bounding box, and description.' It also distinguishes itself from siblings like component_info and list_components by focusing on symbol-level geometric and descriptive data, with an optional absolute-position computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call when you need symbol pin positions, bounding box, or description. It explains optional behavior for computing absolute positions when placement x/y/rotation are provided. It doesn't explicitly state when NOT to use it versus alternatives like component_info, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need propagation delay / skew between TWO signals — e.g. input-to-output delay, clock-to-Q, input-skew. Inputs one transient .raw containing both signals on a shared time axis.
Returns: signed delay = t_b - t_a where t_a and t_b are the FIRST threshold crossings of signal_a and signal_b in the window. Negative delay means signal_b leads signal_a.
Thresholds default to 50% of EACH signal's own min-max range in the window — intentional for asymmetric CMOS where V_in and V_out have different rails. Override per-signal via threshold_a / threshold_b if you need absolute thresholds (e.g. VIH/VIL at fixed voltages). Set direction_a / direction_b independently (e.g. rising input → falling output for an inverter).
Picks only the FIRST crossing of each signal in the window — if both signals have multiple edges, tighten t_start/t_end around the specific edge pair you want. Rejects AC analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_file | Yes | Path to .raw transient result file | |
| signal_a | Yes | Reference signal (e.g. 'V(in)') | |
| signal_b | Yes | Delayed signal (e.g. 'V(out)'). delay = t_b - t_a. | |
| step | No | Step index for .step sweeps | |
| t_start | No | Window start in SPICE notation | |
| t_end | No | Window end in SPICE notation | |
| threshold_a | No | Absolute threshold for signal_a. If omitted, threshold_pct of signal_a's range is used. | |
| threshold_b | No | Absolute threshold for signal_b. If omitted, threshold_pct of signal_b's range is used. | |
| threshold_pct | No | Threshold percent applied PER SIGNAL (not shared) — asymmetric for CMOS with different rails. | |
| direction_a | No | rising | |
| direction_b | No | rising | |
| format | No | 'json' or 'text' |
| Name | Required | Description |
|---|---|---|
| t_a | Yes | |
| t_b | Yes | |
| delay | Yes | |
| threshold_a_used | Yes | |
| threshold_b_used | Yes | |
| direction_a | Yes | |
| direction_b | Yes | |
| num_crossings_a | Yes | |
| num_crossings_b | Yes | |
| warnings | Yes | |
| signal_a | Yes | |
| signal_b | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral details: it rejects AC analysis, explains threshold defaults (50% of each signal's range for asymmetric CMOS), picks only the first crossing, and defines signed delay. This fully informs the agent of behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-organized: starts with purpose, then return value, threshold behavior, edge selection, and rejection. It is front-loaded with the most critical information and every sentence adds value without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description adequately covers return format and main behavior. It doesn't mention error conditions or edge cases like signals not found, but for a measurement tool with clear annotations and good parameter descriptions, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 83% of parameters with descriptions. The description adds contextual meaning: explains that threshold_pct is applied per signal, direction parameters can be set independently (e.g., rising input to falling output). While helpful, it doesn't add substantial new information beyond schema for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for measuring propagation delay/skew between two signals, with specific examples like input-to-output delay and clock-to-Q. This differentiates it from sibling tools like edge_metrics or periodic_metrics that are for single-signal or repeated metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when you need propagation delay / skew between TWO signals'. It also details prerequisites (transient .raw with both signals on shared time axis) and gives advice for handling multiple edges (tighten window). This clearly guides when to use and how to use effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report everything electrically connected to a net: starting from a pin ('Ref.Pin'), a net label ('net:NAME'), or an (x,y) coordinate, return the net's labels and every component pin, FLAG, and wire vertex on it. Follows both wires (segment-aware — catches labels placed mid-wire) and same-name FLAGs (LTspice's name-based nets, as produced by schematic_from_netlist). Use it to answer 'what's on net X', to confirm a connect landed, or to spot an accidental short (a net carrying two different non-ground labels).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to an .asc schematic | |
| pin | No | Pin or net reference to start from: 'Ref.Pin' (e.g. 'M1.D'), 'net:NAME' (e.g. 'net:VDD'), or omit and pass x/y. | |
| x | No | X coordinate (with y) to trace from | |
| y | No | Y coordinate (with x) to trace from | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| start | No | |
| labels | No | |
| pins | No | |
| coordinates | No | |
| is_shorted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description details tracing behavior: segment-awareness for mid-wire labels and name-based FLAGs from LTspice. This adds valuable context not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (<60 words) yet comprehensive, with a clear front-loaded purpose. Every sentence adds value, and it avoids redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently covers input options (three starting methods) and output components (labels, pins, FLAGs, wire vertices), including an edge case (accidental short). It feels complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The tool description adds minimal extra detail, such as example formats for pin references and coordinate usage, but largely reiterates schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies all electrical connections on a net, starting from a pin, net label, or coordinate, returning labels, pins, FLAGs, and wire vertices. It distinguishes from sibling tools by focusing on tracing connectivity rather than editing or simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three use cases: answering 'what's on net X', confirming a connection, and spotting accidental shorts. While it lacks explicit when-not-to-use or alternatives, the provided use cases are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unload a previously loaded library from the session.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to library file or directory to unload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, which cover safety. The description adds minimal context ('from the session') but does not elaborate on behavior such as idempotency or what happens if the library doesn't exist. With annotations present, the description meets the baseline but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and all words contribute to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter fully described and no output schema, the description is nearly complete. It states the resource and action. It lacks details like effects of unloading a non-existent library or whether unloading is reversible, but given the simplicity and annotations, it's sufficient. A score of 4 reflects its adequacy without excess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'path' parameter is fully described as 'Path to library file or directory to unload'. The description repeats the parameter concept but adds no additional semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'unload' with a clear resource 'library' and scope 'from the session'. It distinguishes itself from sibling tools like load_library (loading) and list_libraries (listing) by clearly stating the action of removing a previously loaded library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously loaded' implies use after a library has been loaded, which gives clear context. However, it does not explicitly name alternatives or when-not-to-use scenarios. For a simple tool, this is adequate but slightly under explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint a netlist or schematic before simulation — the static circuit check gate. Catches: element arity (too few nodes, missing E/G/F/H/B value), duplicate/multiple analysis directives ('More than one analysis specified'), .MEAS whose analysis kind isn't present, known-bad .MEAS patterns (vdb()/phase()/group_delay()), and directives the LTspice runner is known to reject. On .asc, also surfaces named-net shorts, floating pins, and dangling labels. Returns a structured issue list; an empty list means the file passes the static gate. Note: value tokens (e.g. a typo'd '1kk') and undefined model references are NOT checked — LTspice coerces or resolves those at run time.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to circuit file (.cir, .net, or .asc) | |
| format | No | Response format: 'json' for structured data, 'text' for human-readable |
| Name | Required | Description |
|---|---|---|
| file | No | |
| issue_count | No | |
| issues | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and idempotent. The description adds behavioral details: returns a structured issue list, empty means pass, and lists specific checks and known limitations. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the main purpose, and uses a clear list of checks. Every sentence adds value, though a bullet-point format could improve readability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and an output schema (structured issue list), the description is comprehensive: it covers input format, checks performed, limitations, and return value semantics. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions (path file types, format options). The description does not add significant new meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a static circuit check gate for netlists or schematics before simulation. It provides specific examples of checks (element arity, duplicate directives, .MEAS patterns) and distinguishes it from sibling tools that handle dynamic analysis or component editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (before simulation) and what it does not check (value tokens, undefined model references), guiding the agent to avoid inappropriate calls. It also specifies supported file extensions, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_componentadd_net_labelapply_schematic_opsbatch_resultsbode_metricscancel_jobcheck_jobcomponent_infoconfigure_montecarloconfigure_sweepconnectcreate_netlistcreate_schematicdiff_circuitedge_metricsedit_directiveexport_netlistfind_modellist_componentslist_librariesload_librarymeasurement_statsmove_componentoperating_pointparameterperiodic_metricspulse_responsequery_valueread_circuitrecentremove_componentreset_schematicresonancerun_montecarlorun_simulationrun_sweepschematic_from_netlistserver_statusset_component_attributeset_component_valuesignal_statssimulation_summarystability_metricssymbol_infotiming_betweentrace_netunload_libraryvalidate_netlistScored across 48 tools
Each tool targets a very specific circuit design or analysis task, with detailed descriptions that prevent overlap. For example, edge_metrics, periodic_metrics, and pulse_response each handle distinct transient phenomena. Even tools that might seem similar, like simulation_summary and measurement_stats, serve different purposes (overview vs. aggregated .MEAS results).
Names follow a mostly consistent verb_noun pattern for actions (add_component, run_simulation) but analysis tools use varied suffixes (_metrics, _stats, _summary) or are single words (resonance). The mix is still readable and predictable, with only minor deviations from a uniform pattern.
48 tools is well beyond the typical 3-15 for a well-scoped server, indicating possible redundancy or over-specification. While the LTspice domain is complex, many tools could be merged or streamlined without losing functionality, e.g., combining several metrics tools into a single configurable analysis tool.
The tool surface covers the entire LTspice workflow: schematic editing, netlist creation, simulation setup and execution, result analysis (transient, AC, sweeps, Monte Carlo), library management, and validation. There are no obvious gaps; advanced features like diffing circuits and tracing nets are included. The set feels complete for the domain.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI dialogue using various LLM models via AceDataCloud
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
