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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description doesn't need to restate mutability. It adds useful context beyond annotations: the write target (sketch.yaml) and the read-mode fallback when sketchPath is omitted. It doesn't detail error handling or overwrite behavior, but the key behavioral trait (dual read/write mode) is 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?

Two compact sentences. The primary purpose is front-loaded, and the secondary read-mode is appended without superfluous words. Every clause earns its place.

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

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

For a 4-parameter mutation tool with no output schema, the description adequately covers what it does, why, and the two modes. The lack of output schema means a hint about what 'shows current defaults' returns would help, but the core is complete 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 100%, so the schema already documents each parameter with examples. The description adds meaning by explaining the consequence of each: fqbn/port/programmer become saved defaults, and omitting sketchPath switches to a display mode. That is value beyond the schema's per-field descriptions.

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

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

States a specific verb (save) and resource (default port + FQBN + optional programmer into a sketch's profile), and explicitly ties it to the downstream effect (later compile/upload calls can omit them). It's clearly distinguishable from siblings like board-list or board-details, which are read-only board queries.

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 clarifies the two modes: with sketchPath it saves defaults, and 'With no sketchPath, shows current defaults.' This gives clear usage context. It doesn't name an explicit alternative tool for viewing defaults, but the mode distinction is sufficient for correct invocation.

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?

No annotations are provided, so the description carries the full burden. It reveals the read-only nature and the fields returned, but doesn't state whether the FQBN must already be installed or resolved, or what happens on an unknown FQBN. For a lookup tool with zero annotation coverage this is thin.

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 resource front-loaded and no filler. Nothing to trim.

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

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

Adequate for a single-param lookup tool, but with no annotations and no output schema, the description could have carried more behavioral context (failure modes, resolution behavior). It covers the minimum viable surface.

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

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

Schema coverage is 100% – the single 'fqbn' parameter is fully documented in the schema with an example. The description repeats 'for an FQBN' without adding format or resolution semantics beyond the schema. Baseline 3 applies.

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

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

States a specific verb ('Show details') and resource (a board identified by FQBN), and lists the exact fields returned (required core, board options, default programmer). It is distinguishable from siblings like board-listall or board-list, though it doesn't name 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?

No guidance on when to use this versus board-list or board-listall, and no prerequisites stated. Usage is only implied by the FQBN requirement.

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

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

With no annotations, the description must carry the behavioral burden. 'List' implicitly signals a read-only operation, and the output fields are stated. But it lacks explicit safety statements (e.g., non-destructive, no side effects) or any mention of error conditions, timeouts, or prerequisites. It is adequate but not rich.

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

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

Two sentences with no fluff. The first states what it does and what it outputs; the second gives usage guidance (run first to discover upload port and FQBN). Every word earns its place.

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

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

For a zero-parameter list tool, this is complete. It tells the agent what it returns (port, protocol, FQBN) and how to use it in a workflow (run first to get upload info). Nothing else is needed to call it correctly.

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

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

The tool has zero parameters, so the schema is empty. The description correctly avoids adding parameter details. According to the rubric, a 0-parameter tool gets a baseline of 4, and the description adds no noise here.

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 ('List') and a specific resource ('connected Arduino boards'), and clearly states what it returns (port, protocol, detected FQBN). It distinguishes itself from the sibling 'board-listall' by the word 'connected', implying a subset of boards.

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, actionable context: 'Run this first to find the upload port and FQBN.' This tells the agent when to invoke it and for what purpose. However, it does not explicitly mention when not to use it or name alternatives like board-listall, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the burden. It discloses that results include FQBNs, which is useful return-content context, but says nothing about pagination, ordering, or whether the list is cached/installed-vs-supported only. For a simple read-only list this is adequate but not rich.

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 core action front-loaded and the optional filter second. Nothing redundant or 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?

For a one-parameter list tool with no output schema, the description covers what is listed and that FQBNs are included, which is enough to invoke correctly. The only gap is failure to clarify its role versus the sibling board-list.

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

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

Schema coverage is 100% and the single parameter already documents the substring filter in the schema. The description's filter examples ('uno', 'esp32', 'nano') mostly duplicate the schema examples, adding little beyond it. Baseline 3 is correct.

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 (boards), and adds that FQBNs are returned. The 'all supported' qualifier hints at breadth but never explicitly distinguishes it from the sibling board-list, so an agent must still guess which listing tool is intended.

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 notes an optional name filter and gives examples, which implies the common usage. However, it gives no when-to-use guidance relative to board-list or board-details, leaving sibling selection to inference.

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, idempotentHint=false, readOnlyHint=false, so the safety profile is covered. The description adds non-redundant context: it requires physical hardware and warns to double-check fqbn + programmer, which is exactly the failure mode for this irreversible operation. It omits what actually happens to the existing bootloader/flash contents.

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 and mechanism, then the hardware caveat, then the verification warning. No filler and no repetition of the name or title.

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, but the tool's contract is simple and annotations carry the safety profile, so the description's coverage of prerequisite hardware and pre-flight verification is largely sufficient. It could note the consequences of a mismatched fqbn/programmer to be fully complete for an irreversible 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 100%, with each of fqbn, port, and programmer documented in the schema itself. The description only echoes 'fqbn + programmer' as things to verify and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (burn) and resource (bootloader) plus the required mechanism (external programmer), which cleanly separates it from the sibling `upload` tool. The examples (USBasp, atmel_ice) pin down the resource unambiguously.

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?

Clearly signals when this applies: only with extra programming hardware, explicitly 'not a normal upload', which implicitly routes agents to `upload` otherwise. It stops short of naming the alternative tool or stating prerequisites like the board being disconnected from the normal port.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that it returns memory usage and errors, but says nothing about build failures timing, dependency/board-attach requirements, or rate/latency 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?

Three short sentences, front-loaded with the core action, then the hardware-free benefit, then the return contents. No wasted words.

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

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

With no output schema, the brief mention of memory usage and errors covers the return shape adequately, and 100% schema coverage handles parameters. The main remaining gap is routing guidance relative to sketch-validate and preprocess.

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

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

Schema description coverage is 100%, so all seven parameters (fqbn, verbose, libraries, sketchPath, boardOptions, additionalUrls, buildProperties) are already documented with examples in the schema. The description adds no parameter meaning beyond that.

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+resource ('Compile an Arduino sketch for a board') that clearly conveys the action. However, it does not distinguish itself from the sibling sketch-validate, which an agent may confuse with a hardware-free code check.

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 'Verifies code without needing hardware' implies the build-without-upload scenario, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative (e.g. sketch-validate, upload, preprocess) is named or contrasted.

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 non-readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: installation is slow on first run, and certain cores (esp32) need a board-manager URL. It does not cover permissions or output, but for this tool the timing caveat is the key operational fact.

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 compact sentences with the core purpose first and the operational caveat second; no filler, 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?

For a three-parameter, no-output-schema install tool with annotations covering safety, the description plus schema gives an agent enough to call it correctly, including the slow first-install expectation. It could say a bit more about prerequisites (e.g., needing the board index URL configured) but is otherwise complete.

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

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

Schema coverage is 100%, so coreId, version, and additionalUrls are all documented in the schema, including the 'omit for latest' convention. The description's example IDs and the esp32-needs-URL note reinforce rather than extend that, so it sits at the baseline.

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 ('Install a board core') and illustrates the resource with concrete IDs ('arduino:avr', 'esp32:esp32'). This clearly separates it from siblings like core-upgrade, core-search, and lib-install without needing to name 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?

Usage context is implied by naming the operation and giving examples, and it usefully notes that esp32 requires an additional URL. However, it never states when to prefer this over core-upgrade, nor any preconditions for installing a core.

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?

No annotations are provided, so the description carries the full burden. It conveys that this is a non-mutating enumeration and hints at the shape (platforms with versions), but says nothing about ordering, format, or whether results are cached/refreshed.

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 resource and nothing extraneous.

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 zero-parameter, side-effect-free list with no output schema, the description covers what is enumerated and roughly what comes back ('with versions'). Only the exact result shape/ordering is left implicit, which is a minor 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?

The tool takes zero parameters, so there is no argument meaning to document; the baseline for a parameterless tool applies.

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

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

Specific verb ('List') plus resource ('installed board platforms/cores'), with an example format (arduino:avr) and the returned payload ('with versions'). The word 'installed' implicitly separates it from core-search, but no sibling is named, so an agent must infer that 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?

Usage is only implied: 'installed' suggests reaching for this rather than core-search or core-install, but there is no explicit when-to-use statement, no prerequisites, and no named alternative. Adequate but leaves routing to inference.

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

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

With no annotations, the description carries the full behavioral burden, yet it only says 'Search'. It does not disclose that this is a read-only lookup, whether it queries a remote package index/network, or what the result set looks like.

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 short sentence with the verb front-loaded and no filler. The inline examples duplicate the schema's example, which is slight redundancy but harmless.

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 tool with a fully documented schema and no output schema, the description is minimally adequate but omits what gets returned and how it relates to core-list/core-install workflows.

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

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

Schema description coverage is 100% and the single 'query' parameter is already documented with the same 'esp32' example. The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Search') and resource ('available cores in Boards Manager') with example terms, so the intent is immediately clear. It does not, however, differentiate itself from siblings like core-list or lib-search, which an agent must choose between.

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

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

No guidance on when to search versus when to list all cores (core-list) or how this differs from lib-search. Usage is only implied by the verb 'Search'.

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

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

Annotations already declare the key traits: not read-only, idempotent, non-destructive. The description adds the bulk scope behavior (omitting coreId upgrades everything), which is useful operational context, but says nothing about network access, failure behavior on individual cores, or what the response contains.

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 primary action comes first and the conditional modifier second.

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 single-optional-parameter tool whose annotations cover the safety profile and with no output schema to explain, the description is nearly sufficient. Only minor gaps remain around network/prerequisite expectations for a mutation 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?

With 100% schema description coverage, the schema already documents coreId including the omit-for-all semantics and an example value. The description merely restates that same rule without adding format or edge-case detail, so baseline 3 applies.

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

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

States a specific verb (Upgrade) and resource (installed cores), which implicitly distinguishes it from the similarly named lib-upgrade sibling by resource type. It is clear enough to select correctly, though it never names or contrasts the alternative to remove 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?

"Omit coreId to upgrade all" gives conditional behavior for the two modes but frames it as parameter usage rather than when-to-use guidance. It never says when to prefer this over core-install or lib-upgrade, so usage must be inferred from context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by enumerating what gets inspected (CLI, cores, libraries, boards, updates), which is more than the annotations convey, though it says nothing about output or how failures are reported.

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

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

Two sentences, front-loaded with the scope of the check followed by the usage trigger. No filler or redundant restatement of the 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 no-parameter, read-only diagnostic with no output schema, the description covers what is checked and when to run it, which is sufficient for correct invocation. A brief note on the shape of the result or follow-up tools would make it fully 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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies since the schema is empty and complete.

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 (health check) and resource (whole Arduino setup), then enumerates the diagnostic surface: CLI, cores, libraries, boards, pending updates. This clearly distinguishes it from the sibling list/install/compile tools, which each operate on one narrow resource.

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?

"Run first when anything behaves oddly" gives a clear trigger condition for invoking the tool. It does not name alternatives or exclusions, but the diagnostic-first framing is unambiguous enough that an agent knows when to reach for 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 readOnly=false, idempotent=true, destructive=false. The description adds useful context that it compiles a sketch and writes firmware artifacts into a folder, but does not disclose build duration, auth/toolchain prerequisites, or whether it overwrites existing files.

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 economical sentences: the action and artifacts come first, followed by the use cases. No filler, front-loaded correctly.

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 build-and-export tool with no output schema, the description adequately conveys what it produces and why an agent would pick it. It omits edge cases such as output collision or failure modes, but is otherwise sufficient 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 100%, so all five parameters are documented in the schema itself. The description only alludes to the folder destination and does not add format or syntax detail beyond the schema, so baseline 3 applies.

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

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

Specific compound verb (compile + export) with clear resource (firmware files .hex/.bin/.elf) and destination (a folder). The agent can distinguish this from the sibling 'compile' tool, which builds but does not necessarily emit exportable artifacts.

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 concrete use contexts: flashing with external tools, OTA updates, archiving builds. However, it does not explicitly contrast with the sibling 'compile' or 'upload' or state when-not to use it, leaving the boundary to inference.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that it reports needs and gaps, which is useful diagnostic context, but says nothing about output format or failure behavior beyond that. With annotations carrying the burden, 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?

Two tight sentences with the primary purpose front-loaded and the usage cue trailing. No filler, every clause earns its place.

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

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

For a read-only, single-parameter diagnostic tool with an output schema absent but a described result shape, the description covers enough to invoke it correctly. It could mention what a 'missing' result looks like, but nothing essential 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 100% and the single 'name' parameter already documents the optional pinning syntax ('AudioZero@1.0.0'). The description adds no parameter detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (Check) and resource (dependency status of a library) with a parenthetical clarifying the output (what it needs, what's missing). This clearly separates it from siblings like lib-list, lib-search, and lib-install, though it doesn't name 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?

Gives a concrete trigger: 'Run before compile when a library install seems incomplete.' That is a clear use context. It stops short of naming alternatives (e.g., lib-install) or stating when-not-to-use, so it's strong 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a use-case hint but no behavioral traits like filtering, sorting, or return format.

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

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

Three concise sentences, front-loaded with the core action, then parameter guidance, then a use-case tip. Zero waste.

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

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

For a simple read-only listing tool with one optional parameter and full schema coverage, the description is complete enough. It could mention output format or whether examples are paths, but that's minor.

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

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

Schema description coverage is 100% and the parameter is well-documented in the schema. The description adds an example ('Servo') in the schema but not in the description itself. Baseline 3 is appropriate.

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

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

States a specific verb (List) and resource (bundled examples for installed libraries) with clear scope. Does not explicitly differentiate from siblings like lib-search or lib-list, but the 'bundled examples' resource is distinctive enough.

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?

Clear usage context: 'Omit name to list examples for all libraries' and 'Great for finding starter code for a sensor/module' indicates when to use. No explicit alternatives or exclusions, so not a 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation/idempotency profile is covered. The description adds only the install source ('Library Manager'), which is modest extra context but no detail on side effects like dependency installation.

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 examples duplicate the schema's own example, which is the only slight redundancy.

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

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

For a simple three-parameter install tool with no output schema, the description is minimally adequate but omits useful context such as whether dependencies are pulled in by default (partly covered by noDeps) or what a successful install returns.

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

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

Schema description coverage is 100%, so name, noDeps and version are already documented with their own descriptions. The description's examples of library names add marginal value beyond the schema and nothing about version or dependency semantics.

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

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

The description states a specific verb and resource ('Install a library from Library Manager') and gives concrete examples, which distinguishes it from lib-list/lib-search/lib-upgrade. It does not explicitly name a sibling, so it falls 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 guidance on when to use this versus lib-search or lib-upgrade, nor any prerequisite about resolving a library name first. Usage is only implied by the name and verb.

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?

No annotations are provided, so the description must carry the full behavioral burden. It only states the tool's purpose and omits any details about read-only nature, permissions, output format, or side effects. The word 'installed' hints that it queries local state, but that is minimal transparency.

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

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

The description is a single, front-loaded sentence with no wasted words. For a simple list tool, it is appropriately sized.

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

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

The tool is simple, with one optional parameter and no output schema. The description states the purpose but does not describe the return value or the effect of the fqbn filter. With no annotations and no output schema, it could provide slightly more context to be fully complete.

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

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

Schema description coverage is 100%, so the single fqbn parameter is fully documented in the schema. The description adds no extra meaning about the parameter or its filtering behavior, which is acceptable given the schema baseline but not value-adding.

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 ('List') and resource ('installed Arduino libraries'), and the scope word 'installed' distinguishes it from sibling lib-search, which likely searches available libraries. However, it does not explicitly name or contrast with any alternative, so it falls short of the highest clarity 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?

There is no guidance about when to use this tool versus alternatives like lib-search or lib-deps. The sentence implies the basic use case, but it does not state conditions, exclusions, or alternative tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether this is a read-only lookup, whether it queries a remote registry, how many results are returned, or whether results are paginated — all relevant for a search tool.

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

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

A single compact sentence that front-loads the verb and resource. It is slightly padded by parenthetical examples that restate the schema example, but there is no wasted prose.

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 search with no output schema and no annotations, the description is minimally adequate but leaves the agent guessing about the return shape (list of libraries? metadata?) and result limits. It should do more given that nothing else covers behavior.

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

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

There is a single parameter and schema description coverage is 100%, so the baseline is 3. The examples in the description ('Servo', 'DHT sensor', 'WiFi') largely duplicate the schema's own example ('DHT sensor') and add no formatting or matching-behavior details.

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

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

States a specific verb ('Search') and resource ('the Arduino Library Manager'), which is enough to distinguish it from core-list or board-list. It stops short of explicitly differentiating from the closest sibling, core-search, so it is clear but not maximally 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?

Usage is only implied: an agent can infer this is for discovering libraries by name, but there is no explicit when-to-use vs lib-list, core-search, or lib-deps, and no note about what to do with the results (e.g. feed into lib-install).

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 (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description does not contradict them. It adds the useful behavioral detail that omitting name upgrades all libraries, but it does not disclose side effects like version replacement or dependency changes.

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 very brief and front-loaded: two short sentences convey the action and the key scope rule. It is appropriately sized for a tool with one optional parameter, though it sacrifices some contextual richness for brevity.

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 low-complexity tool with one optional parameter, complete schema coverage, and annotations covering idempotency and destructiveness, the description is largely sufficient. It lacks only explicit routing guidance relative to sibling tools and any note about the result of an upgrade.

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 parameter 'name' has 100% schema description coverage, and the description merely restates the same 'Omit for all' guidance. The description adds no meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific action ('Upgrade') and resource ('libraries'), and the additional 'Omit name to upgrade all' clarifies scope. It is clearly distinguishable from sibling tools like lib-install or core-upgrade because the resource and action are 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?

No explicit guidance is given about when to use lib-upgrade versus alternatives such as lib-install or core-upgrade. The only usage hint, 'Omit name to upgrade all,' addresses an invocation detail rather than selecting among sibling tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds meaningful behavioral context: it is a bounded snapshot, non-blocking, and returns only what arrived within timeoutMs. This goes beyond the structured annotations, though it could still clarify empty-result 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?

Three short sentences, front-loaded with the core action, and every sentence earns its place: the action, the intended use, and the key limitation. No filler or redundant restatement of 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?

For a simple snapshot tool with read-only, idempotent annotations and a fully described optional parameter set, the description is nearly complete. It explains the return concept ('what arrived within timeoutMs') despite there being no output schema, though it doesn't address edge cases like no serial data arriving or connection failures.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description references timeoutMs but adds little beyond what the schema states; baseline 3 is appropriate since the schema carries the parameter meaning.

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

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

The description states a specific action and resource: 'Read serial output from a board for a few seconds (non-blocking snapshot).' It also explicitly distinguishes itself from a live stream, which is the key sibling alternative, so an agent can tell it apart 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?

The description gives a clear use case ('Use for Serial.println debugging') and an explicit when-not: 'NOT a live stream.' It does not name the sibling tool (e.g., upload-and-monitor) as the alternative, so it falls just short of full alternative 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 already declare this a safe read-only, idempotent operation, so safety is covered. The description adds meaningful output semantics beyond the annotations: 'Empty output means everything is current,' which is valuable given there is no output schema.

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

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

Three short sentences, front-loaded with the core purpose and immediately followed by the output interpretation and next step. 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 zero-param read tool with no output schema, the description supplies the key missing piece (empty = current) and points at the upgrade follow-ups. It could note version/detail granularity of the output, but nothing required 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?

With zero parameters and 100% schema coverage there is nothing for the description to explain; a 4 baseline applies. No parameter-related gaps exist.

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 ('Show') and resource ('installed cores and libraries that have upgrades available'), so an agent immediately knows it surfaces outdated items. It does not explicitly distinguish itself from siblings like core-list or lib-list, which also enumerate installed items, so it falls 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?

It names the follow-up tools (core-upgrade / lib-upgrade) and the condition that triggers them, giving a usable workflow context. It stops short of stating when NOT to use it versus core-list/lib-list, so no explicit exclusions are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description usefully explains the output content (preprocessed source) rather than just repeating that it's a read, but says nothing about permissions or how this relates to the compile pipeline beyond 'instead of compiling.'

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: the first front-loads what the tool does, the second gives the use case. No wasted words.

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

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

For a simple read-only operation, the description covers purpose, output, and use case, and annotations carry the safety profile. The lack of an output schema is mitigated by the description stating that the preprocessed source is printed, though it could note whether output is streamed or returned.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds no parameter-level meaning (e.g., how fqbn or buildProperties affect preprocessing), so the baseline 3 is appropriate.

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

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

States a specific verb ('Print') and resource ('the preprocessed sketch source') and clarifies the transformation (macros expanded, headers resolved). It implicitly contrasts with 'compile' via 'instead of compiling,' though it doesn't name the sibling tool directly.

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 use case: 'debugging #define / conditional-compile issues.' This tells the agent when the tool is valuable, but offers no explicit exclusions or named alternatives for other debugging scenarios.

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

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

Annotations already declare write (readOnlyHint=false), idempotent, and non-destructive, so the safety profile is covered. The description adds only 'optionally including build artifacts', which merely restates the includeBuildArtifacts parameter and says nothing about overwrite behavior for an existing output zip or 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?

A single front-loaded sentence with the action first and the optional scope second. No wasted words.

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

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

For a simple three-parameter tool whose schema is fully documented, most of what an agent needs is present, and no output schema means return values need no explanation. However, the total absence of usage or prerequisite context leaves a gap for a mutation tool.

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

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

Schema description coverage is 100%, with each of the three parameters documented including the output default, so the baseline is 3. The description contributes no additional parameter meaning beyond what the schema already provides.

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

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

States a specific verb (zip) and resource (sketch), with the scope qualifier that build artifacts may be included. It does not differentiate from adjacent siblings like export-binary or preprocess, but the core action 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?

No when-to-use guidance, no prerequisites (e.g., must the sketch be valid first?), and no mention of alternatives such as export-binary. The agent must infer when archiving 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=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description usefully adds what actually gets created (folder plus boilerplate .ino), but says nothing about behavior when the path already exists or where the path is created relative to.

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 resource and its side effects are packed efficiently into one line.

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 one-parameter creation tool with annotations covering the safety profile and no output schema to explain, the description is nearly complete. The only gap is error/conflict behavior when the target path is occupied.

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 a single parameter with 100% schema description coverage, including a concrete example path, so the schema does the heavy lifting. The description adds nothing about the path format or constraints beyond what the schema already states, which fits the baseline 3 for full 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 and resource ('Create a new Arduino sketch') and enumerates the concrete artifacts produced (folder + .ino file with setup()/loop() boilerplate). This clearly distinguishes it from read/validate/archive siblings like sketch-validate and sketch-archive.

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 never states when to use this tool versus alternatives such as sketch-archive or compile, nor any prerequisites like whether an existing sketch folder would conflict. Usage is only inferable from the verb.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that it lists files and what it validates, but says nothing about the return format or failure behavior; with this annotation coverage, 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?

Two tight sentences with the action and the validated convention front-loaded, and the usage timing second. 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 single-param read-only validator with no output schema, the description covers what it checks, what it lists, and when to run it. Only a note on what a failed validation reports (or return shape) 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 description coverage is 100% and the single param already documents 'Path to sketch folder or .ino file'. The description's mention of the '<name>/<name>.ino' layout adds context but not new parameter syntax beyond the schema, so baseline 3 holds.

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') and resource ('sketch folder layout') and even names the exact convention it validates ('<name>/<name>.ino') plus the side effect of listing files. This is clearly distinguishable from siblings like compile, preprocess, and sketch-new.

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 tells the agent when to run it ('Run before compile to catch layout mistakes'), which is strong contextual guidance. It stops short of naming alternatives or when-not-to-use conditions, so it isn't a full routing instruction.

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=true, idempotentHint=true, so the safety profile is already covered. The description adds real value beyond that: it discloses the implicit compile step, the board-attach dependency for omitted params, and the port-contention failure mode with Serial Monitor. It doesn't describe post-flash board reset behavior or return output, but that's a minor gap against the annotation coverage.

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, each earning its place: the core action, the parameter-omission rule, and the critical precondition. Front-loaded with the primary action and no wasted words.

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

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

For a 7-parameter mutation tool with no output schema, the description covers the main preconditions, the implicit compile behavior, and parameter defaults. Residual gaps are small: no explicit statement about board reset after flash or the relationship to 'upload-and-monitor', but annotations carry the safety profile.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including the note that fqbn/port can be omitted if set via board-attach. The description's mention of that same omission rule adds an explanation of why (saved via board-attach), but no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States specific verbs and resources: compile-if-needed and flash a sketch to a connected board. This is clearly distinguishable from the sibling 'compile' (compile only) and implies a superset operation. It doesn't explicitly name 'upload-and-monitor' as the alternative, so sibling routing is only partially spelled out.

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 concrete usage context: fqbn/port may be omitted when previously set via board-attach, and a hard precondition that Serial Monitor must be closed because it holds the port lock. It stops short of an explicit when-to-use-this-vs-'upload-and-monitor' comparison, which is the nearest ambiguous 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 the write/destructive/idempotent profile, so the description only needs to add process detail — and it does, disclosing the ordered sequence (upload, wait for reboot, then serial capture). It does not mention permission/auth needs or that existing firmware is overwritten, which the destructiveHint largely covers.

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 compact sentences, front-loaded with the value proposition before the mechanics. Every clause earns its place with no repetition of schema data.

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 8-parameter composite tool with no output schema, the description conveys the full flow and result type (serial output) succinctly. It could be slightly richer about what the returned snapshot looks like or failure/timeout behavior, but nothing needed to invoke 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 description coverage is 100%, so the parameters (including baudrate requirements, monitorMs bounds, and board-attach fallback for port/fqbn) are fully documented in the schema. The description adds only the general notion of a serial snapshot and no extra parameter syntax or defaults, so the baseline 3 applies.

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

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

The description names a concrete verb+resource pair ('Flash a sketch', 'captures a serial snapshot') and states the composite scope ('Uploads, waits for the board to reboot, then captures'). This implicitly separates it from the sibling pair 'upload' + 'monitor-snapshot', though neither alternative is named outright.

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 usage context via 'one call from new code to visible result', telling the agent this is the shortcut when a serial reading is wanted right after flashing. It stops short of explicit when-not guidance (e.g., 'use plain upload when you don't need serial output').

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