Uses Cloudflare tunnels to securely expose the MCP server to the internet, with automated setup via cloudflared.
Exports circuit designs to KiCad schematic format (.kicad_sch).
Click on "Install 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., "@SPICEBridge Design a 1kHz RC low-pass filter"
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.
AI-powered circuit design through simulation — an MCP server that gives language models direct access to SPICE circuit simulation via ngspice. Describe a circuit in plain English and let the AI handle netlist generation, simulation, measurement, and spec verification.
28 tools covering the full circuit design workflow
11 built-in templates with automatic component value calculation (E24 series)
Simulation: AC sweep, transient, DC operating point
Measurement: bandwidth, gain, DC levels, transient metrics, power
Monte Carlo & worst-case analysis under component tolerances
Multi-stage composition — connect circuit stages with automatic port mapping
Model wizard — generate SPICE .lib models from datasheet parameters
KiCad export — output .kicad_sch schematics
Web viewer — interactive schematic viewer in the browser
Cloud setup wizard — one-command deployment with Cloudflare tunnels (spicebridge setup-cloud)
Spec verification — compare results against design targets
Related MCP server: ltspice-mcp
pip install spicebridgePython 3.10+
ngspice installed and on PATH
Add to your .mcp.json:
{
"mcpServers": {
"spicebridge": {
"command": "spicebridge"
}
}
}spicebridge --transport streamable-http --port 8000One command to go from a local install to a public MCP endpoint:
spicebridge setup-cloud # interactive (named tunnel, permanent URL)
spicebridge setup-cloud --quick # quick tunnel (temporary URL, no account needed)The wizard handles the full deployment pipeline:
Installs cloudflared automatically (macOS via Homebrew, Linux via APT) if not found
Authenticates with Cloudflare (browser-based OAuth, named tunnel mode only)
Creates or reuses a tunnel — prompts to pick an existing one or make a new one
Configures DNS routing for your custom domain (named tunnel mode)
Generates an API key for authentication
Starts the SPICEBridge server and tunnel together
Prints connection info with a ready-to-paste JSON config for Claude.ai
Quick tunnels give you a temporary trycloudflare.com URL instantly — no Cloudflare account required. Named tunnels give you a permanent custom domain (e.g. spicebridge.example.com).
Additional options:
spicebridge setup-cloud --domain mcp.example.com # specify custom domain
spicebridge setup-cloud --port 9000 # custom port
spicebridge setup-cloud --no-install # skip cloudflared installation1. load_template("rc_lowpass_1st", specs={"f_3dB_hz": 1000})
-> netlist with R=1.6k, C=100nF, circuit_id: "a1b2c3d4"
2. run_ac_analysis(circuit_id, start_freq=1, stop_freq=1e6)
-> frequency response data
3. measure_bandwidth(circuit_id)
-> f_3dB_hz: 995
4. compare_specs(circuit_id, specs={"f_3dB_hz": {"target": 1000, "tolerance_pct": 5}})
-> PASS
5. draw_schematic(circuit_id)
-> schematic SVGTool | Description |
| Store a SPICE netlist, returns a circuit ID |
| Delete a stored circuit and clean up resources |
| List available circuit templates |
| Load a template with parameter substitution |
| Calculate component values from target specs |
| Change a component value in a stored circuit |
| Check a netlist for errors before simulation |
Tool | Description |
| AC frequency sweep |
| Transient (time-domain) analysis |
| DC operating point analysis |
Tool | Description |
| Find -3 dB bandwidth from AC results |
| Measure gain at a specific frequency |
| Extract DC operating point values |
| Measure time-domain characteristics |
| Calculate power dissipation |
Tool | Description |
| Retrieve last simulation results |
| Check measurements against target specs |
| Generate a schematic diagram (PNG/SVG) |
| Export as KiCad 8 schematic (.kicad_sch) |
| Start the interactive web schematic viewer |
Tool | Description |
| Define port-to-node mappings for a circuit |
| Return port definitions (auto-detect if unset) |
| Compose multiple stages into a single circuit |
Tool | Description |
| Monte Carlo analysis under component tolerances |
| Worst-case analysis at tolerance extremes |
| Full design loop in one call: template + simulate + verify |
Tool | Description |
| Generate a SPICE .lib model from datasheet parameters |
| List all saved models in the model library |
git clone https://github.com/clanker-lover/spicebridge.git
cd spicebridge
pip install -e ".[dev]"
pytestGPL-3.0-or-later
Run the full design loop in one call: load template, simulate, and verify.
specs uses compare_specs format: {"f_3dB_hz": {"target": 1000, "tolerance_pct": 5}}
sim_type is one of "ac", "transient", or "dc". sim_params optionally overrides default simulation parameters.
Returns accumulated results including circuit_id, simulation data,
measurements, and spec comparison. On failure at any step, returns
partial results with an error key and failed_step.
When a schematic_url is present in the response, ALWAYS include it as a clickable link in your message to the user. Users cannot see inline images. The schematic_url in the response is a public internet-accessible URL, not a sandbox or localhost URL. Always share it directly with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | ||
| specs | Yes | ||
| sim_type | No | ac | |
| sim_params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a read-write but non-destructive tool. The description adds failure behavior (partial results with error key and failed_step) and specific instructions for handling schematic_url, which are not covered 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 well-structured with bullet points for parameters, front-loading the purpose. It is somewhat lengthy but each sentence adds value, such as return format and URL instructions.
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?
Despite no output schema, the description thoroughly explains return values (accumulated results, failure handling) and critical user interaction details (schematic URL sharing). It is complete for a tool of 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?
With 0% schema coverage, the description explains three of four parameters: specs format (compare_specs style), sim_type values (ac/transient/dc), and sim_params optional overrides. template_id is not elaborated beyond its name.
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 'Run the full design loop in one call: load template, simulate, and verify,' which combines multiple steps. It distinguishes itself from siblings like load_template or run_ac_analysis by being a composite tool.
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 a complete design loop but does not explicitly state when to use this tool versus alternatives like individual simulation tools. It provides parameter format guidelines but lacks explicit 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate component values for a circuit topology from target specs.
| Name | Required | Description | Default |
|---|---|---|---|
| topology_id | Yes | ||
| specs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, destructiveHint false, and idempotentHint true, covering safety. The description adds no further behavioral details beyond the fact that it calculates values, which aligns with annotations. 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?
A single sentence with no superfluous words. Every part is meaningful and clear.
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 (2 required params, nested object, no output schema), the description is minimal. It provides the core purpose but lacks detail on input semantics and return value, which would aid an agent in using it effectively.
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 0%. The description mentions 'target specs' but does not explain the topology_id or the expected structure of the specs object, leaving the agent with insufficient semantic guidance.
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 calculates component values for a circuit topology from target specs. It uses a specific verb-resource pair and distinguishes itself from sibling tools like auto_design or compare_specs.
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. It does not specify prerequisites, contexts, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare simulation results against design specifications.
specs format: {"spec_name": {"target": N, "tolerance_pct": P}} or {"spec_name": {"min": N, "max": M}}.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| specs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior; description adds value by specifying the exact format for specs, which is critical for correct invocation.
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 plus a formatted example; front-loaded with main purpose, no 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?
Missing description of return values; without an output schema, the tool's output behavior (e.g., pass/fail, details) is not described, leaving a significant gap.
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?
Description explains the 'specs' parameter format in detail, compensating for the 0% schema coverage, but provides no explanation for 'circuit_id' parameter.
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 the verb 'compare' and the resource 'simulation results against design specifications', distinguishing it from sibling tools like measurement and analysis 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?
Implies usage for comparing results to specs but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose multiple circuit stages into a single combined circuit.
Each element of stages is {"circuit_id": str, "label": str (optional)}.
If connections is omitted, stages are auto-wired in order
(out of stage N → in of stage N+1).
shared_ports defaults to ["gnd"] — those nodes are never prefixed.
| Name | Required | Description | Default |
|---|---|---|---|
| stages | Yes | ||
| connections | No | ||
| shared_ports | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it details the stages format, auto-wiring logic, and shared_ports default. Annotations (readOnlyHint false, destructiveHint false) are not contradicted, and the description clarifies that this is a compositing 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 concise (three sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, parameter format, default behaviors. No unnecessary 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?
While the description covers parameter details and defaults, it lacks information about the tool's return value or output format. Since there is no output schema, the description should ideally mention what is returned. This gap reduces completeness.
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 0% schema description coverage, the description fully compensates by explaining that stages is a list of dicts with circuit_id and optional label, connections is optional, and shared_ports defaults to ['gnd']. This adds essential 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 action ('Compose multiple circuit stages into a single combined circuit') with a specific verb and resource. It distinguishes from sibling tools like create_circuit or modify_component by focusing on stage composition.
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 default behaviors (auto-wiring when connections omitted, shared_ports default) but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a SPICE netlist and return a circuit ID for subsequent analyses.
| Name | Required | Description | Default |
|---|---|---|---|
| netlist | Yes | ||
| models | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms a write operation (store), consistent with readOnlyHint=false. However, it does not disclose behaviors beyond what annotations already imply, such as error handling, validation, or the meaning of 'store' (e.g., does it overwrite existing circuits?).
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, front-loaded sentence with no waste. It efficiently communicates the core 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 covers the main function but lacks details about the optional 'models' parameter and edge cases. For a tool with no output schema, it could mention the return format or error conditions.
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 0% schema description coverage, the description should compensate but does not. It mentions 'netlist' implicitly but does not describe the 'models' parameter or provide any context about parameter formats or constraints.
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 'Store' and resource 'SPICE netlist', clearly stating the outcome 'return a circuit ID for subsequent analyses'. This differentiates it from siblings like delete_circuit and create_model.
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 (e.g., when to use create_circuit vs load_template or validate_netlist). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a SPICE .lib model file from datasheet parameters.
component_type: "opamp", "bjt", "mosfet", "diode" name: model name (e.g. "OPA2134") parameters: type-specific datasheet values; omitted keys use defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| component_type | Yes | ||
| name | Yes | ||
| parameters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with a creation tool. The description adds that omitted parameters use defaults, providing minor behavioral insight, but overall does not significantly expand 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 concise (2 lines plus a compact bullet list), front-loaded with the main action, and every sentence provides value without 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 does not explain what the tool returns (e.g., file path or content), leaving a gap for a creation tool. It also omits prerequisites or side effects, though annotations mitigate safety concerns. Overall adequate but not 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?
With 0% schema description coverage, the description adds essential meaning: component_type is limited to four values, name is the model name, and parameters are optional key-value pairs with defaults. This substantially clarifies the otherwise bare 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 generates a SPICE .lib model file from datasheet parameters, with a specific list of component types (opamp, bjt, mosfet, diode). This distinguishes it from sibling tools like list_models or load_template.
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 some guidance on parameters (type-specific, defaults) but does not explicitly state when to use this tool versus alternatives like list_models or auto_design. Usage context is implied but not clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a stored circuit and clean up its output directory.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable context about cleaning up output directory, which is not captured by annotations. 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?
Single sentence of 8 words, no fluff. Every word contributes to describing the tool's core action.
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 simplicity (1 param, no output schema), the description covers the basic action. However, it omits details about behavior on non-existent circuits, return values, or error conditions, which an agent might need.
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 0% schema description coverage, the description should compensate by explaining the 'circuit_id' parameter's meaning or format. It provides no parameter-specific information, leaving the agent to guess.
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 the action ('delete'), the resource ('stored circuit'), and an additional behavior ('clean up its output directory'). It distinguishes from sibling tools like create_circuit or modify_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 explicit guidance on when to use this tool versus alternatives. The description implies it's for deletion, but does not mention prerequisites, safety checks, or scenarios where it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a schematic diagram from a stored circuit's netlist.
When a schematic_url is present in the response, ALWAYS include it as a clickable link in your message to the user. Users cannot see inline images. The schematic_url in the response is a public internet-accessible URL, not a sandbox or localhost URL. Always share it directly with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| fmt | No | png |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behavioral traits: the generated URL is public and accessible, and it clarifies that users cannot see inline images. This adds value beyond the annotations (idempotentHint, etc.) by detailing output expectations.
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 with four sentences: first stating purpose, the next three giving crucial output instructions. It is front-loaded and every sentence earns its place without 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 covers the main action and output handling, but misses explaining the 'fmt' parameter and error cases (e.g., invalid circuit_id). For a simple two-parameter tool, it is moderately complete but leaves 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?
The description only implicitly explains 'circuit_id' as referring to a stored circuit's netlist, but provides no details about 'fmt' (e.g., valid values like png, svg). With 0% schema description coverage, the description adds minimal semantic 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 generates a schematic diagram from a stored circuit's netlist. The verb 'generate' and resource 'schematic diagram' are specific, and the source 'stored circuit's netlist' distinguishes it from other tools like 'open_viewer' that likely display existing schematics.
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 strong guidance on how to handle the output (always share the URL as clickable link), but lacks information on when to use this tool versus alternatives (e.g., prerequisites like circuit must exist, or comparisons with 'open_viewer').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export circuit as KiCad 8 schematic (.kicad_sch) file.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true but readOnlyHint=false, suggesting it may create a file without modifying state. The description adds context about the output format but doesn't clarify side effects or file location.
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 redundant information, achieving maximal 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 tool has two parameters and no output schema, the description lacks essential details about parameter usage, output behavior, and any constraints, making it inadequate for correct 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?
With 0% schema description coverage, the description should explain parameters like 'circuit_id' and 'filename', but it omits any parameter details, leaving the agent to guess their 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?
The description clearly states the action 'Export' and the specific resource 'circuit as KiCad 8 schematic (.kicad_sch) file', making the tool's 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?
No guidance is provided on when to use this tool versus alternatives like 'draw_schematic' or 'validate_netlist'. There's no mention of prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return port definitions for a circuit, auto-detecting if none are set.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key behavioral detail 'auto-detecting if none are set', which goes beyond the annotations (readOnlyHint, idempotentHint) and informs the agent that the tool can handle circuits without explicit port definitions. This is valuable context not captured elsewhere.
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 with no redundant information. It is concise and front-loaded, effectively conveying the tool's purpose and key 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?
For a simple tool with one parameter and strong annotations, the description provides sufficient context: it states what is returned, for which resource, and a special behavior (auto-detection). No additional information is needed given the tool's simplicity.
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 description does not mention the parameter 'circuit_id' at all. With 0% schema description coverage, the description should compensate by explaining the parameter's purpose, format, or constraints, but it fails to do so.
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 ('Return') and the resource ('port definitions for a circuit'), and the added behavior 'auto-detecting if none are set' distinguishes it from the sibling tool 'set_ports' which would set ports.
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 retrieving port definitions, but it does not explicitly mention when to use this tool versus the sibling 'set_ports' or any other alternative. The usage context is implied by the name and description, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the last simulation results for a circuit.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds the 'last simulation' context, hinting at historical data access. However, it does not disclose what happens if no results exist or if results are updated.
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, front-loaded sentence with no fluff. However, it is almost too minimal; for a simple tool this is acceptable, but additional critical details (like parameters) could be included without sacrificing 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 no output schema, the description should hint at the return format or structure. It only says 'simulation results' without specifying content. The 'summary' parameter effect is unmentioned. For a tool with 2 parameters and no output schema, this is insufficient.
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 0% schema description coverage, the burden falls entirely on the description to explain parameters. The description does not mention 'circuit_id' (the required identifier) or 'summary' (the optional boolean). No additional meaning is provided beyond the schema itself.
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 ('Return'), the resource ('simulation results'), and the scope ('for a circuit' and 'last'). It effectively distinguishes from sibling tools that perform other operations like running simulations or modifying circuits.
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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a simulation must have been run) or cases where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all saved SPICE models from the model library.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds minimal extra context (e.g., 'from the model library') but does not contradict annotations. With annotations covering the behavioral profile, the description adds some value, warranting a 3.
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 conveys all necessary information without redundancy or waste. It is front-loaded and 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 tool has no parameters, no output schema, and annotations provide safety hints, the description is complete enough for an agent to understand and use this simple list operation 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?
The tool has no parameters, and schema description coverage is 100%. The description does not need to add parameter semantics, so it achieves a baseline of 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 that the tool returns all saved SPICE models from the model library. It uses a specific verb ('return') and resource ('SPICE models'), and this purpose is distinct from sibling tools like create_model or delete_circuit.
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 the tool is used to list models, but it does not explicitly state when to use it versus alternatives or provide any exclusions. Given the simplicity, a baseline score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available circuit templates, optionally filtered by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds no behavioral context beyond the filtering capability. It does not mention side effects, caching, or response pagination, which would be helpful for a listing tool.
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, front-loaded sentence with no wasted words. It efficiently conveys the core function and key option.
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 one-parameter input and no output schema, the description is insufficiently complete. It omits details on return format, pagination, error handling, and the effect of null category versus omission, which are important for reliable agent usage.
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 description briefly mentions optional filtering by category, adding some meaning to the sole parameter. However, with 0% schema description coverage, it fails to specify acceptable values, format, or behavior when omitted, leaving the agent to guess.
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 verb (list), resource (circuit templates), and optional filtering by category. It succinctly defines the scope and distinguishes it from siblings like list_models and load_template, 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 description provides no guidance on when to use this tool versus alternatives, such as list_models or load_template. There is no mention of prerequisites, exclusions, or context for when filtering is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a circuit template and create a circuit from it.
If specs is provided, the design-equation solver runs automatically,
results are snapped to E24 standard values, and the netlist .param
lines are updated. Explicit params override solver-calculated values.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | ||
| params | No | ||
| specs | No | ||
| models | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which only show non-readonly and non-destructive), the description discloses key behaviors: automatic solver run if specs provided, result snapping to E24 values, netlist param updates, and explicit param overriding. This 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?
The description is concise with three sentences, front-loading the main purpose and then specifying conditional behavior. No fluff, but could be slightly improved by ordering constraints or prerequisites more clearly.
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 and no output schema, the description covers the main workflow (loading template, optional solver) but omits details on the 'models' parameter and what the tool returns. It is adequate but not fully 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?
With 0% schema description coverage, the description explains the 'specs' and 'params' parameters effectively, but does not describe 'template_id' (required) or 'models'. This leaves two of four parameters unexplained, partially compensating but not fully.
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 loads a circuit template and creates a circuit, with a specific verb and resource. It differentiates from sibling 'create_circuit' by focusing on template loading, but could more explicitly distinguish from 'auto_design' or 'calculate_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?
The description implies usage when loading a template and optionally running the solver, but does not explicitly state when to use this tool versus alternatives like 'auto_design' or 'create_circuit'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure the bandwidth (cutoff frequency) of an AC analysis result.
Uses -3dB by default; specify threshold_db for custom cutoff levels.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| threshold_db | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds behavioral context about the -3dB default and custom threshold levels, but it does not mention what happens if no AC analysis has been run or the output format (e.g., returns a frequency value). This is adequate but not comprehensive.
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 clear sentences with no redundant information. It front-loads the core purpose and adds a specific detail about the default threshold.
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 and the presence of annotations covering safety, the description explains the measurement method and default threshold. However, it does not explicitly state the prerequisite (that an AC analysis must have been run) or the return value, which are important for correct 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?
The schema has 0% description coverage, so the description must compensate. It explains the threshold_db parameter (default -3dB, custom levels) but does not describe circuit_id beyond its name. This partial coverage is acceptable but leaves room for improvement.
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 measures bandwidth (cutoff frequency) of an AC analysis result, with a specific verb and resource. However, it does not distinguish it from sibling tools like measure_gain or measure_power, which could lead to confusion about when to use this tool over others.
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 the tool should be used after an AC analysis, but it does not explicitly state prerequisites, when to use this tool versus alternatives, or when not to use it. No exclusions or sibling differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure the DC voltage at a specific node from operating point results.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| node_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the key behavioral context that the tool operates on operating point results, implying a prerequisite analysis. This goes beyond structured fields.
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 of 12 words, efficient and front-loaded. However, it partially repeats the tool name 'measure_dc' by starting with 'Measure the DC voltage...' which is slightly redundant.
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?
No output schema exists, but the description does not specify what the tool returns (e.g., a voltage value). It also does not mention the prerequisite of running a DC operating point analysis, which is critical for correct use. Two required parameters lack any additional 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?
With 0% schema coverage for parameters, the description does not explain the meaning of circuit_id or node_name. It only mentions 'specific node' without detailing how to specify it. The description should compensate but does not.
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 'measure' and resource 'DC voltage at a specific node', distinguishing it from sibling tools like measure_bandwidth or measure_gain. The phrase 'from operating point results' provides specific 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?
The description implies that the tool should be used after an operating point analysis (e.g., run_dc_op), but it does not explicitly state when to use it versus other measurement tools, nor does it provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure gain and phase at a specific frequency from AC analysis results.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| frequency_hz | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint, so the safety profile is clear. The description adds context about measuring from AC analysis results, but does not disclose the behavior for frequencies not in the results or other edge cases.
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, concise and front-loaded. However, it sacrifices completeness for brevity, missing important details about parameters and output.
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 absence of an output schema, the description should explain the return value (e.g., gain and phase as magnitude/angle or complex). It does not, leaving the agent uncertain about how to interpret results.
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 0%, yet the description only implicitly references the parameters (e.g., 'specific frequency' for frequency_hz, 'AC analysis results' for circuit_id). It does not explain the meaning, units, or constraints of the parameters 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 tool measures gain and phase at a specific frequency from AC analysis results. It uses specific verbs and resources, distinguishing it from sibling tools like measure_bandwidth or measure_dc.
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 after AC analysis has been performed, but lacks explicit guidance on when to use or not use this tool versus alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure power consumption from DC operating point results.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the context 'from DC operating point results,' which implies a prerequisite but does not detail error handling, dependencies, or return 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 a single, front-loaded sentence with no wasted words, achieving conciseness. However, it could include additional context without becoming verbose.
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 (one parameter, no output schema) and the presence of sibling tools, the description is functional but lacks details about output format, units, and usage context, leaving some uncertainty for an 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?
The input schema has one parameter (circuit_id) with 0% schema description coverage. The description does not explain the parameter's purpose or format, failing to compensate for the lack of schema documentation.
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 ('Measure') and the resource ('power consumption from DC operating point results'), which is specific and distinguishes it from sibling measurement tools like measure_dc or measure_gain.
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 (e.g., measure_dc, measure_gain). It does not mention prerequisites like running a DC operating point analysis first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract key transient response metrics (rise time, settling time, overshoot).
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds that it extracts specific metrics, which is helpful but does not reveal additional behavioral traits like required prior simulations or data output format. It adequately complements but does not significantly extend 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, focused sentence of 11 words, front-loading the key action and outputs. No unnecessary words, making it highly efficient for quick comprehension.
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 a single required parameter and no output schema, the description is moderately complete for a simple tool. However, the lack of parameter details and any mention of output nature or usage context leaves room for ambiguity, making it only partially sufficient.
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 0%, and the description fails to explain the parameter 'circuit_id' (e.g., format, valid values, or how it identifies the circuit). The agent has no semantic guidance for providing input, making parameter usage ambiguous.
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 'extract' and resource 'transient response metrics' with specific examples (rise time, settling time, overshoot). This distinctively sets it apart from sibling tools like measure_bandwidth or measure_dc which focus on 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 provides no explicit guidance on when to use this tool versus alternatives. While the name and content imply it's for transient analysis, there is no mention of prerequisites, scenarios, or exclusions to help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify a component value in a stored circuit's netlist.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| component | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose idempotentHint=true and readOnlyHint=false. The description adds that modification occurs 'in a stored circuit's netlist,' providing context about the persistent nature of the operation. However, it does not elaborate on side effects, validation, or error cases. A score of 3 is appropriate as description adds some value beyond annotations but lacks depth.
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, which is concise and front-loaded. However, it may be overly brief, sacrificing necessary detail. It earns its place but could be expanded without becoming verbose.
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 three required parameters, no output schema, and 0% schema coverage, the description is incomplete. It fails to explain the relationship to sibling tools, the expected format of parameters, or the result of the operation. More context is needed for effective agent 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 coverage is 0%, meaning no parameter descriptions exist in the schema. The description does not compensate: it fails to explain the format or meaning of circuit_id, component, or value. Without any semantic guidance, the agent must guess parameter usage, making this dimension severely lacking.
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 and resource: 'Modify a component value in a stored circuit's netlist.' The verb 'Modify' and resource 'component value in a stored circuit's netlist' are specific. It distinguishes from siblings like set_ports or create_circuit, but does not explicitly differentiate. A score of 4 reflects clear purpose but lack of explicit sibling differentiation.
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, no prerequisites, and no context about when modifications are appropriate. It simply states what it does, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the interactive web schematic viewer and return its URL.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | No | ||
| port | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond what annotations provide. Annotations indicate idempotency and non-read-only, but the description does not explain side effects like server startup or whether it opens a browser.
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 front-loads the action and output, but it sacrifices necessary detail for brevity.
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 two parameters and no output schema, the description is incomplete. It fails to explain parameters, the URL format, or any behavioral implications of starting an interactive viewer.
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 0% schema description coverage, the description provides no explanation of the two parameters (circuit_id and port). Their roles are entirely ambiguous to 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 clearly states the action (start) and resource (interactive web schematic viewer), and specifies the return value (its URL). However, it does not differentiate from sibling tools, though no sibling appears to have a similar function.
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 any context about prerequisites 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.
Run AC analysis on a stored circuit.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| start_freq | No | ||
| stop_freq | No | ||
| points_per_decade | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, indicating the tool is safe to rerun. The description adds that the analysis is on a 'stored circuit,' implying the circuit must exist. No further behavioral traits are disclosed, such as output format or error handling, but annotations cover the basics adequately.
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 wasted words. However, it is overly brief, omitting important details that could be included without becoming verbose. It gets a middle score for being efficient but inadequate.
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 4 parameters, no output schema, and many siblings, the description is incomplete. It does not explain parameters, output, or how this analysis relates to others. The mention of 'stored circuit' is the only contextual hint. A more complete description would include parameter guidance and behavioral notes.
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 0% description coverage, and the tool description does not explain any parameter. While parameter names like 'start_freq' and 'stop_freq' offer some clues, the description fails to clarify units, allowed ranges, or the role of each parameter. This leaves the agent with insufficient information to set parameters correctly.
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 'Run' and resource 'AC analysis on a stored circuit', making the basic purpose understandable. However, it does not differentiate this tool from sibling analysis tools like run_dc_op or run_transient, leaving the agent without guidance on when to choose this specific tool.
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. There is no mention of prerequisites, context, or exclusions. Given the many sibling tools for different analyses, this lack of usage guidelines is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run DC operating point analysis on a stored circuit.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds no additional behavioral context beyond 'run', such as side effects or state changes. With annotations present, the description is adequate but does not enhance transparency.
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 of 9 words, front-loaded with the essential action and context. No extraneous information; every word 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?
Despite the tool having only one parameter and no output schema, the description omits critical context: what the analysis returns or how to interpret results, and any prerequisites (e.g., the circuit must exist). This leaves the agent underinformed for correct 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?
The schema has 0% description coverage, and the description does not explain the 'circuit_id' parameter or its role in identifying the circuit. The agent cannot infer the meaning or constraints of this parameter from the description alone, which is a significant gap.
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 ('Run'), the resource ('DC operating point analysis'), and the context ('on a stored circuit'). It effectively distinguishes from sibling tools like run_ac_analysis and run_transient, which perform different analyses.
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 DC operating point analysis but offers no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusion conditions. The agent must infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Monte Carlo analysis under component tolerances.
Randomly varies R/C/L component values within tolerance bands and runs multiple simulations to produce statistical results.
analysis_type: "ac", "transient", or "dc_op" tolerances: map component ref or prefix (R/C/L) to tol %.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| analysis_type | Yes | ||
| num_runs | No | ||
| tolerances | No | ||
| default_tolerance_pct | No | ||
| seed | No | ||
| start_freq | No | ||
| stop_freq | No | ||
| points_per_decade | No | ||
| stop_time | No | ||
| step_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavioral info (readOnlyHint=false, destructiveHint=false). The description adds that it randomly varies component values and runs multiple simulations, but does not disclose side effects (e.g., circuit modifications), time cost, or result storage. It adds some value beyond annotations but could be more specific.
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 (3 sentences) and front-loaded with the purpose. The list of parameter explanations is helpful but incomplete. It earns its place without redundancy, but could be restructured to cover all parameters.
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 11 parameters, no output schema, and simple annotations, the description is incomplete. It does not explain how results are returned, the behavior of many parameters, or the overall workflow. A more complete description would include default tolerance handling, seed usage, and frequency/time dependencies.
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 0%, so the description must explain parameters. It briefly explains analysis_type and tolerances but ignores 9 of 11 parameters (num_runs, default_tolerance_pct, seed, etc.), leaving the agent with insufficient understanding of how to configure the analysis.
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: running Monte Carlo analysis under component tolerances, with a specific verb ('Run') and resource ('Monte Carlo analysis'), and distinguishes from sibling tools that perform single analysis types (e.g., run_ac_analysis).
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 explicit guidance on when to use this tool vs alternatives like run_worst_case or other statistical tools. The description only lists analysis_type options but does not indicate when Monte Carlo is preferable, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run transient analysis on a stored circuit.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| stop_time | Yes | ||
| step_time | Yes | ||
| startup_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false, indicating safe repeated execution. However, the description adds no behavioral context beyond what annotations already convey. It does not explain side effects, required permissions, or how the analysis affects the stored circuit.
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. However, it may be overly terse given the lack of parameter descriptions; conciseness should not come at the cost of completeness.
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 4 parameters (3 required), no output schema, and no sibling differentiation, the description is severely incomplete. It does not explain the nature of transient analysis, parameter semantics, or return values, making it inadequate for proper tool 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 0%, so the description must compensate for parameter meaning. It does not mention any parameters, leaving the agent to infer from names like 'stop_time' and 'step_time' without any guidance on units, constraints, or relationships.
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+resource: 'Run transient analysis on a stored circuit.' It is specific about the action and target, but does not explicitly distinguish from sibling tool 'measure_transient' which may perform a related but different function.
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 guidelines on when to use this tool versus alternatives like 'measure_transient' or 'run_ac_analysis'. No prerequisites or context are provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run worst-case analysis at tolerance extremes.
Evaluates component sensitivity and deterministic corner combinations to find true worst-case performance bounds.
analysis_type: "ac", "transient", or "dc_op" tolerances: map component ref or prefix (R/C/L) to tol %.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| analysis_type | Yes | ||
| tolerances | No | ||
| default_tolerance_pct | No | ||
| start_freq | No | ||
| stop_freq | No | ||
| points_per_decade | No | ||
| stop_time | No | ||
| step_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context that the analysis is deterministic and evaluates corners, which is consistent with idempotency. It explains the behavioral traits beyond annotations (sensitivity, corner combinations), though it could detail more about side effects 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 description is concise with three sentences and a brief parameter list, front-loading the purpose. Every sentence adds value, and there is no redundant or extraneous 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 has no output schema, 9 parameters with 0% schema description coverage, and is moderately complex, the description only covers the core purpose and two parameters. It lacks guidance on circuit_id, frequency/time parameters, and expected return values, making it incomplete for an agent to use properly.
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 0%, and the description only explains two parameters (analysis_type, tolerances) out of nine. It provides examples for those but leaves circuit_id, default_tolerance_pct, and frequency/time parameters undocumented. The description adds some meaning but insufficiently compensates for the low 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?
The description clearly states the verb 'Run' and the resource 'worst-case analysis', specifying it evaluates component sensitivity and deterministic corner combinations to find worst-case performance bounds. This distinguishes it from siblings like 'run_monte_carlo' (statistical) and other analysis types.
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 tolerance extremity analysis and provides example analysis_type values (ac, transient, dc_op) and tolerances mapping. However, it does not explicitly state when not to use this tool or directly mention alternatives like run_monte_carlo, though context from sibling names provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store port definitions for a circuit.
ports maps port names to netlist node names,
e.g. {"in": "in", "out": "out", "gnd": "0"}.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes | ||
| ports | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not contradict annotations (idempotentHint=true, readOnlyHint=false). It adds behavioral context by specifying the format of the ports parameter. However, it does not disclose whether it overwrites existing ports or merges, nor does it describe side effects or return values.
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?
Very concise: one sentence plus an example. Every part is informative. No wasted words or repetitive content. Front-loaded with the core action.
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 2 parameters and no output schema, the description is moderately complete. It explains the purpose and the ports format but lacks details on behavior (replacement vs. merge) and return value. The presence of sibling 'get_ports' provides some 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 0%, so description must compensate. It explains the 'ports' parameter semantics with an example map, adding value. But the 'circuit_id' parameter is not explained beyond the schema. The added context for one parameter is decent but not comprehensive.
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 'Store port definitions for a circuit', which is a specific verb-resource combination. It distinguishes from sibling 'get_ports' by being the setter. The example further clarifies the mapping of port names to netlist node names.
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?
Description implies usage when defining ports for a circuit, but provides no explicit guidance on when to use or when to avoid. No mention of alternatives, such as using 'get_ports' for verification. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the netlist syntax of a stored circuit using ngspice.
| Name | Required | Description | Default |
|---|---|---|---|
| circuit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context that validation uses ngspice, which is beyond the 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 with no unnecessary words. It is front-loaded with the action 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?
With one parameter and no output schema, the description is brief but omits what the validation returns (e.g., success/failure, error details). Annotations cover safety, but behavioral output is missing.
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 0%, yet the description does not elaborate on the single parameter circuit_id (e.g., format, source). It adds no meaning beyond the parameter name.
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 validates netlist syntax of a stored circuit using ngspice, with a specific verb and resource. Among siblings like create_circuit, delete_circuit, or run_ac_analysis, this is unique.
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 use before simulation, but provides no explicit when-to-use guidance or alternatives. No mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct operations (specific analysis types, measurements, or actions). However, auto_design overlaps with the combined workflow of load_template, simulation, and compare_specs, which could cause ambiguity for an agent deciding between high-level and individual tools.
All tools follow a consistent verb_noun pattern with underscores (e.g., create_circuit, run_ac_analysis). The only minor deviation is 'auto_design', but it still uses the same imperative style. Overall, naming is predictable and uniform.
28 tools is moderately high for a single server, but the domain of circuit simulation and design justifies many distinct analysis, measurement, and management operations. The count is on the upper end of reasonable but not excessive, as each tool has a clear purpose.
The set covers core design, simulation, and measurement workflows. Notable gaps include the absence of a tool to list stored circuits (agents cannot enumerate existing circuits) and no tool to delete models or update models. These gaps may cause occasional failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
MCP server for building and testing AI agents with multi-model experimentation and insights.
Research-only MCP server: turn your AI into a quant research desk — backtests, no trades.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/clanker-lover/spicebridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
