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

With no annotations, the description carries the behavioral burden. It clearly discloses that this is a destructive discard operation and explains the side effect on subsequent reads. It does not mention potential limitations, but for a zero-parameter utility the key behavior is well covered.

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 sentences with no filler. The core action is front-loaded, followed by a concise practical tip, making it easy to parse quickly.

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, no-nested-schema tool with an output schema, the description fully covers what the tool does and when to use it. 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?

The tool has no parameters, so there is nothing for the description to explain beyond the schema. The baseline for zero parameters is 4, and the description adds appropriate context about why this no-parameter call is useful.

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 ('Discard') and resource ('any buffered received data'), making the operation unambiguous. It also clarifies what kind of data is dropped ('old echo, prior output, or syslog noise'), distinguishing it from read or send 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?

It explicitly states when to use the tool: 'right before sending a command so the next read starts clean.' It does not name sibling alternatives or exclusions, but the usage context is clear and actionable enough for an agent to select it appropriately.

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 does a good job: it explains that a background reader is started, reads never block Claude (due to the fixed polling interval), and warns about the `xonxoff` parameter swallowing binary bytes. It also notes that `timeout` is reserved for compatibility, which is important behavioral context. The only minor gap is that it doesn't explicitly state the background reader will keep reading indefinitely or how to stop it (though `disconnect` likely handles 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 description is well-structured and front-loaded with the core purpose first, followed by defaults and then parameter details. It is concise, with no fluff, and every sentence adds value. The use of bullet points and short sentences makes it easy to scan, and it avoids unnecessary repetition.

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

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

Given the tool's complexity (8 parameters, 1 required, varied use cases), the description is remarkably complete. It covers defaults, parameter semantics, edge cases (binary protocols, flow control), and the non-blocking behavior. With an output schema present and sibling tools listed, an agent has everything it needs to call this tool correctly without ambiguity.

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

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

Since schema description coverage is 0%, the description must compensate, and it does excellently. It explains each parameter in plain language, providing common values and guidance on when to change them (e.g., 'almost always 8' for bytesize, 'only turn on if the device's manual says so' for rtscts). It also gives real-world examples for the `port` parameter and detailed notes on `xonxoff` behavior. This adds substantial value beyond the schema.

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

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

The description clearly states the tool's purpose: opening a serial port and starting a background reader. It specifies the resource (serial port) and the action (open and start). It also provides essential default settings (9600 8N1) that distinguish it from other tools like `list_serial_ports`, which only lists ports.

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 this tool (when you need to establish a serial connection) and it references a sibling tool (`list_serial_ports`) for getting port names, which helps with the selection process. However, it does not explicitly state when NOT to use this tool or mention alternatives like `reconnect_last` for reusing a previous connection, which would be useful.

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

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

No annotations are provided, so the description must carry the burden. It clearly states the action and outcome, but does not disclose behavior such as error conditions when not connected or reversibility. For a simple close, this is acceptable but could be more explicit.

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 conveys the action and consequence with no 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?

Given the tool has no parameters and an output schema exists (though not described), the description is sufficient for an agent to know when to call it. It lacks details on error handling, but for a disconnect operation that is not critical.

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, so the description adds no parameter-specific information, but none is needed. The baseline for zero parameters is 4.

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

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

The description states a specific verb 'Close' and resource 'serial port', and adds the consequence of freeing it for other programs. This clearly distinguishes it from connect and reconnect_last, which are about establishing 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?

It implies usage when the serial port is no longer needed, by mentioning freeing it for other programs. However, it does not explicitly name alternatives or state when not to use it, though the purpose makes it obvious.

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 burden of behavioral disclosure. It discloses what the tool returns—system name, human description, and USB hardware id—and implies a safe, read-only discovery operation, though it does not explicitly state that it has no side effects.

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

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

The description is short, front-loaded with the core function, and every sentence adds value: what is listed, when to call it, and what the output is useful for.

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 parameterless discovery tool with an output schema, the description fully covers why an agent would invoke it, when to invoke it, and what the result enables. No essential guidance 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 input schema has zero parameters, so there is nothing to document. The description adds relevant context by explaining how the returned values are meant to be used, which is more than necessary for a parameterless call.

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 object: 'List every serial port the computer can currently see.' It clearly distinguishes this tool from siblings like connect, send_text, and read_available, which perform different operations on a chosen port.

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 explicitly tells the agent when to call this tool: call it FIRST when connecting to a device without an exact port name, or when a connection fails. It also frames the output as the port name to pass to `connect`, making the relationship to the primary sibling tool clear.

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

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

No annotations are provided, so the description carries the burden. It discloses the behavior of clearing the buffer and reading until prompt or idle, which is good. However, it does not mention side effects like clearing the buffer that might be unexpected, or any permission/connection requirements. It could be more explicit that this is a write/read operation and requires an active connection.

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 well-structured with a summary first, then detailed parameter explanations. It is concise for the complexity, but the parameter docs could be seen as verbose or could be streamlined into bullet points. Still, it is front-loaded with the key purpose and usage guidance.

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 has 4 parameters and an output schema (not shown in detail). The description covers the purpose, usage guidance, and parameter semantics adequately. However, it does not mention the return value format or error conditions, which might matter given the output schema exists. A short note on what the reply contains would improve completeness.

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 must compensate. It explains each parameter: data as command text, line_ending with examples and reference to send_text, prompt semantics (literal prompt vs idle), and read_timeout as overall wait. This goes beyond the schema's basic names, though it could elaborate more on edge cases or precise format requirements.

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 that the tool combines clearing the buffer, sending an ASCII command, and reading the reply, using the verb 'send' and resource 'command'. It distinguishes itself from sibling tools by combining operations, and the example commands ('show version', 'ID') make the purpose concrete.

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 explicitly explains when to use this tool vs alternatives. It says 'best for interactive CLIs' when a prompt is given and 'best for line-based rigs/CAT' when prompt is empty. It references send_text for line_ending details, guiding the agent to related tools for more specific behavior.

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 discloses that the tool transmits nothing, waits up to read_timeout for the first bytes, briefly settles to capture a full chunk, and returns everything buffered. It does not specify edge-case behavior when no bytes arrive or whether the buffer is cleared, but the main behavioral profile is transparent.

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 three concise, front-loaded sentences with no filler. The action is stated first, followed by when to use it, then duration and return behavior. Every sentence contributes distinct value, and it remains compact and readable.

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 covers what the tool does, when to use it, roughly how long it waits, and what it returns, and an output schema exists to describe the result shape. Remaining gaps are the unspecified timeout unit and lack of explicit behavior for an empty buffer after timeout, so it is mostly complete but not exhaustive enough for a perfect score.

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 coverage, the description must compensate for the read_timeout parameter. It does add behavioral meaning by explaining that read_timeout bounds the wait for the first bytes, which goes beyond the schema's title and default value 1. However, it fails to state the unit (seconds versus milliseconds), leaving an important semantics gap for callers, so compensation is only partial at best.

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 clear verb-resource statement: 'Drain and return whatever the device has sent, without transmitting anything.' The use cases list concrete scenarios, distinguishing read_available from siblings such as send_hex, send_text, clear_buffer, and read_until_prompt. It clearly identifies what the tool does and how it is distinct from sibling 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?

The description provides explicit use cases: unsolicited/streaming output such as syslog, GPS, sensors, rigs in auto-info mode, and binary replies after send_hex. It does not explicitly name when-not-to-use or compare against read_until_prompt as an alternative, so it stops short of full routing guidance, but the context is clear enough for an agent to make a sensible choice.

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 bears full responsibility for behavioral disclosure. It thoroughly explains the continuous reader, that output is returned up to and including the prompt, that trailing content remains in the buffer, and the echo-matching warning. This goes well beyond a basic 'reads until prompt.

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 well-organized with a summary sentence, context, a typical flow, and a clean Args section. Every sentence carries operational value; the length is justified by the amount of necessary guidance, with 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 tool with three optional parameters, no annotations, and an output schema, the description covers all necessary ground: prompt semantics, timeout behavior, regex mode, buffer mechanics, and a concrete usage example. The output schema exists, so not detailing return values is acceptable.

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 input schema has 0% description coverage, so the description compensates fully. Every parameter is documented with examples and edge-case guidance, such as the warning about matching the echo of the sent command and the regex example for hostname-style prompts. This adds substantial meaning beyond the bare schema properties.

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 precise statement: 'Read accumulated output until a prompt appears, or until timeout.' It names the resource (accumulated output) and the termination condition. The phrase 'This is the right tool for interactive CLI sessions' clearly positions it among siblings like read_available.

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 explicitly states when to use the tool: interactive CLI sessions such as routers, switches, and shells. It also explains the advantage over a fixed delay for multi-page outputs and provides a typical send_text/read_until_prompt flow. It does not explicitly name alternative sibling tools or list exclusion cases, but the usage context 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?

There are no annotations, so the description carries the behavioral disclosure burden. It discloses that the tool reuses previous session settings and, importantly, handles the no-remembered-settings case by directing the user to `connect`. It could add a bit more about failure behavior or side effects of reconnecting, but for a zero-parameter convenience tool this is solid.

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 short and efficient, with the core purpose in the first sentence and supporting usage guidance plus fallback behavior in the following sentences. Every sentence earns its place with no 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?

Given the tool's low complexity, zero parameters, and existence of an output schema, the description covers what an agent needs: when to use it, what it does, and what to do if no previous session exists. There are no obvious gaps 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?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds useful context by naming what settings are remembered (port and baud rate), even though no input is required.

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 reconnects to the most recently used port/settings from a previous session, which is a specific action with a defined resource. It also distinguishes itself from the sibling `connect` by explaining the fallback condition, so an agent can tell them apart.

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 explicitly says it is handy at the start of a chat so the user doesn't have to repeat the port and baud rate. It also names the alternative (`connect`) and specifies the condition when that alternative should be used instead.

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 of behavioral disclosure. It covers TX-only behavior, the fact that it does not read, that spaces in hex input are ignored, and the optional buffer-clearing behavior. It does not mention connection requirements or error outcomes, but the core side effects are well 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?

The description is compact and front-loaded: behavior first, then usage context, then parameter details. Every sentence adds useful information, and the example is valuable without bloating the text.

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

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

For a two-parameter tool with no annotations, the description is complete enough for an agent to invoke it correctly. It explains what the tool does, how parameters behave, what to do next, and which sibling tool to use for reading a binary response.

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 fully: hex_bytes gets a concrete format plus an example, and clear_buffer_first is explained as discarding buffered RX before sending. It even clarifies that whitespace handling, adding real semantic value beyond the raw 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 (send raw bytes as hex) and clearly distinguishes itself from sibling read tools by noting it writes to TX only and does NOT read. It also positions itself for binary protocols like Icom CI-V, making it impossible to confuse with send_text or the read tools.

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

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

The description gives explicit when-to-use guidance: use for binary protocols, especially CI-V. It also tells the agent to call read_available afterward to see binary replies and explicitly advises that read_until_prompt is usually not the right tool, which makes the routing decision clear.

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 covers it well: TX-only behavior, no read, echo behavior on interactive console, non-ASCII '?' substitution, line-ending semantics, and buffer discarding when clear_buffer_first is set. These are exactly the non-obvious behaviors an agent needs to know before invoking.

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 a one-sentence core purpose, followed by the actionable behavioral context and then a terse Args section. Every sentence either constrains behavior, provides an example, or explains a parameter—no filler or redundant restating of the schema.

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

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

The tool has no annotations and the description covers operational behavior, parameter meanings, edge cases, and follow-up reads. An output schema is present, so return-value documentation is not needed. Minor missing context includes behavior when the device is disconnected or when a command fails, but these are not essential 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%, but the description fully compensates: data gets concrete examples ('show version', 'FA014250000', 'ID') and the non-ASCII fallback (sent as '?'), line_ending gets exact values with CR/LF explanations and device guidance, and clear_buffer_first gets a precise behavioral definition. This is more valuable than a typical schema description.

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 ('Send an ASCII command to the device'), and immediately clarifies scope: 'Writes to TX only; does NOT read.' This clearly separates send_text from read-oriented siblings like read_until_prompt and read_available, and from send_hex for raw byte transmission. No ambiguity remains about what the tool accomplishes.

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 explicit follow-up instructions ('call read_until_prompt (or read_available) afterward') and clear guidance on when to use clear_buffer_first. It also points to send_hex as the alternative for raw bytes. However, it does not explicitly contrast with query_text, which appears to be the natural when-to-use-this-vs-that alternative for command/response exchange.

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 of behavioral disclosure. It states the tool reports state and settings, implying a read-only operation, but doesn't explicitly say it makes no changes. It also doesn't disclose whether it requires an active connection or what happens if the port is closed.

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

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

The description is a single concise sentence that front-loads the verb and resource, then lists the three reported aspects. Every word earns its place with no 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?

The output schema exists, so return values are presumably documented there. However, the description doesn't clarify whether the tool works without an active connection, which is a key contextual gap given the sibling tools include connect and disconnect. It also doesn't mention whether RX buffered is a count or bytes, though the output schema may cover that.

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 there is no parameter semantics burden. The description correctly focuses on what the tool reports rather than inputs. Baseline 4 is appropriate for a no-parameter 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?

The description uses a specific verb ('Report') and names the resource ('a port') plus the specific aspects covered: open state, settings, and RX buffered amount. It clearly distinguishes itself from sibling tools like connect, disconnect, and read_available, though it doesn't explicitly name them.

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

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

The description implies this is a diagnostic/status tool to check port state and settings, which is distinct from connect/disconnect or read operations. However, it doesn't explicitly state when to use it versus alternatives, nor does it mention prerequisites like needing an active connection.

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