ltspice-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, with detailed cross-referencing that resolves potential confusion (e.g., get_waveform vs export_waveform vs plot_waveform). A few overlaps exist—such as run_sweep/run_montecarlo and the various AC analysis tools—but the descriptions explicitly delineate when each should be used.
Naming Consistency4/5
All tool names follow a snake_case convention with a mostly verb_noun pattern (run_simulation, list_components, set_component_value). A few names are nouns or adjectives (resonance, operating_point, recent, parameter), but the overall style is consistent and readable.
Tool Count2/5
49 tools is a very large surface for an MCP server, exceeding the 25+ threshold where coherence tends to degrade. While the domain is broad (simulation, analysis, schematic editing, libraries), the sheer number makes navigation and selection harder.
Completeness5/5
The tool set covers the full LTspice workflow: circuit creation/editing, netlist validation, simulation execution (single, sweep, Monte Carlo), job management, comprehensive signal analysis (time/frequency/AC/noise), and library management. There are no obvious dead ends; every core operation has a corresponding tool.
Average 4.3/5 across 45 of 49 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 110 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description provides no information about optional chaining or behavioral effects beyond what the name implies, which is tautological. No annotations are present to compensate for the lack of adequate transparency. The description adds no safety profile context for mutation is molecular, and there is no deviation from the structured data. No annotation or description reveals behaviors that the agent should know about but doesn't disclose. No requirements for multi-agent context, no rate limits mentioned for a scaled API. The Hazard note applies since no annotation-based awareness of mutations or potential for side effects is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Almost no structure is present due to clear hardware and missing context, and the output schema is present, adding zero value. The description is very short but extraordinarily cryptic. Otherwise, the answer is impossible or impossible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a completely inadequate description and transparent insight is missing the required depth. The title is irrelevant, and no schema exists or optional is entirely absent, severely limiting the ability to effectively use the tool. The presence of the output_schema does not make up for the level of output. This is broken at the most basic intent level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description is a garbled schema that obfuscates schema meaning, and the parameters shown (#3) are not understood. The schema does heavy lifting by defining the parameter count, but the description fails to clarify their semantic role. Schema coverage is not 100% covered by the description for the needed names. The parameters listed are actually 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is garbled and includes schema/JSON artifacts. The tool name is 'list_libraries' and the title is 'list_libraries', but the description is pure tautology, restating the tool's purpose without a clear verb-resource structure. It provides no meaningful information about listing libraries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 over siblings like list_components or find_model. The garbled text mentions 'with detail=true', suggesting documentation issues, but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries full weight. It only says 'load into the session' but does not disclose whether loading replaces existing libraries, is idempotent, has side effects, or what happens on errors. This is minimal disclosure for a state-modifying operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded, with no redundant words. Every element adds meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the core action but omits behavior like replacement policy, existence checks, or interaction with other tools (e.g., whether loaded libraries are automatically used by simulations). Given the minimal annotations, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Path to library file or directory'. The tool description adds file extensions (.lib, .mod) and clarifies that a directory is accepted, providing marginal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Load' clearly specifies the action (loading a SPICE library file or directory), and it explicitly names the resource types (.lib, .mod). It distinguishes from siblings like unload_library and list_libraries by stating the purpose of making libraries available to the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('into the session') but does not explicitly state when to use this tool versus alternatives like find_model or unload_library, nor does it mention any exclusions or prerequisites. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered by structured data. The description adds the 'using LTspice' context but does not explain what may be destroyed (e.g., overwriting an existing .net file) or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately states the core conversion action, and contains no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with annotations covering side-effect safety, the description is mostly complete. It would benefit from mentioning the output destination or that LTspice must be available, but it gives sufficient context for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the single 'path' parameter is fully documented as 'Path to .asc schematic to export.' The description adds no additional meaning beyond matching that parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resources: 'Export an .asc schematic to a SPICE netlist (.net) using LTspice.' This clearly identifies the tool's function and distinguishes it from siblings like validate_netlist or export_waveform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_netlist or validate_netlist. It implicitly assumes the agent will know this is the export path, but gives no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint, indicating safe operations. The description adds that limit is capped at 50 and pagination is possible, which is behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the primary purpose and two optional behaviors. It is concise with no fluff, though it could be more explicit about the two modes of operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return formats are covered. The description is sufficient for a read-only listing tool with 6 parameters, but could better explain the difference between 'reference' mode vs 'prefix' mode and when to use each.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well documented. The description adds little: it mentions 'type prefix' and 'single component value by reference' which clarifies the 'prefix' and 'reference' fields slightly, but mostly redundant with schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists components in a circuit file, with optional filtering by prefix or returning a single component by reference. It distinguishes from siblings like component_info (which presumably provides details on a known component) and set_component_value (mutation), but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing or reading components, but doesn't explicitly state when to use this vs component_info or other query tools. It mentions optional filtering and single lookup, which hints at usage scenarios, but lacks clear guidance on when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false, etc.) and provide no safety profile. The description discloses that it runs asynchronously and returns a job_id immediately, which is useful behavioral context. It doesn't mention what happens on failure, or that it may consume resources, but given the annotations are sparse, the description adds some value but could be more explicit about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that packs in key details: 'previously configured', 'asynchronously', 'return a job_id immediately'. No fluff, front-loaded with the action, and completely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity is low (2 params, no output schema, no nested objects), the description adequately covers the essential aspects: what it does, the async nature, and the return. It could mention that it returns a job_id for tracking, but it already does. It doesn't explain how to use the job_id, but that's likely covered by other tools like check_job. Overall, it's reasonably complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the description adds little beyond what the schema already provides. The description mentions 'previously configured' which reinforces the config_id parameter's role, but doesn't add extra detail about max_parallel. With full schema coverage, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a previously configured parameter sweep and returns a job_id asynchronously. It uses a specific verb (execute) and resource (parameter sweep), and it distinguishes from siblings like run_montecarlo by focusing on 'parameter sweep' rather than Monte Carlo. However, it doesn't explicitly name the alternative, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: 'previously configured' and 'config_id' from configure_sweep or configure_montecarlo. It doesn't explicitly say when not to use it or mention alternatives, but the context of requiring a config_id implies it should be used after configuration. Sibling tools like run_montecarlo exist, but no contrast is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the list of report sections but no extra behavioral context (e.g., performance for large files, reliance on job_id vs raw_file). With annotations present, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action and lists key outputs. No extraneous words or repetition; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a present output schema, full parameter descriptions, and safety annotations, the description is sufficient for a summarization tool. It covers all major report components, and the agent can infer that no side-effects occur. Slight miss: no mention of the job_id/raw_file choice, but that is schema-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – every parameter has a detailed description in the input schema. The tool description does not add any parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('comprehensive simulation summary') and enumerates the exact contents (type, signal list, data size, .MEAS results, Fourier analysis, AC bandwidth metrics, warnings). This clearly differentiates it from siblings like bode_metrics or thd, which target specific analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., batch_results, check_job). It does not mention prerequisites, workflows, or exclude cases. Given the rich sibling set, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate modifying nature (readOnlyHint=false), but description doesn't mention potential side effects such as overwriting existing connections or changing netlist. Lacks explicit warning about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description adequately covers the function, parameters, and behavior. It explains the conditions for waypoints sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are detailed with examples for pin references and waypoints. The description reinforces the meaning of waypoints and when they are needed, adding clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Connect two component pins with wire(s)' and notes automatic position resolution. It distinguishes from other tools by focusing on wiring, though no explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides details on when to use waypoints and when they can be omitted, guiding the user on the proper invocation. No explicit alternative guidance, but sufficient context for a schematic editing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations contain no safety or read-only hints, leaving the description to carry the full burden. The description mentions 'empty .asc' but does not describe permissions, side effects, or constraints. Given the presence of a large sibling list, the behavioral disclosure effort falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with an appositive phrase ('empty .asc') and a helpful naming convention example. Each element is essential and well-placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description must carry the full burden for this simple tool. Given a schema and annotations that are lean, the description remains incomplete, a shortcoming that undermines its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only a single parameter at 100% coverage, and the description does not provide supplementary semantics for it. The description's reference to 'iterative editing' doesn't add any extra meaning that might otherwise be conveyed in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create', the resource 'schematic', and the scope 'empty .asc', which unambiguously identifies the operation. It is unambiguous and clear in its intent, even though it lacks an explicit distinction from deeper siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, and the phrase 'Prefer schematic_capture for exact sizes and redundancy' explicitly names an alternative tool, finding the semantic gap in the introductory clause. This is an explicit when-other-alternative reference that adds clarity to the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=false) by indicating a mutating action, and adds context about the file type and grid positioning. It does not disclose side effects like duplicate reference handling or whether existing file content is preserved, but the annotations already cover the basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. Every word contributes meaning, naming the action, target, and positioning requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, annotations, and presence of an output schema, the one-sentence description is largely sufficient. It does not explain less obvious behavior like duplicate references or file-creation semantics, but these are not needed for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the input schema. The description adds little beyond the schema, only framing the action as adding to a schematic at a grid position. This meets the baseline for a high-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and clearly identifies the resource ('a new component to an .asc schematic') and a key constraint ('at a specified grid position'). This distinguishes it from sibling tools like set_component_value or create_schematic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding new components to schematics, which is sufficient for basic selection. However, it does not explicitly state when not to use it or mention alternatives for modifying existing components or creating schematics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is well covered. The description adds that it reads from an .asc file and returns specific fields, but it does not disclose error handling or other behavioral details beyond what annotations imply. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with the verb 'Get' front-loaded. All words are meaningful and it avoids redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and presence of an output schema, the description is sufficient for this read-only tool. It lists the key data returned and the input context, though it could optionally mention behavior when components are missing, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter (path, reference, format) is already described. The description does not add additional meaning or constraints to the parameters beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (get), the resource (placed component), and the data retrieved (pin positions, bounding box, value, attributes) from an .asc schematic. It is distinct from siblings like symbol_info or list_components, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (placed component, .asc schematic) that implies when to use it, but it does not explicitly mention alternatives or when not to use it. No user guidance is provided regarding comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true), and the description adds a specific behavioral detail: automatically appending .END if missing. This goes beyond the annotations without contradicting them, providing useful context about file handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and a single notable behavior. There is zero redundancy or filler, every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and annotations flag destructive behavior, the description adequately explains the core function and a key side effect (.END appending). It does not describe return values, but no output schema exists and this is not critical for a creation tool. The description is sufficient for an agent to use correctly, though slightly more detail on overwrite handling could be added.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter documentation (e.g., name handling, overwrite default). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and resource (SPICE netlist file) along with the input source (content string). It distinguishes this tool from siblings like export_netlist or validate_netlist by specifying 'new' file creation, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating netlists but does not explicitly contrast with alternatives (e.g., edit_directive for modifying existing files, read_circuit for reading). No clear 'when not to use' guidance is provided; only the general context of 'new' is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond annotations by specifying different outputs for netlists ('content and component values') versus schematics ('layout and directives'), which helps the agent predict behavior across file types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource, and wastes no words. Every sentence adds distinct value: the first states what it does, the second clarifies format-specific behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only parser, the description is largely complete given the rich annotations, fully documented schema, and existing output schema. It could have added note about unsupported file types or error behavior, but these are minor gaps for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds context about file extensions and return categories, but it does not materially improve on the parameter-level detail already present in the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read and parse') and names a concrete resource ('a circuit file (.cir/.net or .asc)'), with distinct return behavior for netlists versus schematics. This clearly distinguishes it from sibling tools like create_netlist, export_netlist, and list_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining what the tool reads and what it returns, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. Context is present, but there is no direct 'use this instead of X' guidance despite many related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, which cover safety. The description adds minimal context ('from the session') but does not elaborate on behavior such as idempotency or what happens if the library doesn't exist. With annotations present, the description meets the baseline but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and all words contribute to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter fully described and no output schema, the description is nearly complete. It states the resource and action. It lacks details like effects of unloading a non-existent library or whether unloading is reversible, but given the simplicity and annotations, it's sufficient. A score of 4 reflects its adequacy without excess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'path' parameter is fully described as 'Path to library file or directory to unload'. The description repeats the parameter concept but adds no additional semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'unload' with a clear resource 'library' and scope 'from the session'. It distinguishes itself from sibling tools like load_library (loading) and list_libraries (listing) by clearly stating the action of removing a previously loaded library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously loaded' implies use after a library has been loaded, which gives clear context. However, it does not explicitly name alternatives or when-not-to-use scenarios. For a simple tool, this is adequate but slightly under explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns a config_id and is non-destructive (configuration only). This aligns with annotations (idempotentHint true, destructiveHint false) and adds a small extra detail about the return value beyond the annotation set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('Configure') and includes the key outcome ('return a config_id'). It is concise without omitting essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema with many parameters, the high-level description is sufficient because the schema carries the detailed semantics. It mentions the core function and output, making it complete for its purpose, though it omits specifics like mismatch handling that are covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed parameter descriptions. The top-level description does not add meaning beyond what the schema provides, so it sits at the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: configuring a Monte Carlo analysis with component tolerances and returning a config_id for later execution. It distinguishes from siblings like run_montecarlo (execution) and configure_sweep (sweep setup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a setup step before running ('for later execution'), which functionally separates it from run_montecarlo. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a perfect explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the safety profile is covered. The description adds meaningful behavioral detail beyond that by specifying the categories of changes detected (components, attributes, .PARAM/.MEAS/.MODEL directives), giving the agent a concrete sense of the tool's output scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in sentence one and usage context in sentence two. Every word contributes value; no fluff or repetition of the schema. This is a model of efficient tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only diff tool with no output schema, the description provides the key output categories and a usage trigger, which gives the agent enough context to invoke it correctly. It does not describe exact return formatting, but the format parameter and listed report categories cover the essentials, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents path_a, path_b, and format. The description adds little parameter-specific semantic beyond implying two file paths; it focuses on the diff behavior rather than explaining the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'diff' and names the resource ('two circuit files'), then enumerates exactly what it reports: added/removed components, changed values/attributes, and added/removed directives. This clearly distinguishes it from sibling tools like read_circuit or validate_netlist, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly tells the agent when to use this tool: after set_component_value, set_component_attribute, or edit_directive, to confirm a change landed. This is clear context, though it stops short of naming when-not-to-use or alternative diff tools, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, but the description explicitly states 'asynchronously and return a job_id', which discloses non-blocking behavior and output. This adds information beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, includes all essential elements: execute, previously configured, asynchronous, job_id. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mentions the output (job_id) despite no output schema, covering the immediate result. Does not detail job polling but that is not required for the action itself. Adequate for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes both parameters (config_id from configure functions, max_parallel with default). The description does not add further parameter-specific details; baseline applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (execute) and resource (Monte Carlo analysis), distinguishing it from siblings like run_sweep or configure_montecarlo. Mentions async and job_id, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates that the analysis must be 'previously configured', implying a prerequisite step (configure_montecarlo). While it doesn't explicitly contrast with alternatives, the name and context make its intended use clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only, not idempotent, and not destructive. The description adds context about setting batch flags, handling the ngspice headerless-raw dialect, routing artifacts, and sync/async execution. It does not contradict annotations and provides useful operational details, though error handling is not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single substantial paragraph, front-loaded with the core purpose. It's structured with clear sentences about execution modes and return values. It's slightly verbose but every sentence adds value; no filler. A more concise version could trim details, but it's not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers essential context: sync/async behavior, timeout semantics, and return types. It explains why to use this tool (avoid parsing rawfiles) and how it handles long simulations. It's complete enough for an agent to effectively invoke and understand the outcome, though it doesn't mention error scenarios or partial failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enriches semantics by clarifying timeout defaults, the 30s async threshold, and the 600s hard ceiling with wait=true. It also explains that wait=true forces sync execution, adding meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a SPICE simulation on a netlist file, handles ngspice-specific details, and parses results. It distinguishes from siblings like run_sweep and run_montecarlo by explicitly focusing on a single simulation and automating rawfile parsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use synchronous vs asynchronous execution (short vs long simulations) and mentions wait=true to force sync. While it doesn't explicitly list alternatives, the context makes it evident this is for single simulations, with siblings for sweeps/montecarlo. It gives clear guidance on timeout behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by listing the kinds of status information returned (simulators, config, sandbox paths, runtime state), which goes beyond the annotation metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first front-loads the action and resource with specific details, and the second provides actionable usage guidance. Every word serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (one optional parameter, no nesting) and has an output schema, so the description need not detail return values. It sufficiently covers what the tool reports and when to use it, making it complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single optional 'format' parameter, so the schema fully documents semantics. The description itself adds no parameter-level detail, which is acceptable because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('comprehensive server status'), and enumerates concrete contents: detected simulators, configuration settings, security sandbox paths, and runtime state. This clearly distinguishes it from sibling tools such as run_simulation or check_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use this to check what capabilities are available before attempting operations.' It implies a pre-flight check role but does not explicitly list when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, and the description aligns with this by noting deletion is 'the inverse of setting one' and that it matches by name so a just-added parameter can be removed even after reformatting. It also explicitly states that value is required when name is specified, adding behavioral detail beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that cover the core functionality and a key usage pattern. It front-loads the main purpose and includes an important caveat about deletion. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With high schema coverage (100%), a clear description, and annotations, the tool is well-documented. The output schema exists, so return values need no explanation. Slight deduction for not mentioning file path extension restrictions (though schema does) and not clarifying behavior when no parameters are read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds clarity on how name, value, and delete interact: value is required when name is specified, delete is mutually exclusive with value, and name can be omitted to read all params. This goes beyond the schema's individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'Read, write, or delete .PARAM directive values in a circuit file.' It specifies the resource (.PARAM directive values in a circuit file) and actions (read, write, delete), making it distinct from siblings that deal with components, netlists, or simulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains that setting a parameter is the inverse of deleting it, and gives an example for deletion ('Pass delete=true with name to remove a parameter'). However, it does not explicitly mention when not to use this tool versus alternatives like edit_directive or set_component_value, though sibling names suggest some overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds behavioral context: it mentions that a no-op value write is reported as unchanged, which is useful. It also clarifies that nodes rewrite is only for .cir/.net and not for .asc, and that nodes cannot be combined with value/values. This goes beyond the annotations by explaining the behavior of the tool in specific scenarios. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It states the main purpose in the first sentence, then adds a note about no-op behavior. It's two sentences total, with no wasted words. The information is dense but clear. It doesn't repeat what's in the schema, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, multiple parameters, file type restrictions), the description covers the key points: modes, file type constraints, parameter combinations, and no-op behavior. It doesn't explain return values, but there's no output schema, so that's not required. It could mention what happens on error or the exact format of the response, but for a tool with good schema coverage and annotations, this is sufficient. The description is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the modes (single vs batch) and the relationship between parameters (e.g., nodes requires reference, not combined with value/values). It also provides examples for value and values. This adds meaning beyond the schema's basic descriptions, though the schema already covers the basics. The description helps clarify the parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting component values in single or batch mode, and rewriting node connectivity. It specifies the resource (circuit file) and the actions (set value, rewrite nodes), and distinguishes between the two modes. It also differentiates from siblings by mentioning the specific operation on component values/nodes, which is distinct from other tools like add_component or edit_directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for setting values or fixing node connectivity. It mentions constraints like 'single mode only' for nodes, and that nodes requires .cir/.net only, and not combined with value/values. However, it doesn't explicitly state when not to use this tool or mention alternatives (e.g., for .asc files, it says 'wire pins with connect' but doesn't name the tool). It gives some guidance but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context on the dual modes (list vs. detail) and what happens without job_id. It doesn't describe error handling, but given the annotation coverage, it adds sufficient value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. No fluff; every clause earns its place. The structure clearly separates the two modes and ties in the filter option efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are already specified there. Description covers all main usage scenarios (list vs. detail, status filtering) and references run_simulation for the job_id source. With 3 optional parameters and clear annotations, this is complete for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds integration logic: how job_id and status interact (without job_id lists jobs, with it returns details), which goes beyond individual schema descriptions. It clarifies the conditional behavior, adding meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Check status of a simulation job by ID, or list all jobs.' It distinguishes two modes (without job_id: list; with job_id: detailed status/completion), which makes it unique among siblings like cancel_job or batch_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool: without job_id for listing jobs, with job_id for specific details, and when to filter by status. However, it doesn't explicitly mention alternatives or when not to use it (e.g., for batch results use batch_results), though the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavioral detail beyond those: the sqrt(∫ density² df) calculation, the LTspice Ctrl-click equivalence, and the fact that it reports the integrated band and sample count. This goes well beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the purpose. The formula, output summary, and SNR caveat each add distinct value; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full input-schema coverage, the output schema, and the rich annotations, the description is complete enough. It explains the mathematical behavior, what the tool reports, and what it intentionally leaves out, which is sufficient for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all 8 parameters already have descriptive text. The tool description adds high-level context about band and trace semantics, but it does not add new per-parameter meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and target: 'Integrate a .noise spectral density to a total RMS noise over a band.' It clearly distinguishes this from sibling measurement/plotting tools by focusing on RMS noise integration, and even states the exact formula used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context (banded integration of .noise spectral density) and an explicit non-goal ('Noise figure / SNR are left to you'), but it does not name an alternative tool or provide direct when-not-to-use guidance beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and destructiveHint, the description discloses key behaviors: edge-detection mechanism (threshold crossings), definition of a period (span between consecutive rising crossings), the formula num_periods_measured = num_rising_edges - 1, null duty_cycle/pulse_widths when no full periods, and instability with DC drift. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear paragraphs covering use case, returns, measurement mechanics, threshold behavior, and usage tips. Every sentence adds useful information—no fluff. It is front-loaded with the primary use case. Though a bit longer, it's density of useful info justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, subtle jitter semantics), the description covers return values, null cases, threshold behavior, edge count relationship, and output schema exists for further details. It is complete for an agent to decide when to use it and how to set parameters correctly. No gaps for an oscilloscope-style periodic measurement tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (all parameters have descriptions), so the baseline is 3. The tool description adds context on threshold, min_periods, and t_start/t_end usage, but the parameter descriptions already cover semantics. Edge cases like null returns are explained in the tool description, but not much additional parameter-level detail is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes oscillating transient signals (clock, oscillator output, switching waveform) and lists the metrics returned: period, frequency, duty cycle, pulse widths, and jitter. It distinguishes from sibling edge_metrics by noting 'for a single edge (not periodic), use edge_metrics.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use (oscillating transient signals), how to set threshold for DC drift, use min_periods to guard against 1-edge windows, skip startup transient via t_start/t_end, and explicitly directs to edge_metrics for single-edge cases. This clearly differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true digital matching the non-destructive nature. The description adds that it returns pin positions, bounding box, and description, and indicates optional computation behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence stating the tool's function. The input schema is well-organized with defaults, enums, and descriptions. No redundant or excessive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and optional behavior. However, it doesn't specify what 'absolute positions' means precisely or when it's useful, and doesn't mention alternatives or edge cases. Still, context is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter has a clear description: 'symbol' with examples, 'x'/'y' as placement coordinates, 'rotation' with enum values, 'format' with choices. Required parameter is specified. Meaning and purpose are unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' with specific resources: 'symbol pin positions, bounding box, and description.' It also distinguishes itself from siblings like component_info and list_components by focusing on symbol-level geometric and descriptive data, with an optional absolute-position computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call when you need symbol pin positions, bounding box, or description. It explains optional behavior for computing absolute positions when placement x/y/rotation are provided. It doesn't explicitly state when NOT to use it versus alternatives like component_info, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavioral detail beyond that: it follows wires segment-aware (catching mid-wire labels) and tracks same-name FLAGs (LTspice's name-based nets). This provides algorithmic insight not otherwise available, fulfilling the transparency requirement without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and then expands with selective details (segment-aware, FLAG handling). Every clause adds value, and it avoids redundancy with the schema. It is concise without sacrificing completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a moderate complexity tool with an output schema present, the description covers all necessary aspects: input methods, output types, and practical use cases. It does not need to explain return values because the output schema handles that. The description is self-sufficient and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter having a description. The description itself does not add new parameter semantics beyond what the schema already provides (e.g., pin syntax, coordinate alternative, format choices). It only reinforces existing information, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to report everything electrically connected to a net, with specific input types (pin, net label, or coordinates) and exact outputs (labels, pins, flags, wire vertices). The phrase 'what's on net X' further clarifies its intent and distinguishes it from sibling tools like list_components or connect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: answer 'what's on net X', confirm a connect landed, spot an accidental short. However, it does not explicitly state when NOT to use it or mention alternatives. The when-to-use guidance is strong, but the absence of when-not or alternative tools prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral transparency beyond the annotations. It explains the default behavior (peak across waveform, conflates startup/roll-off with run-to-run variation), the effect of the `at` parameter on slicing, and the `raw` parameter's relationship to reductions versus raw samples. It correctly matches the annotations (readOnly=true, idempotent=true, destructive=false) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is two sentences: first states the purpose, second explains the two modes concisely. Every word serves a purpose. The parameter descriptions enrich the schema with valuable caveats without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with good parameter schema coverage and an output schema, the description is complete. It covers the main behavioral branches, exception cases (when NOT to use for raw samples), and integrates well with the rich schema. Could arguably include a precondition that the job_id exists, but this is implied by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has rich per-parameter descriptions, so the description doesn't repeat them. The primary description adds high-level semantics about the two usage modes. The schema descriptions provide full context including an important caveat in the `at` parameter about AC sweep aliasing and in `raw` about reduced rows not being sample vectors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a batch simulation job and differentiates two modes: without a signal it returns job status/progress, with a signal it returns aggregate statistics or per-run data. It explicitly names the sibling tools run_sweep and run_montecarlo (in the job_id parameter) as the source of job IDs, which differentiates it from other query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use it (for batch simulation jobs, sweep or Monte Carlo) and the signal param differentiates modes. The raw parameter description explicitly states when NOT to use it for raw samples (use export_waveform or get_waveform instead). It doesn't explicitly exclude other siblings but context makes the tool's place clear versus similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing that it kills the simulator process(es) and marks the job as cancelled. This provides useful behavioral insight, though it does not elaborate on potential side effects such as resource cleanup or data loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that directly state the operation and its effect without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and no output specification, the description fully covers the tool's purpose and effect. It is complete for the agent to understand what the tool does and what input is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, job_id, is fully described as the identifier of the running simulation to cancel. This matches the schema and provides all necessary meaning for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool cancels a running simulation job, and it distinguishes between single runs and batch jobs. It explicitly mentions killing simulator processes and marking the job as cancelled, which is specific and unique among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a running simulation needs to be stopped) but does not explicitly discuss alternatives or when not to use it. However, the purpose is clear enough that an agent would understand the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true, which are consistent with the description's non-destructive aggregation behavior. The description adds substantial behavioral details beyond annotations: it explains edge-case handling for WHEN-style .MEAS, the aggregated_field output, and behavior for single runs (n=1). It also notes what happens with different job types, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but front-loaded with the core purpose and examples. Each paragraph adds specific information, but some redundancy exists (e.g., repeating the job_id/log_file distinction already in the schema). It could be slightly condensed while maintaining clarity, but it is well-organized and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with an output schema that likely covers return values. The description fully compensates for any gaps: it covers measurement aggregation, edge cases (WHEN-style), job types, and options like histogram_bins. It also mentions the output includes aggregated_field and 'at' fields, ensuring the agent understands the return format. This is comprehensive given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains all parameters (job_id, log_file, measurement, histogram_bins, format). The description adds value by explaining the distinction between job_id and log_file use cases (batch vs single-run logs), but this is minimal beyond the schema. For example, it clarifies that job_id is for batch jobs and log_file for single .step logs, which is useful but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: aggregating .MEAS scalar results from .step sweeps or Monte Carlo runs. It uses a specific verb ('AGGREGATE') and capitalizes key terms (.MEAS, .step, Monte Carlo), giving concrete examples of questions it answers ('what's the worst-case rise time?'). It distinguishes itself by focusing on .MEAS aggregation, setting it apart from sibling tools like signal_stats or simulation_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: for aggregating .MEAS results across a sweep or Monte Carlo run, or for single-simulation jobs. It also provides alternatives: 'simulation_summary also just reads the raw scalars' and 'Pass measurement=NAME to aggregate just one'. This clear when-to-use guidance differentiates it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive hints, the description discloses important behaviors: SI units where declared, uniform naming across simulators, automatic .options logopinfo, and the critical warning that a solve failure taints all values and appears in 'warnings'. This is valuable context not available from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: front-loaded purpose, then scope details, then a warning. It is dense and every sentence contributes, though the first paragraph packs many clauses into a single long sentence, slightly reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers tool purpose, simulator sources, device filtering, units, and failure-mode warnings. With a rich input schema and an output schema present, nothing critical appears missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema descriptions already cover all 7 parameters thoroughly, so the baseline is 3. The description adds meaningful usage semantics: passing device='M1' yields that device's params plus terminal currents in one call, and explains the uniform naming and unit behavior. This exceeds baseline without needing to restate schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read DC operating point data' and enumerates exactly what is included: node voltages, branch currents, and small-signal params. It clearly distinguishes this from waveform, simulation summary, and other sibling tools by specifying the operating-point scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on when to use the tool (reading DC operating point from LTspice log or ngspice traces, after run_simulation auto-adds .options logopinfo). It also explains the device-filter use case, but it does not explicitly state when to prefer another tool or when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only/idempotent/non-destructive annotations already communicate safety; description adds contextual flags: settling_time negative in three cases with quality distinctions ('never (within window)', 'undefined (full-window)', 'unknown' when trailing window too noisy), plus rejection of AC analysis. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but justified for 11 params in a signal-analysis tool: lead with 'Use when...', 'Returns...', 'Definitions' convention; parameter descriptions are dense with defaults, ranges, and are free of padding. Beyond schema it is not lengthy: not a single wasted sentence for this scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a step-response tool: 11 params fully documented, output schema, annotation flags, default/alternative semantics, explicit auto-detection setting (first/last 10%) contamination in the initial/final, window, noise desciptions. Sibling tools for rising/falling times given; output schema provides the values; semantic coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of 11 params; descriptions enrich defaults (0, auto = mean first/last 10%), invalid combinations (job_id OR raw_file required), output schema present; descriptive defaults added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb+resource: 'step response quality metrics: overshoot %, undershoot %, settling time, peak value, peak time.' Distinguishes from edge_metrics for rise/fall time without overshoot. Clearly identifies input (transient .raw covering ONE step, ideally edge near t_start, tail) and return values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use when you need step response quality metrics'), includes exclusion ('For just rise/fall time without overshoot, use edge_metrics') and exclusions ('Rejects AC analysis.').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive hints, and the description goes further: explains phase unwrapping, null margin handling (infinite/undefined), conditional stability warnings, and multi-crossing behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, usage, returns, nuances. Front-loaded with core function, then edge cases. A bit long but every sentence adds value; could be slightly trimmed but remains efficient for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and existing output schema, the description covers all key aspects: return values, edge cases (never-crossing phase/gain), multi-crossing behavior, and disambiguation from siblings. Comprehensive without needing the output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%) and parameters like signal, raw_file, job_id, run_index, min_separation_decades already have clear descriptions. The tool description adds minimal new parameter semantics, mostly contextual (e.g., loop-gain requirement) but does not exceed baseline for well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it finds all unity-gain and -180° phase crossings, reports phase/gain margins, and replaces a flawed approximation in simulation_summary. It clearly distinguishes from bode_metrics and simulation_summary, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use instructions: run on LOOP-GAIN signals, warns against closed-loop outputs, and names alternatives for other cases (bode_metrics for filter cutoffs and custom crossings). Includes warning detection and clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds extensive behavioral detail: it lists categories of issues caught (dangling nodes, bias degeneracies, duplicate directives), distinguishes warnings from errors, and explicitly states what is NOT checked (value tokens, undefined models). It also explains differences between LTspice and ngspice modes. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but every sentence adds value. It might benefit from bullets for readability, but it's appropriately sized given the tool's complexity and covers all critical information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description thoroughly covers purpose, checks, exclusions, parameter behavior, and return expectations. The presence of an output schema relieves the need to explain return format; the description emphasizes the empty-list meaning, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant context for target_simulator by explaining which gates each simulator selection activates, going beyond the schema's basic enum. It also clarifies the path parameter's accepted extensions. This pushes the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as a static circuit check gate that lints netlists/schematics before simulation, enumerating specific checks. It clearly distinguishes itself from simulation, creation, and export siblings by focusing on pre-flight validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use (before simulation) and explains how the target_simulator parameter changes the set of checks applied. It doesn't explicitly mention when not to use, but the context is clear enough for an agent to select this tool for validation tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/safe, and the description adds substantial behavioral context: the rational-fit-then-asymptotic-fallback algorithm, finite-sweep accuracy caveats, merged corner behavior, non-guaranteed pole/zero counts, and the requirement for human review against the Bode plot. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence carries real information: purpose, algorithm, output semantics, critical flag implications, caveats, accurate-result alternative, and sibling pointers. Formatting with an IMPORTANT callout helps prioritize the human-review requirement without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex analysis tool with an output schema and rich annotations, the description covers algorithm behavior, result interpretation, known limitations, prerequisite conditions, and alternative tools. It is complete enough for an agent to know exactly when to call it, what to expect, and how to guard against misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%) and already documents signal, raw_file, job_id, run_index, and format. The description adds only contextual clues (e.g., plot_waveform on the same signal, pass raw_file OR job_id), but does not extend parameter-level meaning beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Read the pole/zero STRUCTURE of an .AC response' and enumerates concrete outputs (net order, corner frequencies, Q, out-of-phase zeros, transport delay). It clearly differentiates from sibling analysis tools by naming each sibling's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the intended reasoning use case, the required prerequisite ('.AC run'), an alternative for exact results ('.pz analysis'), and names sibling tools with their different focuses (bode_metrics, resonance, stability_metrics). It also tells the agent not to act on magnitude alone when non_minimum_phase is flagged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, which are somewhat ambiguous, but the description discloses key behavioral traits: comment is .asc-only (with refusal on .cir/.net), remove uses exact match or regex, and errors when nothing matches to prevent silent failures. This adds value beyond the sparse annotations, though it could mention idempotency or side effects more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose and key rules, and every sentence earns its place. It covers the essential distinctions (kind, file types, remove behavior, param exclusion) without padding, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (3 required) and no output schema, the description covers the tool's operation thoroughly: file type constraints, default behaviors, matching semantics for remove, error handling, and cross-tool guidance. Combined with the detailed schema, an agent has sufficient information to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich param descriptions, so baseline is 3. The description enhances semantics by clarifying that 'instruction' holds directive text, comment text, or regex patterns for remove, and by noting the auto-placement behavior for x/y coordinates. It adds practical value like the regarding comment-only on .asc, which the schema already notes but the description reinforces via examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or removes SPICE directives or .asc free-text comments, specifying the two kinds and the file types. It distinguishes from the 'parameter' sibling by explicitly excluding .param support, and the resource (directive/comment) is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides detailed when-to-use guidance: default kind is directive, comment is .asc-only, and removal matches both kinds. It explicitly directs callers to use the 'parameter' tool for .param, and instructs to copy lines verbatim from read_circuit for remove operations, minimizing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses extensive behavior beyond the sparse annotations (readOnly=false, etc.): lossless windowing, supported analysis types, complex AC formatting with wrapped phase, tidy/long stepped-run output, and the observations list surfacing facts not verdicts. It adds significant context that the annotations do not supply, fully shouldering the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though the description is long, every sentence earns its place: it covers purpose, supported analyses, complex handling, stepped-run format, observations, output contents, and sibling differentiation. It is front-loaded and efficiently structured, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 optional parameters, multiple analysis types, varied output formats) and the presence of an output schema, the description covers all essential aspects: it explains the CSV output path, row/column counts, observations, and edge cases (stepped runs, complex traces). It leaves no major gaps for an agent to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters in detail (e.g., t_start, complex_format, signals). The description adds some behavioral context (e.g., 'phase is the wrapped np.angle — run np.unwrap yourself') but it does not materially expand parameter semantics beyond what the schema provides. A baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Full-fidelity waveform egress: write every sample of one or more signals to a CSV file on disk and return its path') and clearly distinguishes from siblings by contrasting with get_waveform (decimated envelope) and plot_waveform (interactive picture). It leaves no ambiguity about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'for when you want to compute on the raw data yourself' and names alternatives: 'sibling egress, don't confuse: get_waveform returns a DECIMATED envelope... plot_waveform renders an interactive PICTURE... For a single scalar use signal_stats/query_value.' This gives clear when/when-not guidance and points to relevant alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true explicitly, and the description doesn't contradict that. It goes beyond annotations to disclose the WSL/LTspice path-format quirkchers, the port/params/device_type fields, and the warning about wiring order for .MODEL devices — valuable context for an agent. Minor gap: no mention of the default cutoff behavior or that results are ranked, but the fuzzy-matching and exact behavior are clearly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long (≈200 words) but every sentence earns its place: fuzzy-matching behavior, exact mode, field semantics, WSL path nuance, and .MODEL vs subcircuit distinctions are all covered. It is front-loaded with the purpose and then expands into detail. Slightly dense, but not bloated — a solid 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema and comprehensive annotations, the description exceeds the bar. It covers when to use fuzzy vs exact, what each returned field means, the WSL path context, and the critical usage gotcha (wiring .MODEL parts without node order). For a 7-parameter tool with high schema coverage monitored externally, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3. However, the description adds significant value: it explains the *semantics* of the returned fields (ports, params, device_type, usage order string) and clarifies the behavioral meaning of parameters that the schema leaves implicit (e.g., exact=true bypasses fuzzy matching entirely, cutoff/limit ignored when exact=true, include_directive path format). This meaningfully surpasses the bar.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states 'Find model/subcircuit candidates across loaded (and optionally built-in) libraries' with specific verbs and resource. It clearly distinguishes itself from siblings like list_components and list_libraries by focusing on search with fuzzy matching, exact mode, and returning candidates with metadata like include_directive and ports. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly distinguishes between fuzzy and exact search, explains when to pass exact=true, and notes the tool folds in model_info behavior (`call find_model(name=X, exact=true, full=true)` for a single model's body). It also covers WSL-specific path behavior, implicitly guiding when a user might see unexpected paths. No explicit mention of alternatives, but the tool itself is clearly positioned as the search-plus-details hub.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining the meaning of 'interrupted' (simulation in flight when server stopped), the recovery path (check_job), and explicitly states it does not start or cancel anything. This aligns perfectly with the readOnly, idempotent, and non-destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (mentions 'jobs still running' and later explains 'interrupted'), but each section contributes necessary details about output structure and semantics. It is not overly verbose and remains focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: what the tool returns (list with fields), the meaning of a key status, and explicit non-actions. Combined with the input schema and annotations, it is fully sufficient for the agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'format' has a clear description explaining the difference between 'json' and 'text' outputs, adding meaningful semantics beyond the schema's enum. It also notes the default and optional nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find circuits and jobs the user recently worked with, using the verb 'find' and specifying the resource. It distinguishes from siblings by focusing on recent items and session-start context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage context ('Call on session start') and clarifies no inputs are required, though an optional format parameter exists. It does not explicitly mention alternatives, but the context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly supplements the annotations. It explains the snapshot mechanism, that the snapshot is dropped after reset, that add_component on a new schematic snapshots the empty file, that repeated calls with no edits return reverted=false, and that snapshots do not persist across server restarts. This goes well beyond destructiveHint and idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, every sentence earns its place: purpose, snapshot mechanics, edge cases, return behavior, and persistence limitations are all relevant. It is front-loaded with the core recovery purpose before diving into details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive recovery tool, the description is exceptionally complete. It covers the snapshot lifecycle, the empty-file edge case, the reverted=false return value, and the non-persistence caveat. The presence of an output schema means return-value details beyond reverted=false are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both 'path' and 'format'. The description adds context about how the server snapshots each .asc file, but it does not add new parameter-level meaning beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reverts an .asc schematic to its pre-session state, using a specific verb ('Revert'), a specific resource ('.asc schematic'), and a clear scope ('BEFORE the first edit this session'). It also positions itself as a 'recovery escape hatch,' distinguishing it from siblings like apply_schematic_ops or create_schematic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'when a sequence of edits went wrong.' It also gives a when-not scenario by noting it returns reverted=false when there are no in-session edits, and warns it is 'not a substitute for version control,' which clarifies limitations and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (readOnly, idempotent) by explaining the exact algorithm: first threshold crossings, signed delay semantics, per-signal threshold defaults, direction overrides, and the need to tighten window for multiple edges. No contradictions with annotations; this adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, with a clear front-loaded purpose. Each sentence contributes essential details—from usage scenarios to algorithm specifics to edge-case handling—without redundancy. It's well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and an output schema, the description covers all critical aspects: input requirements, return value semantics, threshold logic, direction handling, edge limitation, and AC rejection. It is complete enough for an agent to use correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%) but the description adds critical interpretive meaning beyond the schema: threshold_a/b override behavior, direction_a/b independence, and the importance of t_start/t_end when multiple edges exist. These clarifications are not explicit in the schema, enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: measuring propagation delay/skew between two signals, with specific examples like input-to-output delay, clock-to-Q, and input-skew. It distinguishes from siblings by focusing on two-signal timing analysis, which is distinct from broader metrics tools like edge_metrics or signal_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit scenarios for use (e.g., input-to-output, clock-to-Q) and a clear exclusion ('Rejects AC analysis'). However, it does not name alternative tools directly, but the context strongly implies when to use this tool vs others, so it's close to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotent/non-destructive signals, and the description adds meaningful behavior: config tracking via config_id, full cross-product semantics, per-value separate runs, and deterministic corner guarantees versus Monte Carlo. It does not cover failure modes or resource implications, but it exceeds the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides dense, useful nuance without filler. Every sentence earns its place, including concrete exclusions and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description states the key return value (config_id) and lifecycle. Combined with sibling tool run_sweep, the intended flow is clear. It covers use cases, alternatives, and anti-patterns thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents individual fields, but the description adds crucial semantic guidance: how to set up two-value [low, high] sets for corner analysis, one-part-at-a-time sweeps for sensitivity, and examples like L/W or .lib model swaps. This materially helps an agent construct the parameters array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a multi-parameter sweep for a netlist and returns a config_id for execution. It distinguishes itself from configure_montecarlo and bias-sweep workflows, making its purpose and scope immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: corner analysis and sensitivity analysis. It also names the alternative for statistical yield/spread (configure_montecarlo) and explicitly excludes bias sweeps, directing to run_simulation + export_waveform instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint:true and idempotentHint:true, and the description builds on this with rich behavioral detail: level auto-estimation from first/last 10% of window (not global min/max to avoid overshoot contamination), sub-sample-accurate linear interpolation for crossings, and rejection of AC analysis. It also discloses the default-first-edge behavior and its pitfall (power-up artifact). This is exactly the kind of context that annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but impeccably structured: purpose, returns, behavioral details, a CAPS-emphasized warning ('PICK THE WINDOW'), and a closing sentence on alternatives. Every paragraph earns its place. A minor deduction because it could arguably be tightened, but the all-caps callout and logical flow make it worth the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, an output schema, and 47 siblings, the description is remarkably complete. It covers purpose, return values (transition_time, slew_rate, levels, crossing times), key behavioral nuances, parameter selection guidance for edge cases, and explicit alternatives. The presence of an output schema means return-value details need not be repeated, and the description wisely focuses on decision-relevant information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions (e.g., t_start explains the startup-glitch recommendation), so baseline is 3. The description adds value beyond the schema by explaining the semantics linking low_pct/high_pct, the window parameters, and edge_index to real usage intent ('Use edge_index only when multiple edges in the window are intentional'). It doesn't fully cover all 14 parameters (e.g., job_id, format), but the schema already documents these well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb + resource pairing: 'quantify HOW FAST one transition happened: rise time, fall time, slew rate.' It clearly distinguishes itself from siblings by explicitly naming alternatives: 'For settling/overshoot after the edge, use pulse_response. For delay between two signals' edges, use timing_between.' This meets the highest bar for purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use when you need to quantify HOW FAST one transition happened'), provides a clear exclusion ('Rejects AC analysis'), gives detailed situational guidance ('If the transient has startup glitches or multiple edges, set t_start/t_end tightly around the edge you care about'), and names specific alternatives with their use cases (pulse_response for settling, timing_between for delay). This is model usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is clear. Description adds deep behavioral context: explains integration method (trapezoidal), warns about startup transients biasing RMS/mean, discloses omitted metrics (RMS/std for DC, mean for Noise) and justifications, and notes correction of common mistakes (np.mean(y)). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraph breaks per analysis type. Front-loaded with clear purpose. Some repetition (t_start/t_end rejected appears twice, 'use query_value' appears twice) and the list of related tools is long but valuable. Length is justified by complexity (4 analysis types) but could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (4 analysis modes, nuanced statistical methods), the description covers all salient points: analysis-specific calculations, omissions, windowing, alternatives, and related tools. Output schema exists, so return values need not be described. For a summary tool with diverse modes, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides extensive descriptions (100% coverage), and the description adds value by explaining semantics beyond schema: clarifies transient windowing, rejected parameters for AC/noise, and meaning of omitted metrics. As baseline 3 with high coverage, it reaches 4 for adding context like 'Strongly recommended when computing RMS' and 'passing no window averages the whole waveform including any startup transient'. Not 5 because schema already covers most parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it's a scalar summary of one signal in a .raw result and differentiates it from siblings by naming it for single-number-per-metric needs, not waveforms/trends. It explicitly lists related tools (edge_metrics, pulse_response, periodic_metrics, measurement_stats) for other use cases, providing strong sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use and when not: 'Use this when you need a single number per metric — not a waveform or a trend.' It also details analysis-type-specific behavior (Transient, DC, AC, Noise) and explains why restrictions apply (e.g., t_start/t_end rejected for AC). Mentions alternatives like query_value for specific frequencies and lists related tools for other metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description fully discloses transactional semantics: by default all-or-nothing, with stop_on_error=false for partial saves. It also warns about non-restorable side effects (cleanup_wires) and pattern matching for remove_directive, providing critical behavioral context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with the core purpose, then lists supported ops, then explains transaction and error handling. Although it's a bit long, every sentence carries necessary information for a complex tool, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (union types with per-op fields), the description is complete. It covers batching, transactional behavior, dry_run usage, error handling, and points to the schema for per-op details. It leaves no major gaps for understanding how to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed per-field descriptions. The description adds value by explaining the overall batch behavior and how errors/results are structured (per-op error fields, wire_count), but it does not significantly extend individual parameter explanations beyond what's already in the schema. Slightly above baseline due to the batch-context clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: applying many .asc edits in one transaction. It explicitly lists the supported ops (add_component, connect, set_component_value, etc.) and distinguishes itself from the individual sibling tools by batching multiple edits into a single round-trip, making it unmistakable what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: it 'cuts the typical 25+ tool calls... down to a single round-trip' for building circuits. It also explains the transaction behavior (stop_on_error, dry_run) and notes that some ops (ack-only mutations) have no standalone tool, giving clear when-to-use vs. alternatives context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the internal operation: splitting into buckets, reporting min/max, time-weighted mean/rms, pk_pk, crest_factor, and surfacing facts like decimation coverage and dropped non-finite samples. It also notes the default bucket count and cap. The annotations already indicate read-only/idempotent, and the description adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with three paragraphs: purpose and use cases, bucket mechanics, and output semantics/contrast with siblings. It is front-loaded with the primary purpose and every sentence adds value—no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description thoroughly covers purpose, usage, parameter interactions, output behavior, and contrasts with related tools. It also notes the output schema exists (though not shown) and explains the envelope concept and zoom workflow, making it self-sufficient for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has high coverage and detailed descriptions for each parameter. The description adds usage context by explaining how parameters interact (e.g., t_start/t_end to zoom, raw_file vs job_id mutually exclusive, bucket count cap), which goes beyond individual schema descriptions. However, it does not introduce new parameter-level details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a min/max-preserving stat-envelope of a signal over a time window, and distinguishes it from siblings like export_waveform (CSV) and plot_waveform (picture). It specifies the verb 'returns' and the resource 'waveform envelope' with concrete use cases (switching nodes, amplifier nodes, startup transients).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('when you need the shape') and when not to (for complex AC use bode_metrics, for scalar stats use signal_stats, for one point use query_value). It also explains the zoom workflow (narrow window and re-request).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations present (readOnlyHint false, openWorldHint true, destructiveHint false), the description goes well beyond the bar. It discloses the min/max-preserving downsample behavior above max_points ('spikes survive; surfaced as a fact'), the exact output path resolution logic (out_dir, sidecar next to circuit/raw), the MCP Apps in-chat widget vs terminal browser dual behavior, and that it produces a picture, not data. No contradiction with annotations — the file-writing disclosure is consistent with readOnlyHint: false and openWorldHint: true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the single most important fact (interactive, for humans, no data to model), then proceeds logically through chart selection, step handling, downsampling, output paths, widget/browser delivery, and ends with sibling differentiation. For a 12-parameter tool with run-type-dependent behavior, every sentence earns its place; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 12 parameters, run-type-dependent chart selection, step/Monte-Carlo overlay, dual output delivery modes — the description covers all major behavioral axes: rendering, output artifact, path resolution, fidelity/downsampling, and delivery channel. An output schema exists, so return-value explanation is not required. The description is complete for an agent to invoke and consume this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description adds genuine meaning beyond the schema by describing parameter interactions: how `step` selects one trace vs overlaying all steps, the behavior of `max_points` triggering downsampling, and the `out_dir` fallback chain (next to circuit for job_id, next to raw for raw_file). It does not walk through every parameter, but the schema already handles that, so the added relational semantics justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line is exemplary: 'Render an INTERACTIVE chart of one or more signals FOR A HUMAN to look at' — a specific verb (render) + resource (chart of signals) + explicit purpose. It immediately distinguishes from siblings by framing itself as 'the co-design complement to the numeric tools' and stating it 'returns NO data values.' This fully differentiates plot_waveform from the sibling measurement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit dedicated section, 'Sibling egress, don't confuse,' that names concrete alternatives with their exact roles: get_waveform (decimated), export_waveform (CSV), signal_stats/bode_metrics (scalars), culminating in 'This tool is for looking, not measuring.' Also explains when it auto-selects chart type by run type, and when to pass `step` for .step runs. This is textbook when-to-use vs. when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context: nearest data point without interpolation, additional AC return fields, and how run-level failures surface in warnings. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the primary purpose. Each paragraph adds distinct value, covering step selection, job runs, differentiation from sibling tool, and warning behavior—no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, multiple use cases), the description covers all relevant scenarios: AC/transient, step selection, MC jobs, and failure warnings. With a rich schema and output schema, this is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds valuable usage examples (e.g., step_axis='temp', step_value='27') and clarifies relationships between parameters (job_id + run_index vs. raw_file), which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a signal value at a specific time or frequency point, and distinguishes itself from export_waveform for multi-signal or waveform queries. The verb is specific ('look up'), and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: selecting steps by axis value, querying completed sweep/MC jobs via job_id, and when to use export_waveform instead. It also explains edge cases like solve failures, making usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe for reads. The description adds value beyond these by explaining the Q calculation formula, null behavior for boundary peaks, the effect of min_prominence_db (rejecting passband humps), and the sampling-density warning for high-Q resonances. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each sentence provides actionable information: the formula, the null case, the prominence default, the sampling warning, and alternative tools. No filler. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, high schema coverage, and presence of an output schema, the description covers critical edge cases (boundary peaks, sampling density, prominence filtering) and directs users to alternative tools. It fully compensates for any gaps in the structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 89%, so most parameters are documented. The description adds semantic insight: it explains min_prominence_db's role in rejecting gentle humps, min_separation_decades merging behavior, and the impact of log sweep density on Q accuracy. It also clarifies the default behavior of parameters like step. While not exhaustive, it meaningfully enriches the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Detect magnitude peaks in an AC sweep and estimate Q factor + -3 dB bandwidth for each') and the resource (AC sweep peaks). It explicitly distinguishes from siblings like bode_metrics and stability_metrics by naming them and their different purposes, and lists specific use cases (RLC resonators, crystal oscillators, peaking amps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context (for resonant modes) and alternative tool guidance: 'For overall filter characterization use bode_metrics(mode='filter'); for stability margins use stability_metrics.' Also explains when Q is not returned (boundary peaks) and advises widening sweep or adjusting sampling. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only/idempotent behavior, which the description matches. It goes beyond annotations by disclosing the coherent sampling default, exactness implications, auto-detection of fundamental, and all conditions affecting the result—excellent transparency for a signal-analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each adding critical information: purpose, methodology accuracy trade-offs, and pointers to alternatives. Front-loaded with the main action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with an output schema, the description covers purpose, usage conditions, algorithmic nuances, and alternative tools. The existence of an output schema handles return values, so no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds meaningful context for key parameters (e.g., fundamental auto-detection vs explicit, window choice affecting accuracy, t_start for skipping transient), enriching the schema without redundant repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it computes THD/THD+N from a transient signal via FFT, and explicitly distinguishes from LTspice's .four via simulation_summary. The verb and resource are specific, and the 'works on any .tran result' scope clarifies its niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (any .tran result without .four, any simulator) and directs to simulation_summary for .four results. Also provides guidance on coherent vs. hann window selection, which helps the agent choose the right approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by detailing behaviors: out-of-range frequencies clamp and warn, all_steps returns per-step errors, signal can be a ratio that divides complex waves, job_id echoes back params, and crossing merges within min_separation_decades. These are non-obvious behavioral details not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with mode-by-mode bullet points that mirror the schema organization. Despite the tool's complexity, every sentence contributes unique information—no redundancy or filler. The format is scannable and logically ordered, making it easy for an agent to extract the relevant mode's details quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's scope, including all four modes, parameter inheritance across modes, edge-case behaviors (clamping, merging, error handling), and integration with swept/MC jobs. It also references sibling tools for alternatives and explains output shapes (steps list, unwrapped phase). No significant context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the JSON schema already covers 96% of parameters with descriptions, the tool description adds crucial clarifications: which parameters are required for each mode, the units for crossing level, the relationship between raw_file and job_id (mutually exclusive), and the distinction between run_index and all_steps for swept loads. This enriches the parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as AC/Bode-plot analysis with four distinct modes, each precisely defined. It also distinguishes from sibling tools by explicitly recommending stability_metrics for loop-gain margins and resonance for peaks/Q, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use each mode (e.g., 'Use when you need a custom window or dB/octave' for slope) and when to prefer alternatives. It also explains the trade-offs between raw_file vs job_id, all_steps vs step, and how to combine them, providing actionable usage context beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP_LTSpice MCP server](https://glama.ai/mcp/servers/ossenna-hq/MCP_LTSpice/badges/card.svg)](https://glama.ai/mcp/servers/ossenna-hq/MCP_LTSpice)

Score Badge

Copy to your README.md:

[![MCP_LTSpice MCP server](https://glama.ai/mcp/servers/ossenna-hq/MCP_LTSpice/badges/score.svg)](https://glama.ai/mcp/servers/ossenna-hq/MCP_LTSpice)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ossenna-hq/MCP_LTSpice'

If you have feedback or need assistance with the MCP directory API, please join our Discord server