Convert SPICE-like electrical descriptions into structured component inventories, node links, and control command details to help AI models understand circuit designs.
把类 SPICE DSL 文本解析为结构化数据 (组件清单、节点、控制指令),便于 AI 理解电路结构。
| Name | Required | Description | Default |
|---|---|---|---|
| dsl | Yes | 电路 DSL 文本。 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the transformation is read-only in effect and names the parsed categories, but says nothing about behavior on malformed/invalid DSL, error signaling, or the exact structure returned. It is adequate but not rich.
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 compact sentence, front-loading the verb and resource before the output detail. Nothing is wasted, though it could be slightly more structured given the parse/output framing.
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, so the description should carry return-value information; it does so only briefly by naming component list, nodes, and control directives. It omits error handling and the concrete output structure an agent would need to consume the result reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter, so the schema already documents the input. The description adds only the format hint 'SPICE-like DSL text', which the name and schema largely convey. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb (parse) and resource (SPICE-like DSL text) plus the output shape (component list, nodes, control directives). This is clear and concrete, but it does not differentiate itself from the sibling parser parse_brd_file, which an agent could plausibly confuse it with.
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 such as parse_brd_file or generate_spice_netlist. The purpose implies a parsing context, but there are no conditions, prerequisites, or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.