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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description need not restate that this writes. It adds real behavioral rules beyond the annotations – orthogonal routing required, different-net crossings rejected, source frequencies auto-inserted – which materially affect how the call is constructed. However it never mentions that writing to an existing path may overwrite it, nor what expected_sha256 guards, leaving the destructive behavior under-disclosed.

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

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

Front-loaded one-line purpose followed by a terse field-by-field breakdown; no filler sentences. The compressed notation ('default R/filter/diode pin0 left') is dense but every clause conveys a usable constraint.

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?

An output schema exists and annotations cover the safety profile, so those areas need no prose. But for a 5-parameter destructive tool with no top-level schema descriptions, the omission of path semantics (create vs overwrite) and expected_sha256's optimistic-concurrency role is a meaningful gap.

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

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

Top-level schema description coverage is 0%, so the description must carry the burden, and it does explain the components and connections payload shapes, zero-based pin indices with default pin conventions, and the harmonics object with a concrete example. It omits meaning for path and expected_sha256, keeping it below 5.

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

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

States a specific verb and resource – build and save a circuit – plus the distinguishing constraint 'from component/pin descriptions without writing .sch syntax', which separates it from raw schematic editing. It does not explicitly contrast with save_schematic or preview_schematic, which is the only reason it isn't a 5.

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 phrase 'without writing .sch syntax' implies the usage context (programmatic construction rather than hand-written files), and 'Diode additionally requires model=...' states a prerequisite. But there is no explicit when-to-use vs siblings like save_schematic, preview_schematic, or validate_schematic, so the agent must infer the workflow position.

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

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

The description adds substantial behavioral detail beyond the annotations: it explains that the worker terminates the native process tree, saves partial sweep results, releases a solver slot, and only then reports cancelled. This aligns with idempotentHint=true and destructiveHint=false by clarifying that repeated cancellation is safe and partial results are preserved.

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

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

The description is compact and front-loaded: the main action and polling requirement appear first, followed by side effects and safety details. Every sentence contributes useful information without 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?

For a one-parameter mutation tool with annotations and no output schema, the description covers the key side effects, safety profile, and effect on finished jobs. It could be slightly more complete by naming job_status as the polling mechanism or describing the cancellation response, but the core operational context is present.

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 is job_id, and the schema description coverage is 0%, so the description does not document the parameter at all. However, the parameter is self-explanatory in the context of cancelling a job, making the definition minimally adequate rather than misleading.

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

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

The description states a specific verb and resource: request cancellation of a job. It also distinguishes the operation from job inspection by noting that finished jobs are unchanged and that cancellation is followed by polling until the state becomes cancelled.

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

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

It clearly indicates the tool is for cancellation and notes that finished jobs are unchanged, which implicitly excludes completed jobs. It also states that repeated cancellation is safe, but it does not explicitly name job_status or another sibling as the polling 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 declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds that the copy is an independent variant and that an existing destination requires its hash, but it does not explain overwrite behavior, what gets destroyed, or permission requirements.

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 short sentences with no wasted text; the core action is front-loaded and the destination-hash condition follows directly.

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 output schema covers return values and annotations cover safety, but the description is thin for a destructive three-parameter tool with zero schema descriptions. It gives the core purpose and one precondition but leaves parameter meanings and overwrite behavior incomplete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies expected_sha256 only as the hash required for an existing destination, while source, destination, and hash format remain unexplained.

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

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

States a specific action and resource: saving a copy of a schematic as an independent variant. It distinguishes the outcome from merely saving, but does not explicitly name sibling alternatives such as save_schematic.

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

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

The only guidance is the precondition phrase "Existing destination needs its hash," which relates to expected_sha256 rather than when to choose this tool over save_schematic or other siblings. No when-not or alternative selection guidance is given.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the additive value here is the 'no interpolation' exact-match rule, the 1..20 dataset ceiling, and the domain caveat that AC samples are peak voltages while DC uses RMS. It does not mention cost, ordering of returned comparisons, or error behavior when a frequency is absent.

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 short sentences, front-loaded with the core action and with no filler. The second sentence is very jargon-dense, so it is efficient but borders on terse for a reader unfamiliar with the domain.

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?

An output schema exists, so return formatting need not be described. However, with 0% schema coverage and four parameters, the unexplained 'variable' parameter and the undefined dataset path concept leave a real gap for an agent assembling a first call.

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

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

Schema description coverage is 0% – all four parameters have only titles, so the description must do the work. It partially does: 'one actual frequency' and 'no interpolation' constrain frequency_hz, 'impedance-qualified dBm' explains impedance, and '1..20 datasets' explains dataset_paths. It never explains what 'variable' denotes or what a dataset path points to.

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

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

States a specific verb and resource: compare a complex voltage at one actual frequency across 1..20 datasets, with the 'no interpolation' constraint. That is far more precise than a bare 'compare results' and implies a difference from read_results, but it never names the sibling it competes with.

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

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

The 'no interpolation' note implicitly tells the agent the frequency must land exactly on an existing sample, which is real selection guidance. It never says when to prefer this over read_results or parameter_sweep, and gives no prerequisites for building the dataset_paths list.

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 the tool is non-read-only, non-idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond the annotations by stating that creation targets a configured project root and fails if the project already exists.

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

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

Two short sentences, front-loaded with the core action and followed by a key failure condition. There is no wasted text.

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 output schema covers return values and annotations cover safety, so the description need not explain those. However, for a tool with two undocumented parameters, it leaves important invocation details unclear, especially the meaning of "name" and "root."

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain what the required "name" parameter does or how the optional "root" parameter changes the target location, only referring vaguely to a "configured project root."

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

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

The description states a specific verb and resource: "Create a new _prj directory in a configured project root." This distinguishes it from listing or cloning tools, though it does not explicitly name a sibling alternative for creating a project.

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?

There is no explicit guidance on when to use this tool versus alternatives such as clone_schematic, nor any stated prerequisites beyond the failure condition. The use case is implied by the verb but not elaborated.

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 establish that this is a safe, read-only, idempotent, non-destructive, closed-world operation. The description adds useful scope by naming the environment components that are inspected, though it does not describe failure behavior or whether checks are active probes versus reports of configured state.

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?

It is a single compact sentence that front-loads the action and lists the checked components without 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?

With an output schema present and rich read-only annotations, the description does not need to explain return values. It is nearly complete for a zero-parameter diagnostic tool, though a brief indication of when to call it would remove the remaining ambiguity.

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?

This tool has zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify.

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, 'Check', and names concrete resources: local installation, simulator, BAT54 library, configured project roots, and capabilities. It clearly differs from project/schematic/job sibling tools, though it does not explicitly name or contrast those alternatives.

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

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

The description lists what is checked but gives no explicit guidance on when to use this tool versus siblings like list_projects or job_status. Usage is only weakly implied by the diagnostic nature of the check.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds that the result is 'fresh' and that the template must be 'installed', which carries real behavioral meaning about availability and re-derivation, but it stops short of saying whether the spec is cached, regenerated, or how it is scoped.

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

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

A single front-loaded sentence with no filler. Brevity serves it, though the same tidiness leaves no room for the routing or return-shape information the tool needs.

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?

There is no output schema, so the description is the only place an agent can learn what a 'builder specification and requirements' actually contains, and it does not say. For a tool whose entire value is the shape of its return, that is a substantial omission.

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

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

Schema coverage is 0%, so the description bears the burden for the single `name` parameter, yet it never mentions it. Only the phrase 'installed template' indirectly implies what `name` denotes; the enum values are visible in the schema but their meaning (what the voltage_divider vs mixer template produce) is undocumented anywhere.

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?

Names a specific verb (Return) and resource (builder specification and requirements for an installed template), so the retrieval intent is clear. It does not distinguish itself from list_schematic_templates or read_schematic, so an agent could confuse which of the template/schematic readers it needs.

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?

There is no when-to-use guidance, no mention of prerequisites, and no alternative named. With siblings list_schematic_templates, read_schematic, preview_schematic and build_schematic all plausibly adjacent, the description gives the agent nothing to route on.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds only the pre-edit timing intent and the fact that a SHA256 is produced; it says nothing about how the digest should be used for change detection or what happens on a missing/invalid file.

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

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

A single front-loaded sentence with no filler. Slight ambiguity remains in the middle clause ('component parameters and SHA256'), which reads as a list of outputs rather than a crisp statement of what is returned or why the digest matters.

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 an output schema present, return values need not be explained, and annotations cover safety, so the remaining gaps are the sibling disambiguation and path semantics. For a one-parameter read tool that is adequate but leaves the agent to infer which of several schematic-reading tools to call.

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?

There is one required parameter, 'path', with 0% schema description coverage, so the description carries the burden. It does convey that the path should point to a .sch file, which is real added meaning, but nothing about absolute vs relative paths, workspace roots, or error behavior for a bad path.

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

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

States a specific verb ('Inspect') and resource (a .sch file), and names what is surfaced: component parameters and a SHA256 digest. It does not, however, distinguish itself from close siblings like read_schematic or preview_schematic, so an agent must still guess which inspection tool to pick.

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 phrase 'before a background edit or run' implies a pre-mutation verification workflow, which is genuine usage context. But it never says when to prefer this over read_schematic, preview_schematic, or validate_schematic, and no prerequisites or exclusions are given.

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

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

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful context by specifying it returns status, latest progress, result, or error for a session-local job. It does not disclose timing, blocking behavior, or how job_id is obtained, but with annotations present, a 3 is appropriate.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes to defining the resource and the kinds of information returned.

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

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

For a simple read-only status tool with rich annotations and no output schema, the description adequately explains the return contents (status, progress, result, error). However, it leaves gaps around how to obtain job_id and when to choose job_status over read_results, so it is only minimally 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?

The schema has one required parameter ('job_id') with 0% description coverage, so the description must compensate. It only implies a job identifier through the phrase 'job's status' and does not explain the parameter's format, source, or expected value, adding little 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 states a specific verb ('Read') and resource ('a session-local job's status, latest progress, result or error'), making the tool's purpose clear. However, it does not differentiate itself from sibling tools such as read_results or start_job, and the mention of 'result' overlaps with read_results, leaving some 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 does not state when to use this tool versus alternatives like read_results or start_job. It only describes what the tool does, with no explicit context, exclusions, or guidance about when polling job status is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description adds useful context by pinning results to the locally configured roots, but says nothing about ordering, empty-result behavior, or failure modes when no roots are configured.

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

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

A single sentence with no filler, front-loading the action and scope before the clarifying negation. Nothing could be removed without losing 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?

With no parameters, a full annotation set, and an output schema handling return values, the description covers nearly everything an agent needs. The only residual gap is the ambiguous domain term 'uSimmics' and the absence of any hint about what happens when no roots are configured.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The scope phrase 'configured local roots' usefully explains that filtering is environmental rather than parameterized.

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

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

States a specific verb (list) and resource (uSimmics projects) plus a scope qualifier ('in the configured local roots'), so the agent knows exactly what is returned. It does not name the sibling create_project explicitly, instead phrasing the distinction negatively as 'without creating projects.'

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 clause 'without creating projects' implies the read-only counterpart to create_project, but the description never explicitly says 'use create_project to make one' or states any other when/when-not condition. Usage is implied rather than directed.

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, non-destructive, idempotent, and closed-world behavior. The description adds 'without configuration or disk writes', which reinforces the side-effect profile but does not cover auth, rate limits, or return shape; with annotations present, this is a moderate contribution.

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

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

A single front-loaded sentence with no filler. It is appropriately sized for a parameterless listing tool.

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 zero-parameter read-only list tool with rich safety annotations, the description is mostly complete: it states scope and absence of side effects. It could go further by clarifying what is returned or how it differs from get_schematic_template, but no critical calling information is missing.

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

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

The tool takes no parameters, so the schema and description confirm there is nothing to document. Baseline for zero parameters is 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 states a concrete resource (templates in the installed package) and clarifies that it is a read-only discovery operation. It does not explicitly contrast with get_schematic_template or other siblings, so it stops short of a 5.

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?

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives such as get_schematic_template. The use case is inferable but not stated.

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

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

Annotations declare a non-read-only, non-idempotent, non-destructive mutation, and the description adds substantial context beyond that: source preservation, per-run time limits, per-point status, a durable partial summary, cancellation behavior that preserves the checkpoint, and hash-checked resume. It omits where outputs land and any authorization or concurrency constraints, keeping it short of a 5.

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 core action and output format are front-loaded in the first sentence, with operational mechanics following in short clauses. Density is high and nearly every clause carries information, though the run-limit and sampling rules could be grouped more cleanly.

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?

An output schema exists, so return values need not be described, and the behavioral section is strong. However, for a 9-parameter mutation tool with zero schema description coverage, four core parameters (path, component, parameter, variable) remain opaque, leaving the definition incomplete for correct invocation.

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

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

Schema coverage is 0% across 9 parameters, so the description must carry the burden, and it only partially does. It clarifies fail_fast ('stops after a failed point'), resume_from ('retries unfinished points after checking source and data hashes'), the values count (1..20), the timeout bound (1..30 seconds), and ties frequency_hz to sampling ('must exist as an actual sample'). It leaves path, component, parameter, and variable completely unexplained.

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 names a specific verb ('Simulate') and resource ('independent parameter variants'), states the cardinality bounds (1..20) and output shape (JSON/CSV comparison), so the agent knows exactly what the tool does. It does not, however, contrast itself with siblings like update_parameters, run_schematic, or compare_results, which appear closely related.

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?

There is no explicit statement of when to choose this over update_parameters or run_schematic, and no when-not guidance. Some usage is implied through the fail_fast and resume_from mechanics, but the agent must infer the decision context entirely.

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 mark readOnlyHint=false, and the description earns that by disclosing the actual side effects: the PNG is saved locally, native GUI screenshots are not produced, Paintings annotations are omitted with a warning, colliding labels are nudged and reported in adjusted_labels, and mismatched-provenance data is flagged in the image. It also states the exact return shape (native MCP image content, spectrum_markers rounded to two decimals), which goes well 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 main output is front-loaded in the first sentence and the remaining detail is ordered by importance: rendering behavior, then label handling, then spectrum specifics. The spectrum sentence is dense and packs several clauses, but no sentence is pure 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?

There is no output schema, yet the description covers return values thoroughly (image content, adjusted_labels, spectrum_markers, per-node panels). With only two parameters and no output schema, the main remaining gap is the meaning of the required path parameter, which is left entirely to inference.

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

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

Schema description coverage is 0%, so the schema gives only bare titles 'Path' and 'Dataset Path'. The description indirectly explains dataset_path (it drives the optional spectrum) but says nothing about what path refers to (schematic file? project?) or what format it expects.

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

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

The description opens with a specific verb and resource: 'Return a PNG image of the saved circuit layout and optionally its discrete HB spectrum.' That is enough to separate it from inspection/read siblings, but it never explicitly contrasts itself with inspect_schematic or read_schematic, which also deal with schematics.

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

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

Usage is only implied: the phrase 'optionally its discrete HB spectrum' hints that supplying the second argument opts into spectrum rendering, but there is no explicit 'use this when' or a named alternative for plain textual inspection. The agent must infer the choice from the sibling list.

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

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

The annotations already declare a destructive write, and the description adds meaningful behavior beyond them: it backs up an existing .dat, refuses stale results and custom DataSet paths, and requires GUI reload to view changes. This gives the agent a clear picture of side effects and failure conditions.

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

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

The description is four compact sentences, front-loads the main operation, then lists prerequisites and side effects. Every sentence adds useful context without 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 output schema and annotations, the description covers the write behavior, backup behavior, rejection modes, and post-action requirement well. The remaining gap is exact parameter mapping, which matters because the schema itself provides no 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 description coverage is 0%, so all three required parameters lack structured explanations. The description implies mappings for the .dat path, dataset, and current schematic hash, but it never names the parameters or clarifies expected formats, leaving path vs dataset_path ambiguous.

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

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

The description gives a specific verb and resource: save the bridge's verified run dataset to the schematic's .dat path for GUI plots. It distinguishes this operation from read_results and save_schematic by naming the dataset-publishing outcome and GUI-plot 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?

It states clear prerequisites (matching run provenance and current schematic hash), exclusions (refuses stale results and custom DataSet paths), and the context for use (GUI plots, then reload in the GUI). It does not name an alternative sibling tool, but the when-to-use conditions are strong.

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 establish that this is a read-only, idempotent, non-destructive operation in a closed world. The description adds that only verified results are read and that output is bounded by points, which is useful context, but it does not describe error behavior, result format, or how verification status affects reading.

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the core action and scope efficiently.

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

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

An output schema exists, so return values need not be explained in detail. However, the description leaves the required path parameter's meaning unstated and provides no usage alternatives, which are notable gaps for a tool with two parameters and many sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It partially explains max_points by saying results have a bounded number of points, but it does not clarify what the required path parameter refers to or how it should be formed.

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 names a specific verb (read), resource (simulation results), and qualifies the data type (verified QucsData v2 real/complex). It clearly distinguishes the tool from most siblings, though it does not explicitly differentiate it from compare_results or preview-oriented tools.

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

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

The description implies that the tool is used to read simulation results, but gives no explicit when-to-use guidance, prerequisites, or alternatives such as compare_results. An agent must infer the usage context.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context. It does: it discloses that the raw file content and a SHA256 digest are both returned, and that malformed files are read rather than rejected — a non-obvious behavioral trait for a diagnostic workflow. Return structure is covered by the output schema, so this is close to sufficient.

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?

One compact sentence with the core action first and the two notable properties (SHA256, malformed-file tolerance) appended. No filler, nothing repeated from the 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?

For a one-parameter read with a full annotation set and an output schema, the description covers the essentials. The remaining gap is path semantics — how an agent obtains a valid path (e.g., via list_projects) — which is not addressed.

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

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

Schema description coverage is 0%, so the sole 'path' parameter is undocumented in the schema. The description only weakly compensates by implying the path points at a saved .sch file; it doesn't say whether the path is absolute, project-relative, or how to discover valid paths. Baseline 3 for a single required param.

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

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

States a specific verb and resource: reading the complete saved .sch source, and adds that the SHA256 is returned alongside it. The word 'complete' and 'source' implicitly contrasts with the inspection/preview/validation siblings, but no sibling is named, so the differentiation is inferential rather than explicit.

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 phrase 'including malformed files for diagnosis' implies one use case (raw retrieval when a schematic may be broken), which is useful. However, it never says when to choose this over inspect_schematic, preview_schematic, or validate_schematic, and gives no prerequisites or 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 already declare it is a non-readOnly, non-destructive, non-idempotent, closed-world operation; the description adds real value beyond that: isolated run folder, no window, no overwrite of GUI datasets, unique output paths plus solver status, and explicit failure on ambiguous wiring. It stops short of noting that the `timeout` parameter governs the run or what happens on timeout.

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 short sentences, front-loaded with the core action, then constraints, then return contract. Little waste, though the supported-subset sentence is dense and the closing sentence slightly overlaps the output schema.

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?

An output schema exists so return values needn't be detailed, and failure behavior is covered. Still, for a non-idempotent compile-and-run tool with zero schema parameter documentation, the description omits path expectations and timeout semantics, leaving key invocation details unresolved.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate and does not: `path` is never explained (file path? project-relative? .5.9 file?) and `timeout` is not mentioned at all, despite its 1–300 range and 60s default. Only an indirect hint ("supported 5.9 schematic") gestures at what `path` points to.

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

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

States a specific compound action (compile a 5.9 schematic, run simulator.exe headlessly in an isolated folder) with the supported component subset named. It is distinguishable from build_schematic/validate_schematic/preview_schematic in spirit, though it never names a sibling explicitly to contrast with.

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

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

Use is implied by the described scope ('supported 5.9 schematic', 'documented R/C/L ... subset'), and it warns that unknown components fail. But there is no explicit when-to-use guidance versus build_schematic, preview_schematic, start_job, or validate_schematic, so an agent must infer routing.

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 only flag destructiveHint and non-idempotency; the description adds distinctly useful behavior: atomic write, automatic backup of existing files, syntax and connectivity validation before any write, UTF-8/LF normalization, and that unsaved GUI buffers are never persisted. That is real operational context an agent cannot infer from 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?

Front-loaded with purpose, then the workflow constraint, then the hash rule and validation/encoding guarantees. Every sentence carries information; the short lines add slight fragmentation but no 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?

For a destructive write tool with an output schema present, the description covers origin of content, concurrency/overwrite safety via SHA256 and backups, pre-write validation, and encoding behavior. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does: 'content' is defined as the full source from read_schematic including edits, and 'expected_sha256' is bound to the existing-file case with explicit instruction to omit it for new files. 'path' is the only field left implicit, which is minor given the rest.

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

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

States a specific verb and resource ('Save a complete supported 5.9 schematic atomically') and enumerates the payload scope (components, wires, plots), which separates it from siblings like validate_schematic, build_schematic and clone_schematic. An agent can identify the tool without opening the schema.

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?

'Supply full source from read_schematic with requested edits' tells the agent the intended read-then-write workflow, and the SHA256 rule disambiguates update versus create. It stops short of explicitly naming validate_schematic as an alternative or stating when not to call this, so it is clear but not exhaustive.

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

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

Beyond the annotations, the description discloses important lifecycle and concurrency behavior: session-local job IDs, retention of the latest 64 jobs, at most four active jobs and one native solver, survival of artifacts and sweep summaries across restarts, and cancellation when the server closes.

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

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

The description is four sentences, front-loads the core action, and every sentence contributes operational information or constraints. There is no redundant restatement of the tool name.

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

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

For a complex background-job tool with no output schema, the description covers session requirements, concurrency limits, retention, restart behavior, and cancellation well. It does not explicitly state what start_job returns, such as a job ID, but that is implied by the instruction to poll job_status.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only says 'run or sweep,' vaguely matching the request oneOf variants, but it does not explain operation, path, timeout, component, parameter, values, or other request fields.

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

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

The description states a specific verb and resource: 'Start a background run or sweep.' It also names related tools job_status and cancel_job, but it does not explicitly distinguish start_job from the synchronous-sounding siblings run_schematic and parameter_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?

It gives clear operational context: start a background operation, poll with job_status, and stop via cancel_job. It also states the prerequisite of a persistent MCP session, though it does not explicitly say when to choose start_job over run_schematic or parameter_sweep.

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?

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing atomicity, that a backup is taken, conflict detection via the passed hash, that all edits validate before any write, and the non-obvious side effect of updating harmonic-balance frequency keys. It also warns that changes are on disk only until reload.

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

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

Front-loaded summary sentence, then a compact example payload, then the non-obvious consequences. Every sentence carries distinct information; nothing is repeated from the schema.

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?

An output schema exists so return values need no explanation, and the mutation semantics are well covered. The gap is the required 'expected_sha256' — the most failure-prone input for a destructive, non-idempotent write — plus 'path' — both left for the agent to infer with zero schema documentation.

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

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

Schema coverage is 0%, and the description compensates partially: it gives the exact edit object shape, a concrete example, and explains that 'parameter' accepts a semantic name or native index (matching the anyOf). But it never explains 'path' or the required 'expected_sha256' beyond the vague phrase 'conflict detection'.

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

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

States a specific verb and resource ('Atomically edit component parameters') plus distinguishing scope: backup, conflict detection, and harmonic-balance key propagation. An agent can tell this apart from save_schematic or parameter_sweep without opening any schema.

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 routes the agent to inspect_schematic for valid parameter names/indices, and tells it the file must be reloaded in uSimmics afterwards. It does not state when to prefer save_schematic or parameter_sweep instead, so there is no explicit exclusion set.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine value beyond them: it discloses the return payload (valid/errors/warnings plus a compiled netlist) and, importantly, sets a scope boundary by warning that not every native GUI feature is rendered or checked — a caveat an agent needs to avoid over-trusting a clean result.

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 tight sentences, front-loaded with the enumerated checks, then the return contract and caveat. Every clause carries information; the only slight friction is the jargon phrase 'HB settings' and 'saved-file sections' which assume domain familiarity.

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?

An output schema exists, so the description need not spell out return structure, yet it helpfully names the key fields anyway. With one required parameter and full annotation coverage, the definition is nearly complete; the only shortfall is the absence of any guidance on the path argument or on where this sits relative to inspect_schematic and build_schematic.

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 single 'path' parameter has 0% schema description coverage, and the description never mentions it — no indication of whether it points to a saved schematic file, a project, or a template. The parameter is conventional enough that this is a minor gap rather than a blocker, but the description does nothing to compensate for the 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?

States a specific verb (check/validate) and resource (schematic), then enumerates exactly what is checked: saved-file sections, plot closure, component connections, HB settings. It does not explicitly differentiate itself from the sibling inspect_schematic, so an agent must infer that 'validate' means structural/format checking while 'inspect' likely means reading contents.

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?

Usage is implied by the verb 'validate' — an agent can guess this is the pre-flight check before build_schematic or run_schematic — but the description never says when to call it versus inspect_schematic, nor does it state any prerequisite (e.g., must the file be saved first, does it work on unsaved schematics?).

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