Loading ToolBench
SPICE simulation through an MCP server and an in-process Python API for LTspice and ngspice. Supports schematic editing, sweeps, Monte Carlo analysis, and structured measurements.
ltspice-mcp provides two domain-specific tools for circuit schematic inspection. Both tools have detailed descriptions and structured schemas, but lack critical guidance for LLM tool selection and parameter dependencies. The 'inspect' tool accepts a complex union of query kinds with conditional parameters (path, pin, x, y) that are not properly documented as mutually exclusive or conditionally required. The 'trace_net' tool has clearer parameter semantics but both tools lack actionable error recovery guidance. Output schemas are not explicitly documented in the visible source, preventing assessment of response structure quality. Tool names ('inspect', 'trace_net') are reasonably domain-specific but could be more action-oriented (e.g., 'query_circuit', 'trace_circuit_net'). Descriptions are substantive (150-220 chars) and explain what each tool does, meeting the 10-1024 char baseline, but lack explicit guidance on WHEN to use each tool vs. the other or what dependencies they have.
Read-only UNDERSTAND surface: queries about the server, detected simulators, dialects, circuits, symbols, nets, components, models, and tools' own vocabulary (reference index). Seven query kinds: capabilities, symbols, symbol, net, components, model, reference. Per-item isolation: a denied path or unknown kind fails only that item; every other query in the batch still returns.
Trace every pin/label/wire vertex on the net at a pin, label, or (x,y). Returns start coordinate, labels, pins with references and positions, wire vertices, short status, and any lexer warnings.
Conditional parameter dependencies not documented. 'inspect' tool accepts 'path', 'pin', 'x', 'y' but their mutual exclusivity and per-kind applicability are buried in the description. Parameter descriptions do not state which combinations are valid (e.g., 'For symbol/net/components/model queries, provide path and optionally pin/x/y; for capabilities/symbols/reference, omit path').
Output schemas not documented. Neither tool's response structure (return type, field names, data types) is visible in the provided source. LLMs cannot plan downstream operations or extract required fields if response shape is undocumented. Baseline from rubric: 100% of A+ tools have documented return types.
Tool naming lacks action verb prefix. 'inspect' and 'trace_net' are nouns or descriptive names rather than verb_object format (e.g., 'query_circuit', 'trace_circuit_net'). 90% of A+ tools start with an action verb; these do not. This makes it harder for LLMs to infer intent from the name alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Error handling guidance missing. No documented error cases, recovery paths, or actionable error messages. For example, if a circuit path is invalid, what error is returned? Can the LLM correct it or must it ask the user? Pattern baseline: 'Error responses must tell the LLM what to do next.'
Parameter type constraints incomplete. 'format' param accepts 'json' or 'text' via enum, but no enum is visible for 'kind' in inspect tool (only a list in description). Enums should be explicit in schema, not buried in prose. Parameter descriptions like 'Pin or net reference' lack format guidance (what characters are valid? what does 'Ref.Pin' notation enforce?).
Tool interdependence not documented. Both tools query circuits but it is unclear which tool to invoke first for a given user intent. For example, if an agent wants to understand a circuit, should it call 'inspect' with kind='capabilities' first, then 'trace_net'? No guidance is provided.