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

Annotations declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. However, the description doesn't disclose what 'before' and 'after' represent (e.g., revision IDs, file paths), any output format, or rate limits, adding little 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 concise sentence with no waste, front-loading the comparison purpose. It is appropriately sized but could benefit from additional 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?

For a tool with 3 required parameters, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what the tool returns, how to interpret 'changed nets', or what inputs are expected, leaving the agent under-informed.

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 should compensate for parameter semantics, but it only vaguely refers to 'changes' without explaining what 'project', 'before', and 'after' should contain (e.g., revision identifiers, file paths). This is a significant gap for required parameters.

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 (Compare) and resources (connectivity, placement, project-file changes), distinguishing it from siblings like inspect_pcb_revision or diagnose_pcb_repair. It is clear but doesn't strongly differentiate its 'ECO' (engineering change order) focus from other analysis 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?

No explicit when-to-use guidance or alternatives are given. The description implies comparison of two revisions but doesn't state when to choose this tool over inspect_pcb_revision or verify_pcb_revision, leaving the agent to infer.

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 this is a non-read-only, non-destructive, closed-world write op. The description adds genuine value beyond that: it applies into a NEW board revision (i.e., doesn't mutate in place) and audits the result. It still omits permissions, failure modes, and what happens to existing revisions.

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 dense sentence with the action front-loaded and zero filler. It is efficient, though terse given the tool's complexity.

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

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

For a mutation tool with four fully-required undocumented parameters and no output schema, the description should explain prerequisites, the plan/candidate relationship, and what 'audit' returns. The one-sentence description leaves too much for the agent to infer.

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 all four parameters (project, revision, plan_id, candidate_id) are undocumented in the schema. The description loosely maps to plan_id ('recorded feasible placement plan') but says nothing about project, revision, or candidate_id, or how they relate. The description fails to compensate for the coverage gap.

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 (apply) and resource (a recorded feasible placement plan) plus the effect (into a new board revision) and follow-up (audit). This clearly differentiates it from sibling propose_pcb_layouts, which only generates plans. It does not name the sibling explicitly, but the verb+resource are 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 phrase 'recorded feasible placement plan' hints that a plan must already exist (e.g., from propose_pcb_layouts), but there is no explicit when-to-use, when-not-to-use, or prerequisite statement. An agent must infer the workflow order rather than being told 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 declare it is not read-only, not destructive, and not open-world. The description adds the critical constraint that only unrouted boards are supported, which is useful context beyond annotations. However, it does not describe side effects on the project/revision state, whether it mutates files in place, or how long the external Freerouting step might take.

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 filler, front-loading the action and then the constraint. It is appropriately sized for a low-complexity tool, though the second sentence could be slightly clearer about what 'supported' means.

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

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

Given no output schema and three parameters, the description is minimal but barely adequate. It omits parameter documentation, expected outcomes, error conditions (e.g., unsupported board), and any indication of how to handle the resulting SES file. For a mutating pipeline tool, this leaves 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 0%, so the description must compensate but does not. It never explains what 'project' and 'revision' refer to (likely an existing project name and revision identifier) nor what 'passes' controls in the autorouting algorithm. The description leaves all parameter meanings to inference.

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 action (autoroute), the resource (PCB revision), and the mechanism (export DSN, run Freerouting, import SES). This clearly distinguishes it from read-only siblings like inspect_pcb_revision or verify_pcb_revision. The only slight gap is that it does not explicitly state why one would choose this over other repair/layout submissions.

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 'Unrouted supported boards only' explicitly states a precondition, which is valuable. However, it does not name an alternative for already-routed boards or reference sibling tools, leaving the agent to infer that other submission tools handle those cases.

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 this is a non-read-only, non-destructive, closed-world operation. The description usefully adds that a ZIP hash-manifest is produced and that nothing is emitted unless the reverify succeeds, but it omits permission requirements, where artifacts are written, and what happens to prior releases.

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 tight sentence with the outcome and its condition front-loaded; every clause carries information and there is 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 write-side release-build tool with no output schema and fully undocumented parameters, the definition leaves major gaps: artifact destination, failure behavior, and how project/revision are identified are all unstated. The annotations cover safety only, not the operational detail an agent needs.

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% and both required parameters (project, revision) are bare strings. The description says nothing about how project/revision are specified (name, ID, path?), so it fails to compensate for the schema gap.

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 specific verbs (reverify, export, create) and names concrete artifacts (manufacturing files, hash-manifest ZIP), so an agent knows this is the terminal build/release step. It doesn't explicitly contrast itself with close siblings like verify_pcb_release_archive or verify_pcb_revision, 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?

Usage is only implied: the phrase 'only on success' suggests it should be run after verification passes, but there is no explicit when-to-use statement, no prerequisites named, and no routing to alternatives such as verify_pcb_release_archive. An agent can infer the context but is not told 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 declare this is a non-destructive, non-read mutation, and the description adds genuinely useful context beyond them: cancellation is deferred to the next stage boundary and will not kill an active native EDA operation. This tells the agent the effect is soft and eventual rather than immediate. It does not mention auth requirements or what state the job ends in.

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 zero filler. The most important constraint, that cancellation is deferred, comes first.

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 with no output schema, the description covers the critical behavioral nuance an agent needs. It omits return/state information, but nothing an agent must know 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 carries the burden, and it says nothing about job_id or its format. However, with a single self-explanatory required parameter, the practical risk is low; a baseline 3 reflects that the description adds no meaning but the schema field is obvious.

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 (cancel) and resource (engineering job) and clarifies the semantics of cancellation. It does not explicitly name or contrast with siblings like submit_engineering_job or get_engineering_job, but the operation is 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 explains what cancellation means behaviorally but gives no guidance on when to invoke it, no prerequisites, and no mention of alternatives. An agent must infer the usage 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds meaningful context beyond that: it clarifies that this only reads recorded findings and does not invoke native execution, which is important given a 'diagnose' name could imply active tooling. It still omits return format or any data-freshness 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?

Two short, front-loaded sentences with no filler; the core action leads and the scope boundary follows. It is efficient, though very terse given the parameter and output gaps.

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?

Annotations carry the safety profile and there is no output schema, so return-value explanation is not required. Still, with 0% parameter coverage and no output schema, the description leaves an agent without any guidance on the meaning/format of project and revision or what the recorded findings look like.

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 both required parameters (project, revision). The description only implicitly scopes results via 'scoped repair proposals' and never explains what project/revision identify or their expected formats, so it does not compensate for the coverage gap.

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 (Read) and resource (recorded verified DRC findings and scoped repair proposals), and the second sentence adds a negative scope boundary ('Does not run native tools'). It is clearly distinguishable from the submit_* repair siblings, though it does not name them explicitly.

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 'Does not run native tools' line implies this is a read-only diagnostic over already-recorded results, which is useful routing context. However, it never states when to choose this over siblings like submit_pcb_repair or analyze_pcb_eco, and there are no explicit conditions 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful nuance that results reflect 'actual local' capabilities (a live probe, not static documentation), but says nothing about latency, side effects, or what the probe returns.

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 padding. It is efficient, though at 12 words it is arguably under-specified rather than concise, and 'Java/router' phrasing is slightly cryptic.

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 carries the burden of explaining the return value, and it does not — an agent cannot know whether it gets version strings, booleans, or a capability matrix. For a discovery tool this is the main missing piece, though the annotations and zero-parameter schema keep the description minimally sufficient.

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 the baseline is 4. Neither the schema nor the description needs to document inputs, and the description introduces no phantom parameters.

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

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

The verb 'Discover' plus the resource 'capabilities' clearly identifies this as an environment/probe tool, and the mention of KiCad, native Python bridge, and Java/router distinguishes it from the PCB workflow siblings (import, inspect, route, repair). It is somewhat vague about what 'capabilities' concretely means, but an agent can tell it apart from every sibling.

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, when-not-to-use, or alternative-tool guidance. The agent is left to infer that this is a first-step diagnostic call rather than something invoked mid-workflow. A single clause like 'call before submitting any PCB job' would have fixed this.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds that the output is a self-contained HTML artifact containing geometry and verification evidence, but it doesn't say where the file is written, whether an existing report is overwritten, or what happens on a revision with unresolved verification failures.

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, front-loaded with the verb and the artifact type. Nothing is wasted and no filler precedes the core 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?

There is no output schema, so the description needn't explain return values, and it correctly names the output format. However, for a generative tool with two undocumented required parameters and no prerequisites stated, it leaves gaps an agent must guess at before invoking.

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% and the description never mentions 'project' or 'revision' at all — no format, no naming convention, no indication of whether revision accepts a label, hash, or id. With two required undocumented parameters, the description fails to compensate for the schema gap.

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 artifact: 'Generate a self-contained HTML review' and adds the material it embeds ('actual board geometry and verification evidence'). That distinguishes it from nearby siblings like build_pcb_manufacturing_release and verify_pcb_release_archive, though it never names them explicitly.

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 when-to-use guidance is given: nothing says whether the project must already be inspected/verified, whether a release must exist first, or how this differs from build_pcb_manufacturing_release or accept an archive. The agent must infer the trigger conditions from the surrounding tool 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine content context by naming what is returned (stages, outcomes, evidence), but says nothing about auth needs, behavior for an unknown or non-durable job_id, or latency.

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 front-loaded sentence with no filler or repetition. It is efficient, though at this size it could have afforded one more clause to cover parameter or usage context without becoming bloated.

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, and the description partially compensates by enumerating the returned content (stages, outcomes, evidence). However, for a job-retrieval tool with zero parameter documentation and no stated failure or not-found behavior, the definition is only minimally sufficient.

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 single parameter job_id has no description in either place. The phrase 'durable job' weakly implies job_id identifies a persisted job, but the description adds no format, source, or lookup meaning beyond the schema's bare string type.

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 (engineering stages, outcomes and evidence from a durable job), so the agent knows it retrieves details of a job. It stops short of naming the sibling it contrasts with, leaving the get-vs-list distinction implicit.

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 statement of when to use this tool versus the obvious alternatives list_engineering_jobs, cancel_engineering_job, or submit_engineering_job. The 'durable job' phrasing hints at fetching a specific job's persisted results, but the agent must infer that this differs from the list tool.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds the meaningful behavioral link that parent_revision corresponds to an external ECO revision. However, it does not explain what side effects a snapshot has on existing revisions or what 'sidecars' are.

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 that are front-loaded with the core action before the parameter hint. No filler, though the extremely terse phrasing leaves it under-explained for its complexity.

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

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

For a tool with 4 parameters, 0% schema description coverage, a nested constraints object, and no output schema, the description is too thin. It omits what the tool returns, what constraints applies to, and how the snapshot relates to the revision lifecycle covered by siblings.

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 the full burden for 4 parameters. It only clarifies parent_revision ('external ECO revision') and leaves project, board_path, and the entire constraints object undocumented. Three of four parameters get no semantic help.

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: 'Snapshot a KiCad board and project sidecars.' This tells the agent it materializes a point-in-time state of a board plus auxiliary files. It does not differentiate itself from siblings like inspect_pcb_revision or list_pcb_revisions, so it falls short of the top tier.

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 'Use parent_revision for an external ECO revision,' which implies a usage context for one parameter. There is no explicit when-to-use versus alternatives such as inspect_pcb_revision or pcb_project_history, nor any exclusions. Usage is implied rather than stated.

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

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

Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds genuine context beyond them: results are paginated and must be drained, and incomplete data ("missing metadata and unverified connectivity") is surfaced explicitly rather than silently dropped. It does not cover ordering or what a partial page means.

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 with the primary capability front-loaded and the operational/pagination note second. Nothing is padded, though the second sentence compresses three distinct ideas into one clause.

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 output schema and 0% parameter coverage, the description needs to do more. It never explains the section-driven response shape, the meaning of the required project/revision pair, or how search interacts with paging, leaving an agent under-informed for a six-parameter inspection 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 description coverage is 0% across six parameters, so the description carries the full burden and largely fails. The data domains loosely hint at the section enum values, and "page until total is exhausted" gestures at limit/offset, but search, project, and revision semantics are never explained.

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 ("Read") and enumerates the resource domains (component, pin, network, copper data) bound to a revision. This is clear on its own, but it never distinguishes itself from the sibling inspect_pcb_revision or list_pcb_revisions, so an agent has to guess which read tool fits.

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?

"Page until total is exhausted" gives real operational guidance on how to consume the result, but there is no statement of when to use this over inspect_pcb_revision or list_pcb_revisions, and no prerequisites. Usage is implied by the resource domains rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned content categories, but discloses nothing about permissions, cost, or failure modes beyond that. 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?

A single front-loaded sentence with a clear verb and an enumerated object list; nothing is wasted. It is efficient, if a touch terse given the coordination complexity of this tool family.

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

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

No output schema exists, so the description carries the return-value burden; it lists content categories but not format or structure. Parameter meanings remain unaddressed, leaving the definition adequate but not complete for a 2-required-param inspection 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 description coverage is 0% for the two required parameters ('project' and 'revision'). The description says 'the revision's' contents but never explains the arguments' format, accepted values, or how project and revision relate. With low coverage, the description should compensate and does not.

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 ('Read') and resource ('the revision') and enumerates the exact content retrieved (components, nets, outline, restrictions, constraints). This clearly distinguishes the *what* of the operation, though it never differentiates itself from sibling readers like inspect_pcb_inventory, list_pcb_revisions, or verify_pcb_revision.

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 prerequisites, and no mention of alternatives. The word 'actual' hints that this reads current/real state, but the agent gets no condition for choosing this over list_pcb_revisions or verify_pcb_revision.

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 the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond the annotations: the result set is capped at 100 and returns summaries rather than full data. It doesn't disclose pagination or truncation behavior when more than 100 jobs exist.

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, zero waste, with the scope (100 lightweight summaries) front-loaded before the routing hint. Every clause carries 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?

An output schema exists, so return values needn't be explained, and the description covers scope plus sibling routing. The only real gap is the unaddressed `project` filter, which an agent may need to use 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?

There is one parameter (`project`) with 0% schema description coverage, and the description never mentions it or explains what scoping it applies. With low coverage the description is expected to compensate, and here the filter semantics are left entirely undocumented.

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 (list engineering jobs) plus the shape of what comes back ('lightweight job summaries', capped at 100), and explicitly contrasts itself with the sibling get_engineering_job. An agent can distinguish this listing tool from the detail tool without opening either 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?

Names the alternative explicitly ('Use get_engineering_job for full steps and native evidence') with the condition that selects it, which is exactly the routing an agent needs. It stops short of saying when not to list at all, or how the optional `project` scope interacts with the call.

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 safe read-only profile, and an output schema covers return values. The description adds two useful behavioral facts beyond the annotations: revisions are immutable and results are ordered by creation time.

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 efficient, though the extreme brevity is also the source of the gaps in usage and parameter detail.

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

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

For a simple read-only list tool with an output schema, the safety and return-format burden is already covered. However, the description omits the sole parameter's semantics and any scoping/pagination behavior, leaving it 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?

Schema description coverage is 0%, so the schema does not document the sole 'project' parameter, and the description does not compensate. The meaning of 'project' (ID vs. name, format) is left entirely to inference.

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 (revisions), adding distinguishing traits (immutable, creation order). It is clear against the singular sibling inspect_pcb_revision, though it does not name or contrast any sibling explicitly.

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 when-to-use guidance, prerequisites, or alternatives are given. Given the crowded sibling set (inspect_pcb_revision, pcb_project_history), an agent gets no help deciding when to list revisions versus inspecting one or reading history.

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 this is a safe, read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds useful context that it both reads and validates a hash-chained ledger, implying an integrity check, but gives no detail on what validation means, failure modes, or cost.

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 zero filler that names the action and the target immediately. It is efficient, though its density leaves the missing details unresolved rather than wastefully padded.

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?

Low complexity (one tool, one param, no output schema) and annotations cover the behavioral profile, so the description need not explain return values. However, it leaves the required parameter's expected form and the meaning of 'validate' unspecified, which are the gaps an agent would need filled.

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% and the lone 'project' parameter is undocumented in both schema and description. The description never indicates whether 'project' is a name, ID, or path, leaving a required parameter 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?

States a specific verb pair ('Read and validate') and resource ('local hash-chained operation ledger'), which no sibling tool covers, so it is distinguishable from the surrounding PCB tooling. It stops short of a 5 because the phrase 'project's ... ledger' is abstract and doesn't clarify what a 'ledger' contains for the agent.

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 prerequisites, and no mention of any alternative or complementary tool among the many PCB siblings. The agent must infer that this is a project-audit/integrity step purely from the resource noun.

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=false, destructiveHint=false, openWorldHint=false, so the safety profile is partly covered, but the description omits the key behavioral facts an agent needs: whether this starts a compute job, whether it persists anything, how expensive/long it is, and what 'measured' means. 'Deterministic' is the only genuine addition, and it is thin for a non-read-only 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?

A single dense sentence with no filler or redundancy, though it is jargon-heavy and front-loads 'deterministic numerical' before the actionable meaning. Efficient, if not maximally informative.

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

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

For a tool with 2 required identifiers, an undocumented count parameter, no output schema, and no annotation detail beyond safety hints, the description is too sparse. It should at least say what gets produced, whether it persists state, and how results relate to apply_pcb_layout.

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% across all three parameters (project, revision, count), and the description supplies no meaning for any of them — no required identifiers, no hint that count controls how many candidate layouts are proposed. The 'compare ... candidates' phrasing only vaguely gestures at count.

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 verb and a rough resource ('placement optimization', 'feasible candidates'), which is enough to guess it proposes PCB layouts, but it never says 'layout', 'PCB', or 'propose' explicitly and does not distinguish itself from close siblings like apply_pcb_layout or autoroute_pcb_revision. The purpose is inferable but not sharp.

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 contrast with apply_pcb_layout or autoroute_pcb_revision, and no stated prerequisites (e.g., whether design constraints must already be set). The agent is left to infer that this is a pre-apply exploration step from the name alone.

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=false, openWorldHint=false, and destructiveHint=false, so the write/non-destructive profile is known. The description adds that this creates a child revision containing validated intent and compiled minima, which is useful behavioral context, but it omits permissions, reversibility, validation failure behavior, and 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 a single front-loaded sentence with zero filler. Every word contributes to the core purpose, and it is appropriately sized for a concise API definition.

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 large nested constraints schema, 0% schema description coverage, and no output schema, a single sentence is insufficient. It communicates the core operation but leaves the agent without adequate detail about required arguments, constraint semantics, validation behavior, or return effects.

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, but it only loosely alludes to the content of the constraints object ('design intent', 'KiCad minima'). It gives no meaning for project and revision, nor any structure or format guidance for the many nested constraint 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 ('Create') and resource ('child revision') and clarifies the content ('validated design intent and compiled KiCad minima'). It is clear enough to distinguish from read-only siblings like inspect_pcb_revision or list_pcb_revisions, but it does not explicitly name an alternative tool or clarify its relationship to the broader PCB workflow.

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 guidance, no prerequisites, and no mention of alternative tools for setting constraints or creating revisions. The agent must infer from the description that this is the appropriate tool, but nothing prevents confusion with siblings like submit_pcb_completion or propose_pcb_layouts.

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 write (readOnlyHint=false), closed-world, and non-destructive. The description adds real value beyond that: the job is persistent and asynchronous, and the calling session does not own execution, implying results must be retrieved elsewhere. It stops short of naming the polling/retrieval tool or stating whether submission is cancelable or idempotent.

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, front-loaded sentences with zero filler: the action leads and the execution-ownership caveat follows. Appropriately sized for a description, though a tool of this complexity arguably needs a little more substance rather than less.

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, async, mutation tool with a large undocumented nested schema and no output schema, the description leaves critical gaps: what operation values mean, what the call returns (job id?), and how to follow up. The annotations plus two sentences are not sufficient for an agent to call this correctly without reading external docs.

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%, and the single 'request' parameter is a deeply nested JobRequest with ~20 fields, a 13-value operation enum, and several option sub-objects — none of which are described anywhere. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap.

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 (queue) and resource (persistent job) and adds who executes it ('workbench or standalone worker'). It does not differentiate this generic submitter from the many specific siblings (submit_pcb_repair, submit_pcb_completion, submit_pcb_clearance_repair), so an agent cannot tell when to prefer it over them.

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 when-to-use guidance, no prerequisites (e.g. whether the project/revision must exist first), and no routing to the specialized submit_* siblings. 'This MCP session never owns its execution' is a behavioral note, not a usage rule.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds genuinely useful behavior beyond that: the additive-only default, that neckdown/fanout need explicit opt-in, and the "Never manufactures" guarantee. It does not explain the async job/return handle, but the annotation-lowered bar makes this a solid 4.

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?

Five short, front-loaded sentences with the core action first and constraints after; little waste. The telegraphic style ("Never manufactures") is terse but each sentence carries distinct 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?

For an async mutation with a nested options object and no output schema, the description covers scope, defaults, and a follow-up pointer (read job detail, retry from it), but omits what the call returns (job id?), prerequisites, and any auth or rate considerations. Adequate but with visible 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 0%, so the schema names options and defaults but explains nothing semantically. The description partially compensates by describing the additive-only default and which options (neckdown/fanout) enable extra behavior, but it says nothing about project, revision, or the other options fields (max_attempts, time_budget_seconds, etc.).

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 ("Queue automatic target discovery, bounded proposals and native checks") on a specific resource, and the phrase "No coordinates required" implicitly separates it from coordinate-driven siblings like submit_pcb_repair or submit_pcb_clearance_repair. The purpose is clear, but it never names an actual sibling to sharpen the distinction.

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 coordinates required" and "Default additive-only; optional neckdown/fanout require explicit options" imply the operating conditions, and "Read job detail for the retained revision and retry from it" hints at the follow-up flow. However, it never states when to prefer this over submit_pcb_repair, submit_pcb_reference_repair, or diagnose_pcb_repair, so the selection guidance is only 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 indicate non-read-only, non-destructive, so the agent knows it mutates but not dangerously. The description adds that native gates reject regressions and it 'never releases', which is extra behavioral context. But it omits permission/auth requirements, what qualifies as a regression, and what happens on failure.

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?

Very terse, a single compact sentence. Front-loaded verb. However, the extreme brevity may sacrifice necessary detail for this complex repair 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 complex, mutation-oriented PCB repair submission tool with no output schema, no parameter documentation, and many similar siblings, the description is far too thin. It should clarify the repair scope, preconditions, and relationship to other submit_* 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 and it does not. It never defines what 'nets', 'region', 'project', or 'revision' should contain, nor the expected format for the ROI or net identifiers.

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 verb and resource: 'Queue ... F.Cu joint movement', which is somewhat specific. But it's terse jargon and doesn't clearly distinguish from siblings like submit_pcb_repair or submit_pcb_reference_repair.

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 given on when to use this versus the many other submit_pcb_* repair siblings. The 'explicit ROI' constraint implies a usage condition, but alternatives are never mentioned.

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 declare the safe-write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds genuinely new behavior: input must be unrouted, output is a queued async job whose real attempts and best revision are only visible via polling. That async/limited-authority context is not recoverable from 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?

Three tight sentences with zero filler; the scope/capability summary is front-loaded, then constraints, then the required next action. Every sentence carries 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?

No output schema exists, and the description handles that by telling the agent the submission is asynchronous and results must be retrieved by polling the engineering job. Together with annotations covering the safety profile, this is nearly complete; only the returned job identifier/handle is left implicit.

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% and the description never mentions 'project', 'revision', or any of the many CompletionOptions fields (candidate_count, route_passes, repair_cycles, placement_mode, etc.). The capability categories loosely map to option groups, but no parameter names, defaults, or ranges are clarified, so it does not compensate for the coverage gap.

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?

Specific verb ('Queue') plus an enumerated scope: bounded layout candidates, whole-board routing, native checks, automatic repair. This sets it apart from narrower siblings like autoroute_pcb_revision or submit_pcb_auto_repair, though it never names a sibling explicitly.

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?

Gives a clear precondition ('Unrouted inputs only'), an explicit exclusion ('no manufacturing authorization' - i.e., not the release path), and a follow-up step (poll the engineering job). No alternative tool is named, but the context and boundaries are well defined.

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=false and destructiveHint=false. The description adds context beyond them: it discloses that source rules/placement are preserved and only 'native improvements' are adopted, which tells the agent what is and isn't mutated. It stops short of stating auth requirements, rollback, or job/queue semantics.

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 with the action front-loaded ('Queue local multi-net ECO repair...') and no filler. The trailing 'Not whole-board replacement...' fragment earns its place as a scope exclusion, though the dense jargon costs some readability.

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

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

For a mutation tool with no output schema and 0% schema coverage, the description covers scope and preservation semantics but omits parameter meaning, job/queue behavior, and any link to the other repair tools. Adequate as a starting point, but gaps remain for a 4-param, sibling-heavy operation.

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% and none of the four required parameters (project, revision, reference_project, reference_revision) is explained. The phrase 'explicit compatible, natively verified reference' loosely hints at the reference_* pair but gives no format, lookup, or compatibility detail, leaving the parameters essentially undocumented.

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 (queue) and resource (local multi-net ECO repair) plus a key qualifier ('using an explicit compatible, natively verified reference'), which separates it conceptually from auto/clearance repairs. However it never names the sibling submit_pcb_repair, submit_pcb_auto_repair, or submit_pcb_clearance_repair tools, so the differentiation against the crowded repair family is left to inference from jargon.

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 'using an explicit compatible, natively verified reference' implies the precondition for selecting this tool, and 'Not whole-board replacement or manufacturing authorization' gives an explicit exclusion. But with four sibling *_repair tools, no alternative is named or compared, so the when-to-use guidance is only 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 already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so safety is partly covered. The description adds genuinely useful context — 'Queue' implies asynchronous submission and 'Never releases manufacturing files' bounds the side effects — but says nothing about what 'approved' removal IDs require, permissions, or how the job is tracked afterward.

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, zero filler, with the operation and its scope front-loaded before the side-effect guarantee. Nothing is 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 6-parameter submission tool with no output schema, 0% schema coverage and four sibling repair variants, the definition leaves too much open: no return value or job-tracking hint, no differentiation from siblings, and half the parameters unexplained.

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% across 6 parameters, so the description must compensate and only partly does: 'nets', 'ROI' and 'approved copper removal IDs' map to nets, region and remove_ids and add real meaning (pre-approval workflow). It says nothing about passes, project, revision, or expected formats such as region being a numeric array.

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

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

States a specific verb (Queue) and resource (repair) plus its scope (scoped, explicit nets, ROI, approved copper removal IDs). However, it never distinguishes itself from the three sibling repair submitters (submit_pcb_auto_repair, submit_pcb_clearance_repair, submit_pcb_reference_repair), leaving the agent to guess which repair variant applies.

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 statement, no named alternative, and no prerequisite or exclusion. With four near-identical repair submitters in the sibling list, this absence is a real selection hazard rather than a minor omission.

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 openWorldHint=false, so the safety profile is covered. The description still adds one genuinely useful behavioral fact not in the annotations: verification happens without extracting the archive, so no files are written. It says nothing about failure behavior or what happens when hashes mismatch.

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 that states the action, the target, the scope of the check, and the non-extraction constraint with zero padding.

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

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

With no output schema and no annotation coverage of results, the description never indicates what the agent receives back (per-file mismatch list, pass/fail status, missing-file report). It is adequate to identify the tool but leaves the outcome shape 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% for the single archive_path parameter, so the description must compensate and does not: it never clarifies whether the path is local filesystem, absolute or relative, or a URL. 'A release ZIP' only loosely implies the path points at a zip file.

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 (verify) and resource (a release ZIP) together with the exact scope of the check: file set and all SHA-256 values. It implicitly separates itself from siblings like verify_pcb_revision (revision, not archive) and build_pcb_manufacturing_release, though it never names an alternative explicitly.

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 or when-not-to-use guidance. An agent cannot tell from the text whether this should be run after build_pcb_manufacturing_release, before import, or instead of verify_pcb_revision; the usage context is only inferable from the word 'release'.

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=false, destructiveHint=false, openWorldHint=false, so safety is partly covered. The description adds useful context that the checks are 'real' and produce 'revision-bound evidence', which is consistent with the non-read-only hint, but it does not say what evidence is produced, where it is stored, or whether it can fail or be costly.

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; the action, the check categories, and the evidence qualifier all earn their 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?

There is no output schema and the description does not explain what the returned evidence looks like or how to act on failures, which matters for a verification tool. Combined with zero parameter documentation and no annotation coverage of the actual side effects, the definition is too thin 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 description coverage is 0% and the description never mentions the two required parameters (project, revision). For a tool that is bound to a specific revision, the agent gets no clarification of what form an identifier takes or how 'revision' relates to the revision list returned by list_pcb_revisions.

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 action (run ERC/DRC, connectivity and geometric checks) against a specific resource (a PCB revision), and 'revision-bound evidence' signals the output nature. It is clearly distinct from a generic 'inspect' tool, though it never names or contrasts with the closest sibling inspect_pcb_revision.

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 prerequisites, and no indication of how this differs from inspect_pcb_revision or diagnose_pcb_repair. The word 'real' hints that some other path produces simulated checks, but the agent is left to infer when that tradeoff matters.

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