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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the annotations by detailing that it kills the simulator process(es) and marks the job as cancelled. This provides useful behavioral insight, though it does not elaborate on potential side effects such as resource cleanup or data loss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences that directly state the operation and its effect without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter schema and no output specification, the description fully covers the tool's purpose and effect. It is complete for the agent to understand what the tool does and what input is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, job_id, is fully described as the identifier of the running simulation to cancel. This matches the schema and provides all necessary meaning for correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool cancels a running simulation job, and it distinguishes between single runs and batch jobs. It explicitly mentions killing simulator processes and marking the job as cancelled, which is specific and unique among the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when a running simulation needs to be stopped) but does not explicitly discuss alternatives or when not to use it. However, the purpose is clear enough that an agent would understand the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is well covered. The description adds that it reads from an .asc file and returns specific fields, but it does not disclose error handling or other behavioral details beyond what annotations imply. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with the verb 'Get' front-loaded. All words are meaningful and it avoids redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high schema coverage and presence of an output schema, the description is sufficient for this read-only tool. It lists the key data returned and the input context, though it could optionally mention behavior when components are missing, but this is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter (path, reference, format) is already described. The description does not add additional meaning or constraints to the parameters beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action (get), the resource (placed component), and the data retrieved (pin positions, bounding box, value, attributes) from an .asc schematic. It is distinct from siblings like symbol_info or list_components, which focus on different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context (placed component, .asc schematic) that implies when to use it, but it does not explicitly mention alternatives or when not to use it. No user guidance is provided regarding comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate modifying nature (readOnlyHint=false), but description doesn't mention potential side effects such as overwriting existing connections or changing netlist. Lacks explicit warning about consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, no redundant information. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown), the description adequately covers the function, parameters, and behavior. It explains the conditions for waypoints sufficiently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are detailed with examples for pin references and waypoints. The description reinforces the meaning of waypoints and when they are needed, adding clarity beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action 'Connect two component pins with wire(s)' and notes automatic position resolution. It distinguishes from other tools by focusing on wiring, though no explicit comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides details on when to use waypoints and when they can be omitted, guiding the user on the proper invocation. No explicit alternative guidance, but sufficient context for a schematic editing tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the safety profile is covered. The description adds meaningful behavioral detail beyond that by specifying the categories of changes detected (components, attributes, .PARAM/.MEAS/.MODEL directives), giving the agent a concrete sense of the tool's output scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose in sentence one and usage context in sentence two. Every word contributes value; no fluff or repetition of the schema. This is a model of efficient tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only diff tool with no output schema, the description provides the key output categories and a usage trigger, which gives the agent enough context to invoke it correctly. It does not describe exact return formatting, but the format parameter and listed report categories cover the essentials, leaving only minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents path_a, path_b, and format. The description adds little parameter-specific semantic beyond implying two file paths; it focuses on the diff behavior rather than explaining the parameters, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the specific verb 'diff' and names the resource ('two circuit files'), then enumerates exactly what it reports: added/removed components, changed values/attributes, and added/removed directives. This clearly distinguishes it from sibling tools like read_circuit or validate_netlist, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence explicitly tells the agent when to use this tool: after set_component_value, set_component_attribute, or edit_directive, to confirm a change landed. This is clear context, though it stops short of naming when-not-to-use or alternative diff tools, so it earns a 4 rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered by structured data. The description adds the 'using LTspice' context but does not explain what may be destroyed (e.g., overwriting an existing .net file) or what side effects occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, immediately states the core conversion action, and contains no filler or redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with annotations covering side-effect safety, the description is mostly complete. It would benefit from mentioning the output destination or that LTspice must be available, but it gives sufficient context for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% because the single 'path' parameter is fully documented as 'Path to .asc schematic to export.' The description adds no additional meaning beyond matching that parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resources: 'Export an .asc schematic to a SPICE netlist (.net) using LTspice.' This clearly identifies the tool's function and distinguishes it from siblings like validate_netlist or export_waveform.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as create_netlist or validate_netlist. It implicitly assumes the agent will know this is the export path, but gives no exclusions, prerequisites, or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint and idempotentHint, indicating safe operations. The description adds that limit is capped at 50 and pagination is possible, which is behavioral context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, efficiently conveying the primary purpose and two optional behaviors. It is concise with no fluff, though it could be more explicit about the two modes of operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, return formats are covered. The description is sufficient for a read-only listing tool with 6 parameters, but could better explain the difference between 'reference' mode vs 'prefix' mode and when to use each.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well documented. The description adds little: it mentions 'type prefix' and 'single component value by reference' which clarifies the 'prefix' and 'reference' fields slightly, but mostly redundant with schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists components in a circuit file, with optional filtering by prefix or returning a single component by reference. It distinguishes from siblings like component_info (which presumably provides details on a known component) and set_component_value (mutation), but doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing or reading components, but doesn't explicitly state when to use this vs component_info or other query tools. It mentions optional filtering and single lookup, which hints at usage scenarios, but lacks clear guidance on when to prefer this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, so the description carries full weight. It only says 'load into the session' but does not disclose whether loading replaces existing libraries, is idempotent, has side effects, or what happens on errors. This is minimal disclosure for a state-modifying operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, directly front-loaded, with no redundant words. Every element adds meaning, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, no output schema), and the description covers the core action but omits behavior like replacement policy, existence checks, or interaction with other tools (e.g., whether loaded libraries are automatically used by simulations). Given the minimal annotations, it is adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter described as 'Path to library file or directory'. The tool description adds file extensions (.lib, .mod) and clarifies that a directory is accepted, providing marginal value beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Load' clearly specifies the action (loading a SPICE library file or directory), and it explicitly names the resource types (.lib, .mod). It distinguishes from siblings like unload_library and list_libraries by stating the purpose of making libraries available to the session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('into the session') but does not explicitly state when to use this tool versus alternatives like find_model or unload_library, nor does it mention any exclusions or prerequisites. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the annotations by explaining the meaning of 'interrupted' (simulation in flight when server stopped), the recovery path (check_job), and explicitly states it does not start or cancel anything. This aligns perfectly with the readOnly, idempotent, and non-destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat repetitive (mentions 'jobs still running' and later explains 'interrupted'), but each section contributes necessary details about output structure and semantics. It is not overly verbose and remains focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all essential aspects: what the tool returns (list with fields), the meaning of a key status, and explicit non-actions. Combined with the input schema and annotations, it is fully sufficient for the agent to understand and use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'format' has a clear description explaining the difference between 'json' and 'text' outputs, adding meaningful semantics beyond the schema's enum. It also notes the default and optional nature.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to find circuits and jobs the user recently worked with, using the verb 'find' and specifying the resource. It distinguishes from siblings by focusing on recent items and session-start context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit usage context ('Call on session start') and clarifies no inputs are required, though an optional format parameter exists. It does not explicitly mention alternatives, but the context is clear enough for typical use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description richly supplements the annotations. It explains the snapshot mechanism, that the snapshot is dropped after reset, that add_component on a new schematic snapshots the empty file, that repeated calls with no edits return reverted=false, and that snapshots do not persist across server restarts. This goes well beyond destructiveHint and idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is long, every sentence earns its place: purpose, snapshot mechanics, edge cases, return behavior, and persistence limitations are all relevant. It is front-loaded with the core recovery purpose before diving into details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive recovery tool, the description is exceptionally complete. It covers the snapshot lifecycle, the empty-file edge case, the reverted=false return value, and the non-persistence caveat. The presence of an output schema means return-value details beyond reverted=false are not required in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents both 'path' and 'format'. The description adds context about how the server snapshots each .asc file, but it does not add new parameter-level meaning beyond what the schema already states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reverts an .asc schematic to its pre-session state, using a specific verb ('Revert'), a specific resource ('.asc schematic'), and a clear scope ('BEFORE the first edit this session'). It also positions itself as a 'recovery escape hatch,' distinguishing it from siblings like apply_schematic_ops or create_schematic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: 'when a sequence of edits went wrong.' It also gives a when-not scenario by noting it returns reverted=false when there are no in-session edits, and warns it is 'not a substitute for version control,' which clarifies limitations and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, but the description explicitly states 'asynchronously and return a job_id', which discloses non-blocking behavior and output. This adds information beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy, includes all essential elements: execute, previously configured, asynchronous, job_id. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Mentions the output (job_id) despite no output schema, covering the immediate result. Does not detail job polling but that is not required for the action itself. Adequate for context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already fully describes both parameters (config_id from configure functions, max_parallel with default). The description does not add further parameter-specific details; baseline applies due to high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (execute) and resource (Monte Carlo analysis), distinguishing it from siblings like run_sweep or configure_montecarlo. Mentions async and job_id, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Indicates that the analysis must be 'previously configured', implying a prerequisite step (configure_montecarlo). While it doesn't explicitly contrast with alternatives, the name and context make its intended use clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.