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

Annotations indicate a write operation but no destructive behavior. Description adds no details about error conditions (e.g., duplicate reference), side effects, or need for prior schematic existence.

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 clear sentence, front-loaded. Efficient but could benefit from a brief note on behavior or response format.

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 9 parameters and output schema present, description covers basic purpose but lacks constraints, error handling, and output description. Adequate but not 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 good parameter descriptions. The description adds no extra meaning beyond the schema, so 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 action (add), the resource (component to .asc schematic), and the positioning (at specified grid position). It distinguishes from siblings like remove_component and move_component.

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

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

No guidance on when to use this vs alternatives (e.g., set_component_value, create_schematic). No prerequisites or context for selection.

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 adds context that the label is placed 'at a wire junction' beyond annotations (idempotentHint, non-destructive). However, it lacks details on side effects, error conditions, or behavior of removing a label. Annotations already indicate idempotency and non-destructiveness.

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 efficiently states purpose and resource. Could include brief usage hint but remains front-loaded and to the point.

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?

Describes core action adequately but misses guidance on coordinate vs. pin usage, action parameter behavior, and no output schema. Sufficient for a simple tool but gaps remain.

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 67%, but description does not elaborate on parameters beyond schema. For example, 'path' parameter lacks schema description and is not mentioned in tool description. The description ties 'net' parameter to 'ground flag' but adds no new semantic meaning.

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

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

Description clearly states verb 'Add', resource 'net label or ground flag', and context 'to an .asc schematic at a wire junction'. It distinguishes from sibling tools like 'connect' or 'trace_net' by specifying the operation on net labels.

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

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

No guidance on when to use this tool versus alternatives like 'connect' or 'trace_net'. Does not mention when to use 'add' vs. 'remove' action, nor any prerequisites or constraints.

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?

Discloses transactional behavior: loads once, applies ops in memory, saves once. Explains error handling (abort on first error vs. continue) and that results include per-op errors. Annotations already indicate mutation, so description adds context 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?

Description is well-structured with an opening statement, a list of supported ops, and error handling details. Every sentence contributes useful information, though it could be slightly more 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?

Given the complexity of batching many ops, the description covers the key behavioral aspects. Output schema likely handles return values, so the omission is acceptable. Could mention prerequisites like file existence.

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%, but description adds value by summarizing the ops array structure and the stop_on_error behavior. It contextualizes the parameter semantics beyond the schema's per-op descriptions, such as explaining the transaction concept.

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: 'Apply many .asc edits in one transaction.' It explicitly lists all supported ops and contrasts with the alternative of multiple individual calls, effectively distinguishing it from siblings like add_component and connect.

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: 'Cuts the typical 25+ tool calls to build a real circuit... down to a single round-trip.' Also explains the stop_on_error flag and when to use false for partial progress, offering clear decision criteria.

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=true, destructive=false, idempotent=true. The description adds valuable behavioral details: mode switching based on signal, pagination via offset/limit, and the effect of the 'at' parameter on data slicing. 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 two concise sentences, front-loaded with main purpose. Every word is informative; 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 8 parameters (1 required), existing output schema, and the tool's complexity, the description covers essential behavior: two modes, pagination, and parameter interactions. It is sufficiently complete for an agent to select and invoke 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%, but the description adds crucial context beyond the schema. For example, it explains how the 'at' parameter changes aggregation behavior and warns about waveform peak conflation without it. This extra guidance significantly aids parameter 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 the tool queries a batch simulation job (sweep or Monte Carlo). It specifies two modes: without signal returns job status/progress, with signal returns aggregate or per-run data. This specificity distinguishes it from sibling tools like check_job and run_sweep.

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

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

The description explains when to use the signal parameter vs not, but does not mention when not to use this tool or explicitly list alternatives (e.g., check_job for job status). Usage context is implied but lacks exclusions.

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, destructiveHint, idempotentHint. Description adds mode-specific behavior: response shape depends on mode, out-of-range clamping with warnings for point mode, and all_steps returns steps list with error 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?

Well-structured with mode descriptions in a clear list, front-loaded purpose. Slightly long but every sentence adds value; no waste.

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 23 parameters and output schema, the description covers all key aspects: modes, parameter combinations, error handling, use cases, and alternatives. Complete for a complex 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?

Schema coverage is 96%, but the description goes beyond by detailing each mode's required arguments (e.g., ref_db for filter, f_low/f_high for slope), explaining all_steps behavior, and clarifying job_id/run_index use.

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

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

The description clearly states it performs AC/Bode-plot analysis selected by mode, and explicitly distinguishes from siblings stability_metrics and resonance. Each mode is defined with specific output details.

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 each mode, when to use all_steps, when to use job_id vs raw_file, and directs to sibling tools for other analyses.

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 and idempotent behavior. The description adds important context: it kills simulator processes and marks the job as cancelled, which goes beyond the annotations. It does not mention error handling or side effects, but the core behavior is well communicated.

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

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

The description is a single sentence with a parenthetical clarification. It is front-loaded with the action and resource, and every word adds value. No wasted or redundant content.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately covers what the tool does and its effect. It is missing information about the return status or behavior on already-cancelled jobs, but these are minor for such a straightforward action.

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 parameter 'job_id' has a schema description ('Job ID of the running simulation to cancel') that is clear and covers 100% of the parameter. The tool description does not add additional information about the parameter, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('cancel') and clearly identifies the resource ('running simulation job'). It distinguishes between single runs and batch types (sweep/Monte-Carlo), and explains the effect ('kills processes, marks cancelled'). No sibling tool has a similar purpose.

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 (to cancel a running simulation). It does not mention when not to use it (e.g., if job already completed) or alternatives, but the purpose is clear enough for an AI agent to infer typical usage.

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, which align with the description. The description adds value by explaining the two operational modes and that 'completion results' are returned with job_id, but does not significantly exceed what annotations convey about safety and behavior.

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

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

The description is two sentences, front-loaded with the main purpose. Every sentence is essential and no extraneous details are included. It is efficient 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?

Given the tool's simplicity (read-only query with three optional parameters and an output schema present), the description is complete. It covers both modes, the filter, and implies the output includes status/results. The output schema handles return value details, so no further elaboration is needed.

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 each parameter. The description adds contextual meaning (e.g., job_id is returned by run_simulation, status filter options), but this is largely redundant with the schema descriptions. It does not provide new semantic information beyond what the schema already offers.

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 two distinct functions: check status by job_id or list all jobs. It uses specific verbs 'Check' and 'list', and the resource 'simulation job' is clear. This distinguishes it from sibling tools like cancel_job or run_simulation.

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 guidance on when to use each mode (with/without job_id) and explains the optional status filter. It doesn't explicitly state when not to use the tool, but the context of a read-only query is evident from the annotations and description.

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 readOnlyHint=true and destructiveHint=false. The description adds value by listing specific output fields (pin positions, bounding box, value, attributes) and specifying the input file type (.asc schematic), which is beyond the annotations.

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

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

The description is a single, well-structured sentence that is front-loaded with the key action and resource. No unnecessary words.

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

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

Given the tool's simplicity (read-only, single function), the schema covers all parameters, annotations are comprehensive, and an output schema exists. The description is complete enough for an agent to understand the tool's purpose and behavior.

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 baseline is 3. The description does not add further meaning to the parameters (path, reference, format) beyond what the schema already provides. It lists output fields but does not explain parameter 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 the tool retrieves pin positions, bounding box, value, and attributes from a .asc schematic for a specific component. It uses a specific verb 'Get' and resource, distinguishing it from siblings like 'symbol_info' or '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 when detailed component info is needed, but does not explicitly state when to use vs alternatives like 'symbol_info' or 'list_components'. No exclusions or when-not-to-use guidance is provided.

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

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

Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds it returns a config_id but doesn't elaborate on side effects, persistence, or prerequisites.

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

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

The single-sentence description is concise and front-loaded with the verb and resource, but could be slightly improved by noting the sibling relationship.

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 (7 parameters, nested objects, no output schema), the description is too brief. It lacks an overview of the tolerance types and workflow, relying entirely on parameter descriptions.

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 thorough parameter descriptions, so the description doesn't need to add detail. It provides no additional meaning beyond the schema.

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

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

The description clearly states the verb 'configure' and the resource 'Monte Carlo analysis', and distinguishes from the sibling 'run_montecarlo' by noting it returns a config_id for later execution.

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

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

The description implies that this tool should be used before 'run_montecarlo', but lacks explicit guidance on when to use vs. alternatives (e.g., configure_sweep) or when not to use it.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds the key behavioral detail that the tool returns a config_id for later execution, which is not in 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, clear sentence that front-loads the purpose without any wasted words 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?

The description adequately explains the tool's purpose and output given its two required parameters and no output schema. It could mention that the config_id is used with run_sweep, but the sibling tool list provides that context.

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

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

Schema description coverage is 100%, so the input schema already fully documents both parameters. The description adds no additional 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 configures a multi-parameter sweep for a netlist and returns a config_id for later execution. It uses a specific verb and resource, and distinguishes itself from execution tools like run_sweep and configure_montecarlo.

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 this tool is for configuration, not execution, by mentioning 'return a config_id for later execution.' However, it does not explicitly state when to use this tool versus run_sweep or configure_montecarlo, leaving some 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 provide no behavioral hints (e.g., destructiveHint=false, idempotentHint=false), and the description only adds 'Resolves pin positions automatically'. It does not disclose potential side effects (e.g., overwriting existing wires) or permissions, leaving gaps for a mutation tool.

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

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

Three concise sentences, each serving a purpose: main action, automatic resolution, and waypoint usage. No unnecessary words.

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

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

Given the presence of an output schema, the description adequately covers the tool's operation without needing to detail return values. It could mention prerequisites (e.g., schematic exists) or error cases, but is still reasonably 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 100% with detailed parameter descriptions. The description adds value by explaining the overall purpose and the role of waypoints, going slightly beyond the schema alone.

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 ('Connect two component pins with wire(s)') and a key feature ('Resolves pin positions automatically'), making the purpose unambiguous and distinct from sibling tools like 'add_component' or 'trace_net'.

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

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

The description explains when to use waypoints ('For a straight horizontal or vertical connection, waypoints can be omitted') and their role, providing clear context for parameter usage, though it does not explicitly compare to 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?

Annotations already indicate destructive=true; description adds key behavior: automatic appending of .END if missing. 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?

Short and to the point with two sentences, no wasted words. Could front-load more detail about overwrite 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?

Adequate for a simple tool but lacks mention of error handling, return value, or how it relates to sibling tools like validate_netlist.

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%, description does not add significant meaning beyond the schema for parameters like name, content, overwrite. Baseline score 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?

Clearly states it creates a new SPICE netlist file from content string, and adds specific behavior (auto-appending .END). Distinguishes from sibling tools like export_netlist and schematic_from_netlist.

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

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

Implies usage for creating netlist files, but does not explicitly clarify when to use this vs other creation methods or alternatives among 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 indicate destructiveHint: true and readOnlyHint: false, so the description correctly implies a mutation. It adds context about creating an empty file and the overwrite parameter's default behavior. 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 two sentences: the first defines the tool's core purpose, the second provides usage guidance. No wasted words, and the key information is front-loaded.

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 creation tool with 4 parameters, no output schema, and present annotations, the description sufficiently covers purpose, usage context, and basic behavior. Minor missing details like file path handling are acceptable for this complexity.

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

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

Schema coverage is 100% with clear default descriptions. The description adds value by noting that default width/height match LTspice defaults, which aids parameter understanding.

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 'Create an empty .asc schematic' with a specific verb (create) and resource (.asc schematic). It also mentions the tool's role as a starting point for incremental editing via sibling tools, distinguishing it from creation tools like create_netlist.

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 tip explicitly advises preferring 'create_netlist' + .cir for design iteration and using this tool only when 'a visual schematic is the deliverable'. This provides clear when-to-use guidance and contrasts with an alternative.

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 read-only and idempotent behavior. The description adds specific behavioral detail about what the diff reports (components, attributes, directives), going beyond annotations to clarify the tool's scope and output.

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 purpose, no redundant information. Every sentence adds value: the first states what it does, the second when to use it.

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 a diff, and the description covers the main diff categories (components, attributes, directives). No output schema exists, but the description adequately explains what the output contains. Could optionally mention format choices, but the schema covers that.

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 all parameters are already described. The description does not add new parameter-level detail, but this is acceptable as the schema already provides sufficient description (path_a, path_b, format). 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 clearly states it performs a 'structural diff between two circuit files' and lists specific reported changes (added/removed components, changed attributes, directives). This verb+resource combination is distinct from sibling tools, none of which offer diff functionality.

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 recommends use after specific mutation tools (set_component_value, set_component_attribute, edit_directive) to verify changes landed. This provides clear context and intended use case, effectively guiding the agent.

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 and idempotentHint=true, so the agent knows it's safe. The description adds valuable behavioral details: level estimation from first/last 10% (not global min/max), sub-sample accuracy via linear interpolation, rejection of AC analysis, and potential power-up glitch issue. 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: starts with purpose, lists returns, explains behavioral details, and ends with usage tips and sibling references. Every sentence adds value, though it is somewhat lengthy. Could be slightly more concise but overall effective.

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, 2 required, output schema exists), the description is highly complete. It explains key parameters, limitations, and how to use effectively. The output schema covers return values, so no need to repeat them.

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 baseline is 3. The description adds meaningful context beyond the schema: explains auto-detection of levels, when to override with low_level/high_level, and provides examples (e.g., signal 'V(out)'). This extra guidance pushes the score to 4.

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

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

The description clearly states the tool's purpose: 'quantify HOW FAST one transition happened: rise time, fall time, slew rate.' It also explicitly distinguishes from sibling tools pulse_response and timing_between.

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 ('Use when you need to quantify HOW FAST one transition happened'), when-not-to-use (rejects AC analysis), and alternatives (pulse_response for settling/overshoot, timing_between for delay). Also gives specific guidance on window selection and edge_index.

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 the tool modifies files (add/remove) and specifies constraints like .asc-only for comments and remove behavior. However, with annotations providing no safety hints (all false), the description could add more about idempotency or side effects.

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

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

The description is concise at three sentences, front-loaded with the main action, and contains no unnecessary words 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 has 7 parameters (3 required) and no output schema, the description covers the essential high-level behavior and constraints. The schema fills in parameter details, making the overall definition adequately complete for an LLM agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds little beyond the schema: it reiterates default kind and remove matching behavior, but does not provide new semantics for parameters not already covered in 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 adds or removes a SPICE directive or .asc free-text comment, with specific verbs and resources, distinguishing it from sibling tools that deal with components or other schematic elements.

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 useful context on when to use the tool, such as file type restrictions (.cir/.net vs .asc) and behavior differences for 'remove' action (matches both directives and comments). However, it does not explicitly compare with alternatives or state when not to use it.

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

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

Annotations indicate destructiveHint=true and idempotentHint=true. The description adds that it uses LTspice, but does not explain what 'destructive' entails (e.g., file creation). Behavioral context is minimal beyond the schema and annotations.

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

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

The description is a single concise sentence that conveys the essential information without any fluff. Every word is purposeful.

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

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

For a simple tool with one parameter and no output schema, the description is largely complete: it explains the transformation (from .asc to .net). It could mention the output format more explicitly, but it is adequate.

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 'path' has a clear description in the input schema ('Path to .asc schematic to export'), and the tool description repeats this without adding new meaning. With 100% schema coverage, the description adds no additional semantics.

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 exports an .asc schematic to a SPICE netlist (.net) using LTspice. It uses a specific verb ('Export') and resource ('.asc schematic') and distinguishes from siblings like create_netlist and schematic_from_netlist.

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 does not explicitly state when to use this tool versus alternatives like create_netlist or validate_netlist. The purpose is clear, but no guidance on when not to use it or context for choosing it over 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 indicate read-only and idempotent behavior, but the description adds critical behavioral details: fuzzy matching behavior, return structure (ranked candidates with similarity score and .include directive), port and parameter inclusion, and a performance warning for include_builtin. 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 concise (5 sentences) and front-loaded with the primary purpose. Every sentence adds value, and the structure flows logically from purpose to behavior to parameter details. 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?

Given the output schema exists, the description still covers return values adequately (candidates, similarity score, .include directive, ports, params, optional full content). All 7 parameters are fully documented in schema, and the description provides necessary behavioral context for effective use.

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

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

Schema description coverage is 100%, but the description adds significant meaning beyond the schema: it explains how fuzzy matching works, that exact=true bypasses fuzzy scoring, that limit/cutoff are ignored when exact=true, and that full=true merges the old model_info tool. This reduces cognitive load for the agent.

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

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

The description uses a specific verb ('Find') and clearly identifies the resource ('model/subcircuit candidates across loaded and optionally built-in libraries'). It distinguishes between fuzzy and exact modes, making the tool's primary function 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 states when to use fuzzy matching (default) vs exact matching (pass exact=true), and explains parameters like limit and cutoff are ignored when exact=true. It does not directly contrast with sibling tools, but the usage context is clearly implied within the domain of component search.

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 and idempotentHint=true, indicating a safe read operation. The description adds no behavioral context beyond what the schema and annotations provide. It does not mention pagination behavior, performance considerations, or error cases.

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

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

The description is a single sentence of 18 words, front-loaded with the core functionality. Every word earns its place; there is no repetition 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?

With 6 parameters, an output schema, and several sibling tools, the description is concise but lacks depth. It does not explain the two modes (list vs. single lookup) in detail, nor does it provide guidance on response structure or pagination. The presence of an output schema partially compensates, but the description could be more complete for agent decision-making.

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 context for 'prefix' (filter by type) and 'reference' (single component lookup), which aligns with the schema descriptions. It does not add meaning for 'path', 'offset', 'limit', or 'format' 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 it lists components in a circuit file with optional filtering by prefix or single component lookup. The verb 'List' and resource 'components' are specific. However, it does not explicitly distinguish itself from sibling tools like 'component_info' or 'query_value', but the purpose is still clear.

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 guidance on when to use filtering versus single lookup, but it does not mention when not to use this tool or provide alternatives. For example, it does not say to use 'component_info' for detailed component information or when to prefer 'list_components' over other listing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description adds value by explaining the behavioral context of the detail flag (exposing .SUBCKT and .MODEL names). This helps the agent understand the tool's non-destructive, read-only nature beyond the 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 two sentences long, front-loaded with the core purpose, and every sentence adds value. No filler or redundant information.

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

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

Given the presence of an output schema (return values documented elsewhere) and comprehensive annotations, the description covers the essential behavior of listing libraries and the detail feature. It does not discuss pagination or the path filter, but those are already present in the schema, so the description is complete for its role.

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

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

With 100% schema coverage, the baseline is 3. The description adds meaningful context for the detail parameter by providing a concrete use case example (foundry .bjt/.mod files with hundreds of .MODEL cards), which clarifies why one might use it and what benefit it 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 'List loaded libraries' with a specific verb and resource, and highlights the optional detail flag to show .SUBCKT and .MODEL names. It distinguishes itself from sibling tools like load_library and unload_library by focusing on listing rather than modification.

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 using this tool to discover loaded libraries and internal models, but does not explicitly state when to use it versus alternatives (e.g., find_model). It lacks explicit when-not or exclusion guidelines, so it meets only a minimal standard.

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 minimal info; description adds loading into session but omits side effects like overwriting or cumulative behavior.

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

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

Single sentence, no wasted words, clearly front-loaded with verb and resource.

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

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

Adequate for a simple 1-param tool; could mention error handling for missing paths or duplicate loads.

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 path with description; baseline 3. Description adds file extensions but no further parameter 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?

Clearly states the action (Load), resource (SPICE library file or directory), and context (into the session). Differentiates from siblings like list_libraries and unload_library.

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

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

No explicit guidance on when to use vs alternatives. Lacks prerequisites or exclusions; only describes behavior.

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 behavioral details beyond annotations: what outputs are returned (min, max, mean, etc.), how axis choice works, and edge cases (single run with n=1). 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 front-loaded with the main purpose and is well-structured. However, it is somewhat verbose; minor tightening could improve conciseness.

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

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

Given the rich input schema, annotations, and output schema, the description fully covers all behavioral nuances, edge cases, and alternatives. No gaps remain.

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 baseline is 3. The description adds significant extra meaning: explains the difference between log_file and job_id, clarifies the measurement parameter, and describes histogram_bins' effect.

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 'aggregate' and resource '.MEAS scalar results', and distinguishes from sibling tools like simulation_summary by noting when to use each. Example questions ('worst-case rise time?') provide concrete 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?

Explicitly states when to use (aggregating across sweep or Monte Carlo) and when not to (use simulation_summary for plain single runs). Also explains axis choice and job type handling.

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 sparse (readOnlyHint=false, destructiveHint=false), leaving the description to carry behavioral disclosure. The description adds key traits: it warns on overlap and lists orphaned wire endpoints, providing insight into the tool's side effects beyond simple mutation. There is 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 two sentences long with no wasted words. It front-loads the core action and immediately adds valuable behavioral details, making every sentence earn its place.

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

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

Given the lack of output schema, the description implies the return value (warnings, orphaned wire list) and covers the operation fully for a 5-parameter tool with 100% schema coverage. It provides all necessary context for an agent to invoke the 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 each parameter already has a description. The tool description adds overall context but does not provide per-parameter meaning beyond what the schema states. The baseline is 3 for high coverage, and the description does not elevate it further.

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 specifies the action (move and/or rotate), the target (component in .asc schematic), and distinguishes from siblings like add_component or remove_component by detailing its unique side effects (overlap warnings, orphaned wires). It is a specific verb+resource pairing with no ambiguity.

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 makes clear when to use the tool (to reposition a component) and provides context about warnings and orphaned wires, but it does not explicitly state when not to use it or suggest alternatives. The need for the tool is implied by the action, but exclusive guidance is absent.

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 the safety profile is clear. The description adds the scope of data returned, but no further behavioral traits (e.g., error handling beyond the schema note on 'step', performance, or output size). With strong annotations, the description does not need extensive behavioral disclosure, but it does not add significant value beyond them.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's core function. No wasted words, and it is front-loaded with the action and result. It is appropriately sized for its purpose.

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

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

The description is minimal but sufficient given the existence of a thorough input schema and annotations. It covers the essence of what the tool does. However, it could mention the requirement for a .raw file (though schema already marks 'raw_file' as required) or clarify the context of 'operating point' (e.g., from .OP simulation). The presence of an output schema helps, but a small addition would make it more 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 description coverage is 100%, so the schema already documents the three parameters thoroughly ('raw_file', 'step' with default and error behavior, 'format' with enum options). The tool description does not add any parameter-specific information beyond what the schema provides. 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 uses a specific verb 'Read' and resource 'DC operating point data showing all node voltages and branch currents', clearly indicating what the tool returns. It is distinct from sibling read tools like 'component_info' or 'simulation_summary' by specifying the scope of the data. However, it does not explicitly differentiate from similar tools, and the title is null, so a slight deduction for not leveraging the title.

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. It does not mention prerequisites, typical use cases, or situations where another tool (e.g., 'simulation_summary' for summary metrics) might be more appropriate. The agent must rely on context and sibling names to infer usage.

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 idempotency and non-destructiveness, but the description adds no behavioral context beyond 'read or write'. It fails to disclose side effects like whether writing creates new directives or requires existing ones, leaving the agent unaware of important constraints.

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

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

The description is a single concise sentence that efficiently communicates the core functionality with no wasted words. It is front-loaded with the verb and resource.

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

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

Given that an output schema exists and schema coverage is complete, the description is adequate but lacks important behavioral distinctions. It does not explain the conditional behavior of reading vs writing based on parameter presence, which is relevant for a dual-purpose 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?

With 100% schema coverage, the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; the interaction between 'name' and 'value' (e.g., reading vs writing) is not clarified beyond the schema definitions.

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 reads or writes .PARAM directive values in circuit files, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'edit_directive' which might handle similar operations on other directives.

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. It does not mention scenarios such as creating new parameters vs updating existing ones, or how it differs from editing directives via 'edit_directive'.

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 readOnlyHint, destructiveHint, idempotentHint. The description adds crucial behavioral context: threshold crossing algorithm, auto midpoint behavior, rejection of AC analysis, and conditions for null duty_cycle_pct. 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?

Well-structured with clear sections. Each sentence adds value, though slightly verbose. No redundancy with schema or annotations.

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 8 parameters, output schema exists, and complexity of periodic measurements, the description covers purpose, usage, edge cases, and behavioral details comprehensively. No gaps identified.

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 practical meaning beyond schema: e.g., threshold auto = midpoint, min_periods guards against 1-edge windows, t_start/t_end intended to skip startup transient. Adds moderate value.

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

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

The description clearly states the tool is for oscillating transient signals to extract period, frequency, duty cycle, pulse widths, and jitter. It explicitly differentiates from the sibling tool edge_metrics ('For a single edge... 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 when-to-use (periodic signals) and when-not (single edge), along with practical tips like skipping startup transient via t_start/t_end, setting explicit threshold for DC drift, and using min_periods to avoid insufficient data.

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 essential behaviors: expects a one-step transition in a transient .raw file, auto-detects initial/final values but allows explicit override if contaminated by ringing, defines metrics (overshoot/undershoot concepts), and notes that settling_time may be null if never settled. This adds substantial value beyond the readOnlyHint and idempotentHint 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 concise: it opens with the purpose, then covers inputs, returns, definitions, and special notes. Every sentence adds value, and it is not verbose. It effectively front-loads the key information.

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

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

Given the tool's complexity (9 parameters, 2 required, output schema present), the description is comprehensive. It covers input requirements, output fields, definitions of metrics, edge cases (auto-detection contamination, AC rejection), and alternatives. With an output schema existing, the description does not need to detail return structure but does so adequately.

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 descriptions are already detailed, but the tool description adds meaning by explaining the auto-detection logic (first/last 10% of window), the definition of overshoot and undershoot, and the interpretation of overshoot_pct=0 as measured overdamped. It also clarifies the role of settling_tolerance_pct with common values.

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 provides step-response quality metrics (overshoot, undershoot, settling time, peak value and peak time). It distinguishes itself from the sibling tool edge_metrics by noting that tool is for rise/fall time without overshoot.

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 (need step-response metrics) and when not (for rise/fall time without overshoot, use edge_metrics). It also mentions that it rejects AC analysis, providing clear usage boundaries.

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 read-only, non-destructive, idempotent. Description adds key behaviors: no interpolation, exact_match flagging, AC return structure (magnitude_linear). Minor omission: no mention of response format constraints 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?

Three concise paragraphs front-loading core purpose and behavior, then handling specific modes. No redundant text; every sentence adds essential context.

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?

Covers all major usage modes (standalone, step sweeps, AC, job runs) for a 9-parameter tool. Output schema exists, so return value details are adequately supplemented by the description's AC specifics.

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%, but description explains parameter relationships (e.g., step_axis+step_value, job_id+run_index) and runtime behavior (nearest step selection, AC return details), adding significant value beyond 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 retrieves a signal value at a specific time or frequency, with 'nearest without interpolation'. It distinguishes from siblings by specifying the exact query operation.

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?

Explicit guidance on when to use step_axis+step_value vs step index, and raw_file vs job_id+run_index, providing clear alternatives for different scenarios.

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, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing the different return contents for netlists vs schematics, and notes supported file extensions. No contradictions with annotations.

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

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

The description is extremely concise (two sentences) with no redundant information. The first sentence front-loads the main action, and the second explains the two cases. Every sentence earns its place.

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

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

Given the tool's simplicity (two parameters), excellent annotations, and presence of an output schema, the description fully covers what the tool does for both netlist and schematic inputs. It mentions file extensions and return types, which is sufficient for an agent to 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% (both path and format have descriptions). The description does not add parameter-level meaning beyond the schema, but it does provide context about the tool's output types which indirectly aids understanding. 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 explicitly states the tool reads and parses circuit files (.cir/.net/.asc) and distinguishes between netlists (returns content/component values) and schematics (returns layout/directives). This is a specific verb+resource and clearly differentiates from sibling tools like validate_netlist or trace_net.

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 states what the tool does but does not provide guidance on when to use it versus alternatives (e.g., trace_net, component_info, or validate_netlist). No when-not-to-use or prerequisites are mentioned, though the read-only nature is implied.

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, destructiveHint, idempotentHint. Description adds 'Does NOT start or cancel anything' and explains what 'interrupted' means, including the recovery path. This provides behavioral context 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?

Description is three short paragraphs, front-loaded with purpose, then return details, then special behavior. Every sentence adds value. No 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?

Covers purpose, usage context, return fields, exceptional cases (interrupted jobs), and recovery path. Given that output schema exists, the description is complete and self-contained.

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 the 'format' parameter well-documented. The description says 'Needs no inputs', which is slightly imprecise as an optional parameter exists, but does not contradict. No additional parameter semantics are 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?

Description clearly states the tool returns 'recent circuits the user was last working with', a specific verb+resource. It distinguishes from sibling 'check_job' by mentioning it as a recovery path. The purpose is immediately clear.

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 says 'Call on session start', providing a specific usage context. Mentions that it is read-only and does not start or cancel anything, which guides against misuse. It does not list other alternatives beyond 'check_job', but the context is sufficient.

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 the description confirms the removal action. The description adds no contradictions but also does not elaborate on side effects beyond what the cleanup_wires parameter description covers. It is sufficiently transparent for a destructive 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 with no extraneous words, perfectly concise and front-loaded.

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

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

For a simple tool with three parameters and no output schema, the description adequately states the core purpose. However, it could be improved by noting its relationship to sibling tools or specifying that removal is permanent.

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 parameters. The description does not add any additional meaning beyond the schema, 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 clearly states the tool removes a component from a schematic by reference designator, which is a specific verb-resource pair that distinguishes it from sibling tools like add_component or move_component.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description lacks context for decision-making.

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?

Adds significant detail beyond annotations: explains snapshot restoration precisely, including that the snapshot is dropped after reset (so subsequent edits establish new restore point). Describes behavior with fresh schematics (empty file snapshotted on first add_component). Notes return of reverted=false for no edits, and session-persistence limitation. No contradictions with annotations.

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

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

Single paragraph is well-organized: starts with core purpose, then explains mechanics, then edge cases and notes. Every sentence adds value, no redundancy. Efficient and clear.

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

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

Given tool complexity (stateful reverts with snapshot management) and presence of output schema, the description covers all essential behavioral aspects: snapshot establishment, reset action, return value on no edits, session lifetime. No significant 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%, with adequate descriptions for path and format. The description adds no extra meaning for parameters 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?

Clear verb 'Revert' and specific resource '.asc schematic' to a pre-edit state. Distinguishes from sibling mutation tools like add_component, move_component, etc., by explicitly stating it reverts changes. Context of 'first edit this session' defines scope accurately.

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 use case: 'recovery escape hatch for when a sequence of edits went wrong.' Provides context for when it applies (edits this session) and notes that it is not a substitute for version control. Lacks explicit 'when not to use' but implications are 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 readOnlyHint, destructiveHint, and idempotentHint. Description adds value by explaining that Q is returned as null for boundary peaks without flanking crossings and warns about under-sampling causing inflated Q/bandwidth. 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?

Description is well-structured with purpose first, then usage notes and parameter tips. It is somewhat verbose but each sentence adds value. Could be slightly more concise, but still effective.

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 (7 parameters, output schema exists), the description is fairly complete. It covers the Q calculation formula, null case, and practical advice. With an output schema, return values need not be detailed here.

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 high (86% or more), so baseline is 3. Description adds extra context: explains min_prominence_db in detail and mentions min_separation_decades for merging duplicates, 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 it detects magnitude peaks in AC sweep and estimates Q factor and -3 dB bandwidth. This specific verb+resource combination distinguishes it from sibling tools like bode_metrics and stability_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?

Explicitly states when to use (RLC resonators, crystal oscillators, peaking amps) and when not to use (for filter characterization use bode_metrics; for stability margins use stability_metrics). Also provides parameter advice like min_prominence_db and sampling density.

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?

Discloses asynchronous execution and immediate job_id return, adding value beyond minimal annotations. 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?

Single sentence, front-loaded with verb and resource, zero waste. 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?

Covers purpose, async nature, and return value. No output schema, but description explains job_id. Could mention how to use job_id later (e.g., check_job), but not necessary.

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 schema already documents both parameters. Description adds slight context (source of config_id and default for max_parallel), but does not significantly enhance meaning.

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

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

Clearly states the verb 'execute', the resource 'configured Monte Carlo analysis', and key details (asynchronously, returns job_id). Distinguishes from sibling tools like configure_montecarlo and run_sweep.

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

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

Implies the tool requires prior configuration (previously configured), but does not explicitly list when to use vs. alternatives (e.g., run_sweep) or when not to use.

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

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

Discloses automatic sync/async behavior, timeout handling, hard cap (600s), and return types (file paths, job ID). No annotation contradictions; annotations are neutral, and description adds significant context.

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

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

Three sentences clearly convey purpose, behavior, and usage. No wasted words; each sentence earns its place.

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

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

Covers core behavior, return values, and key parameters. Lacks prerequisites or permission details, but adequately complete given schema and output schema exist.

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 all 4 parameters with descriptions; description repeats and elaborates slightly but adds no new semantics beyond what schema provides. Baseline 3 due to 100% 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?

Explicitly states 'Run a SPICE simulation on a netlist file', clearly differentiating from sibling simulation types like run_montecarlo and run_sweep.

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 guidance on execution mode (sync vs async) via wait parameter and timeout handling, but does not explicitly compare with alternatives or state when to use this tool over 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 indicate this is a write operation (readOnlyHint=false) but not destructive (destructiveHint=false) and not idempotent (idempotentHint=false). The description adds the async behavior and immediate job_id return. However, it does not disclose that each call creates a new job, nor the lifecycle of the job or what happens if the config_id is invalid.

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, 13 words, front-loads the core purpose and outcome. No redundant information.

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

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

Given a simple tool with two well-documented parameters and annotations covering safety, the description is mostly complete. It lacks specification of the return format (e.g., job_id as string) and explicit linkage to check_job for monitoring, but still informative enough for an agent.

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

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

Input schema has 100% coverage with descriptions for both parameters. The description does not add extra meaning beyond the schema; it mentions 'previously configured' aligning with config_id but doesn't elaborate on max_parallel beyond the schema's default note.

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

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

Description clearly states the tool executes a previously configured parameter sweep asynchronously and returns a job_id. The verb 'execute' and resource 'previously configured sweep' are specific. Differentiates from 'configure_sweep' (configuration) and 'run_montecarlo' (different simulation type).

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

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

The description implies that a sweep must be configured first (using configure_sweep) and that the execution is asynchronous, suggesting the user should later poll with check_job. However, it does not explicitly state when not to use this tool or mention alternatives like run_simulation for non-sweep runs.

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 provides extensive behavioral details beyond the destructiveHint annotation: it parses netlists, places components on a grid, connects via net labels, carries over directives, and notes label-based rather than routed wiring. It also explains the round-trip capability and how unsupported elements are handled. No contradictions with annotations.

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

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

The description is a single, dense paragraph that front-loads the main purpose, then covers process, limitations, and round-trip capability in logical order. Every sentence adds value without redundancy, achieving high conciseness while maintaining clarity.

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 (4 parameters, output schema exists), the description covers all essential aspects: what it does, input format, supported/unsupported elements, output characteristics, and response format options. The mention of skipped elements and round-trip integration with read_circuit provides adequate context for an agent to 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%, so baseline is 3. The description adds value by explaining that the first non-blank line of 'content' is treated as a title and ignored, and lists supported element types. It also clarifies the 'name' parameter exclusion of '.asc' extension and the default behavior of 'overwrite'. This exceeds 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 generates an .asc schematic from SPICE netlist text, specifying verb (Generate), resource (.asc schematic), and input (SPICE netlist text). It distinguishes itself from siblings like 'create_schematic' by detailing its automated placement and connection process, and explicitly lists unsupported elements that are returned for manual handling.

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 this tool (to automatically generate a schematic from a netlist) and when not (for multi-terminal/subcircuit elements that require manual placement). It mentions round-tripping with read_circuit but does not explicitly compare to sibling tools like 'create_schematic' or provide 'when not to use' guidance, though the limitations are 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 indicate readOnlyHint=true and destructiveHint=false, so the description adds value by detailing what status information is returned (simulators, config, security sandbox, runtime state). No contradiction, and the description aligns 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?

Two sentences: first explains what the tool does, second provides usage guidance. No unnecessary words, and the description is front-loaded with the most important 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 simple tool with one optional parameter, rich annotations, and an output schema, the description is complete. It explains the tool's purpose and when to use it, leaving no gaps for this level of 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 coverage is 100% with the 'format' parameter described in the schema. The tool description does not add any additional meaning beyond what the schema provides, so it achieves 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 clearly states it gets comprehensive server status including simulators, configuration, security sandbox paths, and runtime state. It distinguishes from sibling tools by being a general status check, unlike other tools that perform specific operations.

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 advises using it to check capabilities before attempting operations, providing clear when-to-use context. However, it does not mention when not to use it or alternatives, but for a status tool, this is adequate.

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 write operation and idempotency. Description adds constraints (only specific slots accepted) and netlist behavior (silently ignores unknown SYMATTR keys). No contradiction. Misses noting that setting an attribute overwrites previous value, but idempotent hint mitigates this.

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 that front-load the purpose and add crucial details. Every sentence earns its place with no 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?

Comprehensive enough for a constrained set operation. With 4 required parameters fully described, and no output schema needed for a side-effect tool, the description covers key behavioral constraints and usage tips. Could mention if attribute names are case-sensitive, but not essential.

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?

All 4 parameters have schema descriptions (100% coverage). Description adds meaning by listing valid attribute values and giving examples like 'W=10u L=0.5u' for SpiceLine, enriching understanding 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 'Set a schematic-only component attribute' with specific verb and resource. Lists standard LTspice slots (Value, Value2, etc.) and indicates what is rejected, distinguishing it from siblings like set_component_value.

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 says when to use (to set standard slots) and what not to use (anything else rejected). Provides alternative: for arbitrary KEY=val pairs, pass as SpiceLine. This is clear guidance on when and how to use versus 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?

Description aligns with annotations (idempotentHint true, destructiveHint false). No additional behavioral context provided (e.g., permissions, file mutation details). Annotations already shed some light, so description adds minimal new insight.

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

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

Single sentence, no wasted words. Front-loaded with key info. Could be slightly more structured but efficient overall.

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

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

Given 4 parameters fully described in schema and no output schema, the description captures the core purpose. However, lacks details like file modification behavior or return value, which would improve completeness for a mutation 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?

Schema covers 100% of parameters with descriptions. Description adds context about single vs batch mode, which maps to the parameters (reference/value vs values dict). Provides some added meaning 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?

Clearly states the verb 'Set' and the resource 'component value(s) in a circuit file'. Mentions two modes (single or batch), differentiating it from sibling tools like add_component or 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?

Implies batch vs single mode usage but lacks explicit guidance on when to use this tool over alternatives like set_component_attribute or batch_results. With many siblings, more direction would be beneficial.

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