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

No annotations are provided, so the description carries the burden, and it does disclose useful behavior: timeout spans from code transmission to Raw REPL return completion, and the return surface (ok, path, bytes_written, error) is described. It does not state whether a missing file is created, what happens on partial writes or disk-full, or any permission/precondition requirements.

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

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

The Args/Returns/Notes layout is clear and front-loaded, but the content/content_base64 exclusivity is stated twice (inline on each param and again in Notes), which is redundant. Reasonably sized overall but with avoidable 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?

A mutation tool with no annotations, but the description compensates by documenting parameters, the exclusivity constraint, timeout semantics, and the return fields. Missing only edge-case behavior (file creation on missing path, error conditions), which an agent would want for a safe append operation.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: all five parameters are explained (path, content, timeout, encoding, content_base64) with an explicit mutual-exclusion rule between content and content_base64. It does not specify encoding failure behavior or valid encoding names, but the core semantics are covered.

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+resource: appending content to a file on a MicroPython board (「MicroPython ボードのファイルに内容を追記する」). The append semantics are unambiguous. However, it does not explicitly distinguish itself from the sibling micropython_write_file, which is the main ambiguity an agent would face.

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 append versus write_file, upload_file, or exec. The only usage-adjacent statement is the parameter exclusivity between content and content_base64, which is parameter semantics rather than a when-to-use rule. Usage is left to inference from the verb alone.

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

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

The Notes section discloses sha256-based comparison, and the Returns section reveals it returns both hashes and a same flag. No annotations are provided, so this level of detail is valuable. It doesn't mention error handling beyond the generic error field, but it does note the timeout covers the entire Raw REPL round-trip.

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

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

Well-structured with sections for Args, Returns, and Notes. Slightly verbose because it restates parameter names in the Returns, but each section adds useful information.

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

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

Given no annotations, three parameters at 0% schema coverage, and an output schema present, the description does a good job covering purpose, constraints, method, and return shape. It could add error cases or prerequisite states, but is otherwise complete for a comparison utility.

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 does so for all three args, including a key constraint not in the schema: local_path is restricted to the workspace. The timeout semantics (whole round-trip) are also clarified.

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 purpose: comparing whether a local file and a device file match. Distinguishes itself from siblings like micropython_hash_file and micropython_upload_file by being explicitly a comparison operation, not a hash or transfer.

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

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

The description implies usage (verify that a local file matches its device counterpart) but doesn't give explicit when-to-use guidance or name alternatives like micropython_hash_file for one-sided hashing.

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 does disclose the useful behavioral fact that the target format selects the transport (COM3 → serial, host[:port] → WebREPL), but says nothing about failure behavior, whether an existing connection is replaced, or idempotency.

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 purpose line followed by a compact Args block; it is front-loaded and free of filler. Nothing extraneous, though it could be marginally richer without bloating.

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

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

An output schema exists, so return values need not be described. However, for a stateful connect operation with no annotations, the definition leaves connection lifecycle questions (already connected, retries, failure modes) unanswered.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains the target string format per transport and the purpose of password (WebREPL) and baudrate (serial). It omits the defaults (baudrate 115200, password null), which are in the schema, so it is not fully exhaustive.

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?

It states a clear verb+resource ('connect to the specified target'), so an agent knows this establishes a MicroPython connection. It does not, however, explicitly distinguish itself from siblings like micropython_disconnect or micropython_connection_status beyond the obvious verb difference.

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 no explicit when-to-use guidance, no prerequisites (e.g. must be called before eval/exec), and names no alternatives. An agent can infer that connecting precedes other operations, but nothing is stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It enumerates return fields (connected, transport, target, host, port, baudrate, error) which usefully discloses that transport is either 'serial' or 'webrepl' and that failures surface via an error message — but it says nothing about side effects, auth requirements, or whether this has any cost when disconnected.

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

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

Front-loaded one-line purpose followed by a compact field list. Every line earns its place; no preamble or filler.

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

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

A zero-parameter status read with an output schema present, so the description does not need to explain return values — and in fact its field listing partially duplicates the output schema. What remains missing is only the light when-to-use framing, which for this simple tool 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 the baseline is 4. Nothing in the description needs to compensate for a parameter gap.

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

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

States a specific verb+resource: '現在の接続状態を返す' (returns the current connection status). It is clearly distinguishable from connect/disconnect/eval siblings by its read-status nature, though it never explicitly names a sibling to route against.

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 infers 'call this to check whether you're connected before issuing commands.' There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives such as micropython_get_info or micropython_list_ports.

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 supplied, so the description carries the full disclosure burden. It never states that deletion is irreversible, what happens if the path does not exist, whether the board must be connected, or what error conditions exist — all important for a destructive operation.

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

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

Two lines: the action first, then the argument with an example. Every element earns its place and nothing is 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?

An output schema exists, so return values need not be described. However, for a destructive tool with no annotations, the definition omits connection prerequisites and failure behavior, leaving it only minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate for the lone parameter, and it does: it names the argument, identifies it as the file path, and gives a concrete example format ('/test.py'). That is genuine added meaning over the bare string 'Path' in 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+resource ('delete a file on the MicroPython board'), which clearly separates it from directory-oriented siblings like micropython_remove_dir or micropython_rename_path. It does not explicitly name an alternative, but the 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 context, no prerequisites (e.g. an active connection), and no pointer to alternatives such as micropython_remove_dir for directories. The agent must infer the correct circumstances entirely on its own.

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 burden and does disclose a genuinely useful edge case: it returns success even when not already connected, which signals effectively idempotent behavior. It also lists the return fields. It stops short of saying what happens to board state or whether an active connection is required.

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

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

The core action and the key edge-case caveat are front-loaded in two short lines, followed by a compact return-value block. Every sentence earns its place with no padding.

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

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

For a simple zero-parameter action with an output schema covering return values, the description is essentially complete: what it does, its behavior when disconnected, and its returns. It could add one note on the effect on board/session state, but nothing needed 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?

The tool takes zero parameters, so there is nothing for the description to clarify beyond what the empty schema already shows; baseline 4 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 (disconnect) and resource (current MicroPython board connection), which cleanly distinguishes it from the sibling micropython_connect. It does not explicitly name an alternative, but the verb is unambiguous and scoped to the active connection.

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 by the verb – an agent can infer this is how you close a session, but there is no explicit 'use when/when-not' guidance or reference to alternatives such as micropython_connection_status to check state first. The one conditional statement concerns behavior, not when to call 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?

With no annotations, the description carries the full behavioral burden and does well: it explains timeout scope, overwrite behavior, workspace restriction, and success/failure return semantics including sha256 being None on failure. It still omits some operational details such as connection prerequisites and atomicity.

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

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

The description is front-loaded with the core action and then structured into Args and Returns sections. It is concise overall, though the Returns block is partly redundant because an output schema exists.

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 four-parameter file-download tool with no annotations and no schema descriptions, the description covers the essential parameters and return fields. Since an output schema exists, the explicit Returns section is not strictly required, but the definition remains complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It documents remote_path, local_path with a workspace constraint, timeout with its precise scope, and overwrite behavior, adding substantial meaning beyond the bare schema names.

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 first sentence states a specific verb and resource: saving a file from a MicroPython board to the local host. It clearly distinguishes this from sibling tools such as micropython_upload_file and micropython_read_file.

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 the tool is for downloading files, and it notes that local_path must be within the workspace. However, it does not explicitly state when to use this tool versus alternatives like micropython_read_file, micropython_upload_file, or micropython_compare_local_remote.

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 discloses the success/error return shape, but does not explain side effects, safety constraints, timeout behavior, connection requirements, or what happens if the evaluated expression mutates board state.

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

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

The definition is compact and front-loads the purpose, followed by structured Args and Returns sections. The Returns section duplicates information already present in the output schema, which is a minor inefficiency, but the text remains clear and 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 parameter and an output schema, and the description covers purpose, argument meaning, and return fields. However, with no annotations and no usage guidelines or safety context, an agent lacks guidance on when to choose this tool over siblings and what behavioral risks exist.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter. It explains that 'expression' is the Python expression to evaluate and provides examples such as '1 + 1' and 'machine.freq()', adding useful meaning beyond the schema's bare type and title.

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 a specific verb and resource: 'evaluate an expression on a MicroPython board and return the result as a string.' It distinguishes the operation from general execution in spirit, but does not explicitly name or differentiate itself from sibling tools such as micropython_exec.

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

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

The description provides no guidance on when to use this tool versus alternatives like micropython_exec or other execution-related siblings. It only documents the argument and return fields, leaving context selection entirely 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 bears the full burden, and it does disclose some useful behavior: the timeout spans the whole send-to-Raw-REPL-return cycle, and the return fields (ok/stdout/stderr/error) are spelled out. However, it says nothing about state persistence between calls, side effects on the device, or permission/environment requirements, which are important for an arbitrary-code-execution 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?

The Args/Returns/Example structure is front-loaded and easy to scan, with each block earning its place. It is slightly verbose in restating return fields that an output schema already covers, but nothing is wasted or confusing.

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 an output schema exists, the explicit Returns section is redundant but harmless; the description is otherwise complete enough to call the tool correctly. The one meaningful gap is the absence of any sibling routing against micropython_eval.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: 'code' is described as Python code that may be multi-line, and 'timeout' is precisely defined as the total seconds from send to Raw REPL return with a 10s default. This meaningfully compensates for the empty schema.

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

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

The description states a specific verb ('実行する' / execute) and resource ('MicroPython インタープリタで Python コード'), and notes multi-line support. It's clear what the tool does, but it never distinguishes itself from the sibling micropython_eval, which an agent could easily confuse with 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer this over micropython_eval or micropython_reset. The only hint is a capability note ('multi-line code also supported'), which is not usage 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?

No annotations exist, so the description carries the full burden. It usefully enumerates the fields that may appear in info (platform, version, free_mem, fs_free_kb, etc.), which is real added context. However, it omits whether a connection is required, whether it blocks, and any permission/cost considerations for a hardware round-trip.

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 one-line Japanese purpose is well front-loaded, but the Returns block restates fields that an output schema already exposes, and the Notes list is somewhat sprawling across many short lines. Some of that structure duplicates structured data rather than earning 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?

With an output schema present, explaining return values is not strictly necessary, yet the Notes on info contents do add value beyond it. The description is nonetheless incomplete on operational context: no mention of a required connect step, connection failure behavior, or relationship to micropython_connection_status.

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

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

The tool takes zero parameters and the schema is fully described, so per the baseline convention a 4 is appropriate. There is nothing parameter-related for the description to add or omit.

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+resource: retrieving device information from the MicroPython board. That resource is not shared by any sibling tool, so an agent can distinguish it. It does not, however, explicitly differentiate itself from the nearest adjacent tool (micropython_connection_status).

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

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

There is no statement of when to call this versus alternatives, no prerequisite (e.g. an active connection via micropython_connect), and no exclusions. Usage is only implied by the tool's nature as a read-only getter.

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. It discloses that the algorithm is currently limited to sha256, which is useful. However, it doesn't mention whether the board must be connected, how the hash is transported from the device, or what happens on failure. The timeout parameter is described in terms of the raw REPL cycle, giving some operational context.

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

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

The description is concise and front-loaded with the purpose, followed by an Args section that cleanly documents each parameter. No superfluous text. Slightly structured as docstring-style, which is appropriate.

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

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

Given that an output schema exists (so return value need not be explained), the description covers the essential purpose and parameters. It could mention board connection prerequisites or error handling, but for a straightforward hashing tool it is largely 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 provides meaning for all three parameters: path is the target file, algorithm is limited to sha256 currently, and timeout is the overall timeout for code submission to Raw REPL completion. This adds valuable context beyond the bare 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 explicitly states a specific verb+resource: 'MicroPython ボード上のファイルのハッシュを返す' (return the hash of a file on the MicroPython board). It clearly distinguishes itself from siblings like read_file, stat_path, or download_file by the hash-returning operation.

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

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

The description implies usage (compute a file's hash) but doesn't specify when to use this versus alternatives like reading the file locally and hashing, or how it differs from stat_path. No explicit when/when-not guidance or alternative suggestions 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?

No annotations exist, so the description carries the full behavioral burden. It does disclose useful traits like the truncated flag, error reporting, and the precise meaning of timeout (from code send to Raw REPL return), but it omits prerequisites such as needing an established connection to the board and any side effects or rate constraints.

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

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

The Args/Returns structure is front-loaded and readable, but the Returns block largely restates fields already provided by the output schema, adding length without new 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?

Parameter coverage is adequate and the output schema exists so return fields needn't be re-described. However, for a board-interaction tool with no annotations, the description should mention connection prerequisites and how it relates to sibling read tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains all five parameters, including the default-implied semantics of lines (max returned lines), timeout (whole-operation window ending at Raw REPL recovery), encoding, and errors handling. Only minor format details (e.g. valid encoding names) are missing.

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: returning the first N lines of a text file on a MicroPython board. It is a clear read operation, though it never explicitly distinguishes itself from close siblings such as micropython_read_lines, micropython_read_file, or micropython_tail_lines.

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

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

No when-to-use guidance is given. With adjacent siblings like micropython_tail_lines, micropython_read_lines, and micropython_read_file, the description should say when head-of-file is the right choice, but it leaves that entirely 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?

No annotations are provided, so the description carries the full burden. It discloses the mechanism (sending Ctrl-C) and the expected effect (interrupting processing), which is useful behavioral context. However, it doesn't state whether the interruption is graceful, whether state is preserved, what happens if no process is running, or what the output contains. Some behavioral transparency is present but significant gaps remain.

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 is front-loaded with the core action. No unnecessary words or structure.

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 (no parameters, output schema exists), so the description doesn't need to explain return values. However, for an interrupt operation with no annotations, more context about behavior (e.g., what gets interrupted, whether it's safe, effects on connection state) would help an agent use it correctly. The description is adequate but leaves notable gaps.

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

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

The tool takes zero parameters, so parameter semantics are not applicable. Baseline 4 is appropriate for a parameterless tool.

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 (send Ctrl-C) and its effect (interrupt running processing). An agent can distinguish this from siblings like micropython_reset or micropython_disconnect, though the description could more explicitly differentiate from reset (soft interrupt vs hard 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?

No guidance on when to use this tool versus alternatives like micropython_reset or micropython_disconnect. The description implies it stops a running process but doesn't say when this is preferable to a full reset. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a non-mutating read, but it says nothing about error behavior for nonexistent paths, whether the listing is recursive, or any permission constraints.

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

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

Two short lines, the operation is front-loaded, and the parameter note follows immediately. 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?

An output schema exists, so return-value details are not required. The description covers the one input parameter and the operation's scope, which is adequate for a simple listing tool, though it omits any behavioral caveats that would help an agent call it confidently.

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%, but the description documents the single parameter and clarifies that it expects a directory path and defaults to '/'. With only one optional parameter this is sufficient, though the added meaning is modest beyond the schema's own title and default.

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 (files/directories on the MicroPython board filesystem), which clearly separates it from siblings like micropython_read_file or micropython_stat_path. It does not explicitly name alternative tools, so it falls short of the 5 benchmark.

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 other listing/inspection tools (e.g., micropython_stat_path), no prerequisites, and no exclusions. The default path hints at typical usage but the description never states context or alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it adds nothing beyond the name: it does not say whether the listing probes hardware actively, whether it is read-only/safe, whether it can block or time out, or what the returned entries contain. For a zero-argument discovery call this is a low but non-zero disclosure 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?

A single short sentence with the resource front-loaded and no filler. It is appropriately sized, though it leaves obvious room to add a routing clause without becoming bloated.

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

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

With an output schema present and no parameters, the description need not explain return values or argument formats, and the operation is inherently simple. Its only shortfall is the absence of any hint about how it relates to the connect/disconnect/status siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool applies. Schema coverage is effectively 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 and resource (list available serial ports), so an agent immediately knows what the tool returns. It does not, however, distinguish itself from nearby siblings such as micropython_connection_status or micropython_connect, which also concern ports/connections.

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 no when-to-use guidance, no prerequisite conditions, and names no alternative. An agent must infer on its own that this is the discovery step that precedes micropython_connect, and nothing says what to do if no ports are listed.

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 usefully explains that parents creates parent directories and exist_ok permits existing directories, but it omits required connection state, error behavior when exist_ok is false, and other failure modes for a mutation tool.

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

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

The description is front-loaded with the core action and then cleanly lists arguments without unnecessary prose. Every sentence earns its place.

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

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

An output schema exists, so return values need not be described. The description covers the key parameters for this simple mutation tool, though it could better address connection prerequisites and error conditions.

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 0% schema description coverage, the description fully compensates by documenting all three parameters: path for the directory to create, parents for recursive creation, and exist_ok for tolerating existing directories. It adds clear meaning beyond the bare schema names and defaults.

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: creating a directory on a MicroPython board. It is clear and distinguishable from sibling tools like remove_dir or rename_path by name, but it does not explicitly contrast itself with alternatives.

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

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

The description provides no when-to-use guidance, prerequisites, or alternatives. It only describes the operation and its arguments, leaving usage context to inference from the tool name.

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?

アノテーションが皆無のため説明文が挙動開示の全責任を負うが、読み取り専用であること、必要な接続状態、失敗時の挙動（部分的読み取りなど）には触れていない。timeout が「コード送信から Raw REPL 復帰完了まで」という点と as_base64 の切り替え挙動は有用な追加情報だが、全体としては不十分。

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?

Args セクションは簡潔で構造化されているが、Returns セクションは出力スキーマが既に存在するため冗長で、説明文の役割としては重複している。全体として無駄が多い。

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?

5 パラメータで出力スキーマもある中、パラメータ説明は完備している。しかしアノテーションなしにもかかわらず利用条件や兄弟ツールとの関係が欠けており、エージェントが正しく呼び出すための文脈としては最小限。

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?

スキーマ説明カバレッジが 0% なので説明文が全パラメータを補う必要があり、path の例示、timeout の意味、encoding、errors、as_base64 の挙動をすべて説明している。5 パラメータすべてに意味が与えられており、スキーマを超えた価値がある。

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

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

「MicroPython ボードのファイルを読み出して返す」は明確な動詞＋リソースで、何をするかは一目でわかる。ただし download_file、read_lines、head_lines、tail_lines など類似の兄弟ツールとの使い分けには一切触れておらず、汎用読み出しである点の差別化がない。

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?

いつ使うべきか、いつ使うべきでないか、どの代替ツールを選ぶべきかの記述が一切ない。download_file や read_lines との関係が不明なため、エージェントは選択に推測を要する。

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, but it only says it reads a file and returns it. It discloses nothing about connection state requirements, what happens if /HARDWARE.md is absent, or whether the read is safe/idempotent — a meaningful gap for a device-facing 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?

Two short lines, purpose front-loaded, then the Arg definition with no filler. Every sentence earns its place.

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

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

An output schema exists, so return values need not be described, and the tool is simple (one param). What is still missing is the relationship to the many sibling read tools and any precondition about the device connection, which the agent must guess.

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 does: the sole 'timeout' parameter is explained as the overall seconds from code transmission through Raw REPL return completion, which is real semantic meaning beyond the bare 'integer' in the schema.

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

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

The description states a specific verb and resource: read /HARDWARE.md on the device and return it. That is unambiguous. However, it never distinguishes this from the sibling micropython_read_file, which would presumably also read an arbitrary path, so an agent cannot tell why this specialized tool exists.

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

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

There is no when-to-use guidance at all: no statement of prerequisites (must be connected?), no condition selecting this over micropython_read_file, micropython_read_lines, or micropython_head_lines. The agent must infer usage entirely from the tool name.

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 useful behavior: the timeout covers the entire code-send through Raw REPL return, and decoding is configurable via encoding/errors. It does not state that the operation is read-only, that a connection must be established, or what happens on decode/missing-file failure beyond the generic error field.

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 purpose sentence is front-loaded, followed by compact Args and Returns blocks where each line earns its place. The Returns block partially duplicates the existing output schema, which is mild waste but not disruptive.

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

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

For a 6-parameter tool with no annotations, every input is documented and the return contract is spelled out, including eof semantics for continued reads. The remaining gap is sibling routing — nothing tells the agent why to pick this over head_lines/tail_lines or read_file.

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 there are 6 parameters, so the description must compensate — and it does, defining each argument's meaning, including the critical detail that start_line is 1-based and that timeout is a total wall-clock budget. It adds real value over bare titles like 'Path' or 'Max Lines', though it omits default values already present in 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 and resource: partial line-based reading of a text file on a MicroPython board. The scope ('行単位で一部') is clearer than a generic file read, but it never names or differentiates itself from siblings like micropython_read_file, micropython_head_lines, or micropython_tail_lines, which overlap heavily.

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 statement of when to choose this over micropython_read_file, head_lines, or tail_lines, and no prerequisites such as an active connection or board-mounted file. The agent must infer the use case from the purpose line alone.

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

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

With no annotations provided, the description carries the full burden and does add real behavioral context: duration caps the read, idle_timeout triggers early termination on inactivity, and exceeding max_bytes yields truncated=True. It doesn't state permissions or blocking behavior, but the timeout/truncation semantics are genuinely 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?

Structured Args/Returns layout is front-loaded with the action sentence first, and each entry earns its place. The Returns block partly duplicates the output schema, but it still conveys useful semantics efficiently.

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

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

Parameters are fully explained and the output fields are described, which is more than sufficient given an output schema exists. The only real omission is context on how this read tool relates to its numerous siblings.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: all three parameters are explained (duration=max seconds, idle_timeout=early-exit threshold, max_bytes=truncation limit) with the observable consequence of max_bytes spelled out. This meaningfully exceeds the bare schema.

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

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

The description states a specific verb+resource: reading stream output from the connected device for a bounded time. This is clear, but it never distinguishes itself from the many read-oriented siblings (micropython_read_until, micropython_read_lines, micropython_read_file, micropython_exec), so an agent cannot tell which read tool applies without opening 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?

There is no when-to-use guidance and no exclusions. Given ~10 sibling read tools, the definition gives no signal for choosing read_stream over read_until or read_lines, leaving selection entirely 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 disclosure burden. It does reveal useful behavior – that it blocks waiting up to `timeout` seconds, reads at most `max_bytes`, and reports `matched`/`error` – but omits prerequisites (active connection), whether output is lost or partial on timeout, and streaming semantics.

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

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

The one-line purpose is front-loaded, followed by cleanly separated Args and Returns sections. No filler, though the return-value block partly duplicates the output schema.

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

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

For a blocking read with a 0%-covered parameter schema, the description adequately covers purpose, all three params, and expected outputs. Since an output schema already exists, its return documentation is surplus but harmless, and the definition is complete enough to call correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it clarifies `pattern` is a plain substring not a regex, `timeout` is max waiting seconds, and `max_bytes` is the byte cap. This meaningfully exceeds the bare schema titles.

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 ('接続中のデバイス出力を...読み取る') plus a distinctive condition ('指定文字列が現れるまで'), which differentiates it from plain reads like micropython_read_stream. It does not explicitly name or contrast a sibling, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus the many alternatives (read_stream, read_lines, read_file, exec, etc.). The reader must infer the use case (blocking wait for a marker) entirely from the purpose line.

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 discloses one important constraint – that the directory must be empty – but says nothing about whether deletion is recursive, what error occurs on a non-empty or missing path, required board state, or durability of the operation.

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

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

Two short lines with a clear Args block and zero filler; the core action is front-loaded in the first sentence. Efficient for a single-parameter 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?

An output schema exists, so return values need not be explained, and an agent can infer basic usage from the name and single required path. However, with no annotations and no schema descriptions, the definition leaves the destructive/error semantics of this mutation undocumented.

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 has to convey parameter meaning. It does explain that path identifies the directory to delete, marginally adding to the bare 'path' name, but it offers no format, relative-vs-absolute, or examples. Adequate but thin for a 0%-coverage parameter.

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 (空ディレクトリ on a MicroPython board), with the 'empty' qualifier implicitly separating it from file deletion or directory creation. It does not name siblings, but the file-vs-directory and empty qualifiers let an agent distinguish it from micropython_delete_file and micropython_make_dir.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The word '空' (empty) hints at a precondition but the description never says what to do for non-empty directories or how it relates to delete_file / make_dir.

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, and it says nothing about overwrite semantics when dst exists, permission/connection requirements, error behavior, or whether the operation is atomic or reversible. 'rename/move' implies mutation but discloses no operational traits beyond that.

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 purpose line is front-loaded and the Args block is minimal, with no filler. It is appropriately sized for a two-parameter operation, though the boilerplate 'Args:' listing is somewhat schema-redundant.

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

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

An output schema exists, so return values need not be described, and with only two self-evident parameters the description is nearly complete. The gap is behavioral: for a mutation tool with zero annotations, the description omits overwrite rules and failure conditions an agent would want before invoking it.

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% (properties have only bare titles 'Src'/'Dst'), so the description must compensate, and it does: it defines src as the move source path and dst as the destination path. That fully maps both parameters, though it adds no format/syntax detail (relative vs absolute paths).

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

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

States a specific verb pair (rename/move) and resource (a path on the MicroPython board), which is unambiguous and clearly distinct from siblings such as write_file, delete_file, or make_dir. It does not, however, explicitly contrast itself with related file operations, so it stops short of 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?

There is no guidance on when to use this versus alternatives such as upload_file, download_file, or delete_file + write_file. It doesn't state prerequisites (e.g., whether dst's parent directory must exist or whether dst may already exist). Only the implied 'move something' context is present.

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. It usefully discloses that the board is soft-reset (machine.reset()) and that reconnection is required afterwards, which is the key operational consequence. But it omits other material effects — that the running program and RAM state are lost, whether it is safe to call mid-execution, and how this differs behaviorally from a hard reset or interrupt.

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 lines: the first names the operation and its exact equivalent, the second front-loads the critical post-condition. Nothing is wasted and the most important fact (you must reconnect) is not buried.

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 an output schema, the description covers what the agent needs to act: what it does and the state it leaves the connection in. The remaining gap is sibling differentiation, particularly against micropython_reset_and_capture, which the description never addresses.

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

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

The tool takes no parameters, so there is no parameter semantics to document; the baseline of 4 applies. Nothing in the description conflicts with the empty schema.

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

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

The description states a specific verb ('soft reset') and resource ('MicroPython board') and even pins the semantics to machine.reset(), which removes ambiguity about what kind of reset this is. It does not, however, differentiate itself from the sibling micropython_reset_and_capture or micropython_interrupt, so the agent must infer which reset variant to pick.

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

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

It gives one implicit usage signal — 'reconnection is required afterwards' — which tells the agent the connection will be lost and must be re-established. There is no explicit when-to-use guidance and no mention of alternatives such as reset_and_capture or interrupt, leaving the selection between reset siblings 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?

No annotations provided, so the description carries the load. It discloses the truncation behavior, early termination on idle, and separate ok/reset_ok/error fields, which is useful behavioral context. However, it doesn't note side effects of the reset (e.g. state loss on the device) or whether reconnection is needed.

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

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

Front-loaded one-line summary followed by concise parameter and return documentation. No filler; every line carries information.

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

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

An output schema exists, so return-value documentation isn't strictly needed, yet the description provides it directly. Combined with full parameter semantics, the definition is nearly self-sufficient; missing only explicit usage guidance vs siblings.

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

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

Schema coverage is 0%, so the description must compensate. It defines all three parameters meaningfully: capture_duration as max read seconds, idle_timeout as early-exit threshold, and max_bytes with its truncation consequence. Minor gap: no defaults specified for the optional params.

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

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

States a specific compound verb and resource: resets the device AND reads startup output for a duration. Clearly distinguishable from siblings like micropython_reset (reset only) and micropython_read_stream (read only).

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 purpose implies when to use it (capture boot output), but no explicit when/when-not guidance or alternative routing to micropython_reset + read_stream is given, despite many relevant siblings existing.

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 lists return fields and an error field, but does not state that the operation is read-only, how symlinks or permissions are handled, or any other safety-relevant trait beyond basic stat semantics.

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

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

Front-loads the purpose and uses a clean Args/Returns structure. It is appropriately sized, though the Returns block is somewhat redundant given that an output schema exists.

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 stat tool with an output schema, the core invocation details are present. However, missing usage guidance, parameter format details, and behavioral safety disclosure leave notable gaps.

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

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

Schema description coverage is 0% for the single path parameter. The description only says 'path: target path', which essentially restates the parameter name and adds no format, relative/absolute path, or constraint information.

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+resource: getting path information on a MicroPython board. It implies metadata rather than file contents, but does not explicitly distinguish itself from siblings like micropython_read_file or micropython_list_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?

No when-to-use or when-not-to-use guidance. It does not name alternatives such as list_files for directory listing or read_file for contents, leaving the agent to infer when stat 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?

No annotations are provided, so the description carries the full behavioral burden. It does add real value by explaining that timeout spans code transmission through Raw REPL return and by declaring a 'truncated' flag for dropped leading lines, but it says nothing about connection state requirements, failure/recovery behavior, or whether the read is non-destructive.

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

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

Front-loaded one-line purpose followed by structured Args/Returns blocks; each entry is a single clause with no filler. The Returns block partially duplicates the existing output schema, which is the only 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 five-parameter file-reading tool with an output schema and no annotations, the description covers the arguments and return shape adequately, but the complete absence of routing guidance against the many read/list siblings leaves a real gap for agent selection.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: all five parameters (path, lines, timeout, encoding, errors) receive a short gloss. The explanations are terse and omit valid value ranges or the meaning of 'errors' modes, but they prevent the parameters from being opaque.

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: returns the last lines of a text file on a MicroPython board. An agent can distinguish it from micropython_read_file and micropython_head_lines by the 'tail' concept, but the description never names or contrasts those siblings explicitly.

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

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

There is no when-to-use guidance: nothing says when tailing is preferable to micropython_read_lines, micropython_head_lines, or micropython_read_file, and no preconditions (e.g. connection must be established) are stated. Usage is only inferable from the tool name.

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 and does disclose useful traits: local_path is restricted to the workspace, overwrite=False suppresses clobbering, and timeout covers the whole send-to-Raw-REPL-return cycle. It stops short of stating connection prerequisites, side effects on the remote device, or failure/recovery behavior for a mutating operation.

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

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

Front-loaded purpose sentence followed by clean Args/Returns blocks; every line maps to a real parameter or return field. Slightly over-inclusive in restating returns that an output schema already covers.

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

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

For a write tool with no annotations, the definition covers purpose, all parameters, and outcomes, which is enough to invoke it correctly. It could add the connection prerequisite and the upload-vs-download/write sibling boundary, but nothing critical 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 0%, so the description must compensate, and it documents all four parameters with meaning beyond their names — including the workspace-only constraint on local_path and the exact semantics of the timeout window. Only minor formatting/default nuances are absent.

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 direction (転送/transfer) plus both endpoints (local host file → MicroPython board), which is clear at a glance. It does not, however, distinguish itself from close siblings like micropython_download_file (reverse direction) or micropython_write_file, so the agent must infer the boundary.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The agent is left to infer that this is for bulk transfer versus micropython_write_file/append_file, and nothing states prerequisites such as an active connection.

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 does disclose the key destructive behavior (overwrite) and defines the timeout as covering code transmission through Raw REPL return, which is genuinely useful operational context. It omits permissions/auth needs, whether parent directories are created, and partial-write 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?

Nicely front-loaded: purpose first, then Args/Returns/Notes. Every section earns its place, though the Notes line duplicates the mutually-exclusive constraint already in the Args entry for content_base64, which is minor 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?

An output schema exists, so the Returns block is partly redundant, but the Args coverage is complete for a 5-parameter tool with 0% schema description coverage. The mutual-exclusion rule is the one thing an agent could easily get wrong, and it is stated twice, making the definition operationally complete despite no annotation coverage.

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%, but the description compensates well by documenting all five parameters, including the crucial mutual-exclusion between content and content_base64, restated in Notes. However, it doesn't give an example of base64 usage or clarify encoding only applies to content, and the schema's anyOf/null defaults are left unexplained.

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

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

States a specific verb+resource in 'MicroPython ボードのファイルに内容を書き込む（上書き）', and the parenthetical '(上書き)' (overwrite) immediately distinguishes it from the sibling micropython_append_file. An agent can separate write from append without opening either schema.

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

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

The overwrite semantics imply when this is appropriate versus append_file, but no tool is named and there is no explicit 'when to use / when not to use' guidance. It also doesn't tell the agent to verify a path exists or to use micropython_upload_file for binary blobs. Usage is implied rather than stated.

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