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

With no annotations provided, the description carries the full burden and does so well: it discloses that it stops the currently running program, describes timeout behavior (interrupts on timeout), and explains how output is surfaced in Thonny. No contradictions.

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

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

The description is concise and front-loaded with the core action, then adds necessary behavioral details and alternative routing. Every sentence earns its place, and it avoids redundant boilerplate.

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 that runs code and returns output, the description covers the return behavior (prints and tracebacks), the interruption and timeout mechanics, the side effect of stopping the current program, and points to alternatives for infinite loops. 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 0%, but the description compensates fully: it explains `timeout` with default (10), max (300), and its effect (interruption), and `code` is self-explanatory from the context. Both parameters gain meaning beyond the schema.

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

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

States a specific verb (Run) and resource (MicroPython code on the board), and explicitly differentiates from siblings by noting that for long-running programs the user should use `start` + `monitor`. It also clarifies the output (prints and tracebacks), making the purpose unmistakable.

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 explicit when-to-use and when-not-to-use guidance: use for code that should run and finish, and for infinite loops route to `start` + `monitor`. It also notes the tool stops the currently running program first, which is a key contextual condition.

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

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

The description discloses a significant behavioral trait: it stops the currently running program. This is beyond what annotations provide (none are given). It also lists the exact data returned, which helps the agent anticipate the output. However, it doesn't mention whether the stop is graceful, whether it can be resumed, or if there are any side effects beyond stopping the program.

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

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

The description is concise and front-loaded: it starts with 'One-call board fact sheet' and then lists the specific data points. The critical warning about stopping the program is placed at the end, which is a slight issue, but the overall length is appropriate and 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 tool with no output schema, the description is quite complete. It tells the agent what data it will receive and warns about the side effect. The only gap is that it doesn't specify the format of the output (e.g., JSON, text) or whether the program stop is reversible, but given the tool's simplicity, this is adequate.

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

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

The tool has zero parameters, so the description doesn't need to explain parameter semantics. The description fully compensates by explaining what the tool does and what it returns. Since there are no parameters, the baseline is 4, and the description meets that by being self-contained.

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

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

The description clearly states the tool's function: it provides a one-call board fact sheet with specific data points (firmware, board name, CPU MHz, RAM, flash, unique id, Wi-Fi state, root files). It also explicitly notes a side effect: 'Stops the program currently running.' This distinguishes it from sibling tools like 'status' or 'info' by specifying the exact resource and content.

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

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

The description implies when to use it: when you need a quick board overview. It does not explicitly state when not to use it or name alternatives, but the detailed list of what it returns makes the usage context clear. The side-effect warning ('Stops the program currently running') is a critical usage guideline, though it could be more explicit about avoiding it while a program is running.

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 behavioral burden. It usefully discloses that the tool sends Ctrl-C and may escalate to Stop/Restart in Thonny, but it does not mention side effects, failure modes, or whether this resets the board or only interrupts the running program.

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 that is front-loaded with the verb and object, adds the mechanism and escalation in a compact parenthetical, and contains no filler or repetition.

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

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

For a zero-parameter action with no output schema, the description gives the action, target, and behavior well enough to invoke correctly. The main gap is lack of selection guidance against reset or run, but that is a minor omission for such a simple 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?

There are no parameters planned, so the usual parameter-semantics burden is absent. The baseline for zero parameters is 4, and the description does not need to clarify any 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: stop the program running on the board. It names the concrete mechanism (Ctrl-C) and the escalation path, which clearly identifies this as an execution-interruption tool rather than a generic reset or run command.

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 about when to use this tool versus siblings like reset, exec, or start. There are no conditions, exclusions, or alternative selectors; the agent is left to infer the right context from the tool name and minimal description.

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

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

The description discloses recursive behavior and output includes sizes and free space. However, with no annotations, it does not explicitly state read-only status, potential side effects, or performance implications, leaving part of the behavioral profile unspecified.

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 is concise and front-loaded with the key action. However, it omits essential parameter information, making it efficient but not optimally structured for agent comprehension.

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

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

For a simple tool with one optional parameter and no output schema, the description could be sufficient if it explained the parameter. It does not, so an agent cannot reliably know how to specify a path or interpret results, leaving the description incomplete.

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

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

The schema has one parameter 'path' with a default but no description. The tool description does not mention 'path' at all, so the parameter's meaning and valid values are completely unexplained. With 0% schema coverage, the description fails to compensate, leaving the agent without any guidance.

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

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

The description clearly states the action ('list files') and the resource ('on the board') with specific details (recursive, sizes, free space). It does not explicitly contrast with sibling tools like 'info' or 'read', but the purpose 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent is left to infer its applicability without any context.

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

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

With no annotations provided, the description carries the full burden and does well: it explicitly states 'Never interrupts it' and 'just listens to the board's console,' disclosing the read-only, passive nature. It also explains the timeout behavior with 'returns early if it ends,' adding useful behavioral detail beyond the bare schema.

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

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

The description is two efficient sentences that front-load the main purpose and then clarify non-interruption and standalone use. Every clause adds value, with no filler or repetition.

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

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

For a simple one-parameter tool with no output schema, the description covers purpose, usage context, parameter semantics, and key behavioral traits. It does not mention edge cases such as what happens when no program is running, but the essential information for correct invocation is present.

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

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

The schema gives only a type for seconds with no description, so the description compensates by defining its meaning: 'for up to `seconds` (default 5, returns early if it ends).' This adds a default value and behavioral guarantee, though it could also clarify constraints like minimum or maximum values.

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

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

The description opens with a specific verb and resource: 'Read what the running program prints.' This clearly identifies the tool as a console-output listener and distinguishes it from siblings like start, exec, and run_file, which initiate execution, and read, which likely reads files.

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

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

The description gives clear context for when to use the tool: to observe output without interrupting the running program, and notes it works even when Thonny is closed for main.py running standalone. It does not explicitly name alternative tools or state when not to use it, so it stops 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?

There are no annotations, so the description must carry the burden of transparency. It discloses that Thonny must be running and that the file is opened in the editor, but it does not cover failure behavior, whether the file must already exist, or effects on an active editor session.

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

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

A single sentence with no filler. It front-loads the action and resource, then adds the necessary precondition compactly.

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

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

For a one-parameter tool with no output schema, the description names the target, the local file source, and the main precondition. It omits failure-mode details, but the operation is simple enough that the description is likely sufficient for an agent to invoke it correctly.

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

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

The schema has no descriptions (0% coverage), so the description must compensate. It clarifies that path refers to a file on the local computer, but it does not specify absolute vs. relative paths, file type restrictions, or handling of missing files. For a single obvious path parameter this is minimally adequate.

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 'Open' with a clear resource 'a file from the computer' and destination 'Thonny's editor'. The phrasing distinguishes it from sibling tools like read (content retrieval) and run_file (execution).

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

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

Provides the essential prerequisite 'Thonny must be open' and implies the intended use case: opening a local file in Thonny's editor. It does not name alternative tools explicitly, but the context is clear enough.

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?

There are no annotations, so the description must disclose behavioral details on its own. It conveys a read-only intent, but it does not describe the return value, effects, permissions, or failure behavior.

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

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

The description is one focused sentence with no filler. It is concise and front-loaded, though it could be somewhat richer without becoming verbose.

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

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

With no annotations and no output schema, the description should clarify expected outcomes. It names the action but leaves the actual file contents/return behavior and path semantics to inference, making it minimally viable rather than 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 description must compensate. It adds only the minimum context that 'path' refers to a file on the board; it does not explain path format, accepted file types, or how the path maps to the board's filesystem.

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

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

The description clearly names a specific verb ('Read') and resource ('a file stored on the board'), so the core operation is immediately understandable. It does not explicitly differentiate from sibling tools like 'open' or 'info', so it misses the top score.

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 usage context is provided. The description does not say when to prefer 'read' over siblings such as 'open', 'info', 'ls', or 'write', nor does it mention any prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It is transparent about the core effect: the board reruns boot.py and then main.py. It does not mention whether files are preserved or what the return/output looks like, but the core behavior is clearly 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?

One short sentence with the key behavior front-loaded and a parenthetical that removes ambiguity. No filler or redundant content.

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

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

For a zero-parameter utility that simply restarts execution, the description contains everything an agent needs to understand what will happen. No output schema is expected, and the behavior is fully described in context.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameter meaning, and the empty schema matches the tool's simple invocation.

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 ('soft-reset') and the exact resource ('the board'), with a clarifying parenthetical about what happens (boot.py then main.py run again). It clearly distinguishes reset from siblings like interrupt, start, and run_file by defining its behavior.

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 intended use is implied: call this when you want to restart the board's Python execution. However, it does not explicitly state when to use reset versus alternatives like start or interrupt, nor does it mention any exclusions or prerequisites.

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 disclose the full behavioral impact. It mentions recursive deletion, which is helpful, but omits whether the deletion is permanent, reversible, requires confirmation, or what happens on failure. For a destructive tool this is a significant transparency gap.

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

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

The description is a single sentence that is front-loaded and contains no fluff. Every word contributes to the core purpose, and it is appropriately short for such a simple operation.

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

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

For a destructive operation with no annotations and no output schema, this description is under-specified. It lacks irreversible-action warnings, usage guidance, and any note about return values or error behavior. A competent agent could invoke it with a path, but it would not understand the full consequences of doing so.

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

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

The schema only defines 'path' as a string with no description. The description adds that the target can be a file or folder, giving some semantic meaning to the parameter. However, it does not specify path format (absolute/relative), trailing slash expectations, or directory-tree behavior beyond 'recursively'.

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 ('Delete') and resource ('file or folder') and adds a clarifying scope ('on the board') plus recursive behavior. This clearly differentiates it from siblings like ls, read, write, or exec, which describe different operations.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or cautionary warnings. While 'delete' is self-explanatory as an operation, the description does not say 'use when you want to remove files/folders' or mention when not to use it, leaving usage context entirely implicit.

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?

There are no annotations, so the description carries the full burden. It adds useful behavioral details: the file is not saved to the board, the path is project-relative, and the timeout defaults to 30 seconds. However, it does not disclose side effects of executing arbitrary code, output behavior, or how timeout interacts with execution.

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 entire description is one sentence, front-loaded with the core action and followed by necessary qualifiers. It is compact, readable, and contains 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 simple two-parameter tool, the description covers the key invocation details: what file to run, where the path is relative, that it is not saved, and the default timeout. It omits guidance on execution side effects and output, but given the low complexity it is adequately 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 description must compensate. It adds meaning to 'path' by specifying it is relative to the project directory and clarifies 'timeout' with a default unit and value. This is helpful but does not fully describe timeout semantics or other constraints.

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 ('Run'), a specific resource ('.py file'), and a precise mode ('from the computer on the board without saving it there'). It clearly distinguishes itself from siblings like exec or start by emphasizing that the file is not persisted on the board.

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 context is clear: use this tool to execute a Python file from the project directory without saving it to the board. It does not explicitly name alternatives or provide when-not-to-use conditions, but the stated scope is sufficient for most selection 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?

With no annotations, the description carries the full burden. It does disclose that the operation is a read, returns the tail of the shell, and requires Thonny to be open. It does not disclose failure behavior, whether max_chars truncates the returned text, or the exact return format, so transparency is incomplete.

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 sentence with no filler. The primary action is front-loaded, the clarification adds value, and the prerequisite is included. Every part 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 simple single-parameter read tool, the description captures the core function and the key precondition. However, there is no output schema and no annotation, and the description does not explain the return format or behavior when Thonny is not open, leaving moderate uncertainty.

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

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

The schema has one optional parameter, max_chars, with 0% description coverage, and the tool description never mentions it. The phrase 'end of ... shell' only vaguely implies a bounded read, so the description adds almost no parameter meaning; the self-explanatory name and default value keep this from being a 1.

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

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

The description names a specific verb ('Read'), a specific resource ('Thonny's shell'), and a scope ('the end'), then clarifies with 'what the user sees'. This is enough to distinguish the tool from generic siblings like 'read' and the other IDE commands without opening their schemas.

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 prerequisite ('Thonny must be open') and implies the tool is for viewing user-visible shell output. However, it never states when to prefer this over alternatives such as 'monitor' or 'read', nor does it give any when-not-to-use guidance.

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

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

With no annotations, the description carries full behavioral disclosure. It reveals that the tool launches asynchronously, returns output from the first `wait` seconds, and stops any currently running program first – a critical destructive side effect. It also implies the process continues running in the background. This is comprehensive for a process-launch tool and leaves no major surprises.

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 deliver all essential information with no filler. The purpose is front-loaded, and each clause adds value: async behavior, parameters, return value, follow-up tools, and the stop-current-program caveat. This is model of concise, information-dense writing.

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

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

Given no output schema, the description explains the return value (output from first wait seconds) and the lifecycle (monitor, interrupt). It also notes the preemptive stop of the current program. Missing details like error handling or behavior when no program is running are minor for a tool of this complexity; the description gives an agent enough to call it correctly and manage the process.

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 explain all parameters. It does: `code` and `path` are introduced as alternatives ('pass code, or path'), and `wait` is defined as the number of seconds for initial output capture with a default of 1.5. It doesn't specify edge cases like supplying both code and path, but the core semantics are clear. Slight deduction for not noting mutual exclusivity or validation behavior.

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 (launch), a clear resource (a long-running program via code or path), and explicitly distinguishes its asynchronous nature ('WITHOUT waiting for it to end') from synchronous alternatives. It also names the follow-up tools (monitor, interrupt) and the precondition (stops currently running program), making its role unambiguous among siblings.

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

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

The description clearly indicates when to use this tool (for long-running programs like robot main loops and sensor logging) and guides the agent to complementary tools (monitor for reading output, interrupt for stopping). It doesn't explicitly name alternatives like exec or run_file or state when NOT to use it, but the context is strong enough that a capable agent would infer the distinction. A small gap is the absence of an explicit exclusion for short-lived programs.

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 discloses what the status report includes and implies a read-only diagnostic action, but it does not explicitly state safety, side effects, or what happens when no board is connected.

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 entire description is one front-loaded sentence that packs the key purpose, the reported details, and a usage recommendation without wasted words. The phrasing is slightly awkward, but every element 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, low-complexity status tool, the description is adequate: it names the connection modes (Thonny or direct serial) and the reported details. There is no output schema, but the description covers what the agent needs to decide to call the tool; it could add a note on failure indicators.

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 are zero parameters and schema coverage is 100%, so the description need not clarify inputs. It adds value by describing what sort of information the tool returns, which is the only semantic content an agent needs 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 states that the tool reports how the board is currently reached, listing concrete details (interpreter, port, state, action-approval requirement). This is a clear diagnostic-resource statement, though it does not explicitly distinguish itself from the sibling 'info' tool.

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 direct usage cue: 'Call it first when unsure.' This tells an agent when to invoke it, though it does not specify when not to use it or name alternative tools for different connection questions.

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 provided, the description carries the full behavioral burden. It discloses key side effects (soft reset, main.py restart), default paths, force/upload-all behavior, and dry-run reporting. It doesn't cover return values or error handling, but the core behavior is well exposed.

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 front-loaded sentences convey the main operation, defaults, and every option without waste. Every clause adds useful information for selecting and invoking the 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?

The description is rich enough for correct invocation: it specifies default folders, flag behavior, and the restart side effect. Minor gaps remain around expected output/return values and error behavior, but no output schema exists to fill that 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?

Schema description coverage is 0%, so the description must compensate. It explains force, reset, dry_run, and remote_dir defaults, and implies local_dir via 'default src'. This gives meaningful semantics for nearly all parameters, though local_dir isn't explicitly named.

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 identifies a specific verb and resource: upload a project folder to the board. It further clarifies the mechanism (SHA-256 delta sync) and the post-sync reset, making it clearly distinct from siblings like run_file, write, or reset.

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 context is provided: this is the tool for syncing a local project folder to the board and restarting main.py. It doesn't explicitly name alternatives or state when not to use it, but the intended deployment scenario is unambiguous.

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. It does disclose one non-obvious behavior, that parent folders are created automatically, but it does not state whether an existing file is overwritten, what errors can occur, or what the operation 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 filler; the main action comes first and the important side effect is briefly added in parentheses. 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 mutation tool with no annotations and no output schema, the description is thin: it omits overwrite semantics, path format assumptions, and any indication of return or error behavior. The parent-folder note helps but does not make the definition 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% and the description does not explicitly define path/content, but 'text file' implies content is text and the parent-folder note adds meaning to path. This marginal compensation is enough for a very simple two-parameter schema.

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

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

The description states a specific action and resource: 'Write a text file on the board'. It is easily distinguished from sibling tools like read, ls, and rm, and the parenthetical parent-folder behavior adds useful scope.

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

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

No guidance is given about when to choose write over alternatives, nor are any exclusions or prerequisites stated. The description only says what the tool does; when to use it is left entirely to inference.

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