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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses little beyond the word "terminate." It does not say whether the session can be resumed, whether buffered output/history is discarded, whether this is irreversible, or whether closing the active session is safe.

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 that front-load the purpose before the argument note. The "Args:" block is mild boilerplate, but nothing here is wasted.

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. However, for a destructive, zero-annotation, single-parameter mutation tool, the description should state at least whether the termination is permanent and what happens to session state; that gap is only partially offset by the parameter default note.

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%, yet the description compensates by explaining the single parameter's purpose and its default behavior ("defaults to active session"), which the schema only expresses as default: null. This is meaningfully more than the schema alone conveys.

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 plus resource ("Close and terminate an interactive session"), which is immediately actionable. It does not differentiate itself from siblings like switch_session or spawn, so an agent must infer the boundary on its own.

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. With siblings such as switch_session and list_sessions present, the description never says why an agent would close a session instead of switching away from it, leaving the routing decision 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 important behavior: automatic prompt waiting, terminal stream preservation, ANSI stripping, timeout reporting, and the structured return fields. It does not clearly state permission requirements, side-effect/reversibility risks, or security implications of executing arbitrary commands, leaving a meaningful gap for a shell-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 description is front-loaded with the core purpose, then a clearly marked behavioral caveat, return fields, and parameters. It is slightly verbose because it repeats return fields that an output schema already provides, but every section is easy to scan and the warning is appropriately prominent.

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, 0% schema description coverage, no annotations, and an output schema, the description is largely complete. It covers purpose, timeout behavior, long-running alternatives, terminal output handling, and parameter meanings. It could be stronger by clarifying side effects and session permissions, but it provides enough for an agent to call the tool 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. It explains each parameter: command is the command line to execute, prompts are optional prompt patterns defaulting to standard shell/REPL prompts, timeout is the maximum seconds to wait for the prompt, and session_id targets a session defaulting to the active one. It does not specify the expected prompt-pattern syntax or repeat the schema default timeout of 8 seconds, but it gives usable meaning for all four parameters.

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

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

The description states a specific verb ('Execute') and resource ('shell, REPL, or bootloader command') and adds the key behavior of waiting for a prompt to return. It clearly distinguishes the tool from siblings like send and read_buffer, which are named in the usage warning.

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 by naming send and read_buffer for long-running commands and explicitly warning not to use exec_expect for commands that may take more than a few seconds. The condition that triggers the alternative (long-running commands) is stated unambiguously.

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 delivers the key trait that this is an 'Atomic' operation plus polling semantics (poll_cmd repeatedly sent, poll_interval default). It does not describe what happens on timeout (error vs. empty return), though the presence of an output schema offsets part of that gap.

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

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

The summary sentence is front-loaded and the Args block is scannable, with every line earning its place. There is minor duplication where defaults are restated (timeout 10.0s, poll_interval 0.05s), which the schema already encodes.

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 six-parameter, interaction-heavy tool this covers the operation, poll behavior, session targeting, and every argument, and an output schema exists so return values need not be re-explained. Only failure/timeout semantics and explicit sibling routing remain unaddressed.

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: each of the six parameters is explained with meaning, example values ('password:', '# ', ' ' for autoboot), and defaults. The session_id note ('defaults to currently active session') adds semantics the bare schema cannot express.

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 opening sentence gives a specific verb+resource ('send an optional command and match incoming stream against prompt patterns') and the 'Ideal for' clause scopes it to multi-step auth and U-Boot interception, which implicitly separates it from siblings like send or read_buffer. It stops short of naming a sibling or stating what it is not, so it is clear but not fully differentiated.

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?

'Ideal for multi-step authentication (SSH login/password), prompts, and U-Boot interception' supplies concrete use-case context that tells the agent when this tool applies. There are no explicit exclusions or named alternatives (e.g., when to prefer exec_expect or send instead), so guidance is clear but incomplete.

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?

Without annotations, the description carries full burden and does well: it explains the wall-clock timestamp format, the 50ms split-detection heuristic, continuation-line tagging ('↳ '), and the effect of with_timestamps=False. It does not state permissions or whether history is mutable, but these are less central for a read operation. Strong behavioral disclosure overall.

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 detailed behavioral notes and a concise Args section. It is somewhat verbose on timestamp mechanics but every sentence conveys distinct, 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?

For a 3-parameter read tool with an output schema (so return format need not be explained), the description covers purpose, parameter meaning, and timestamp/continuation behavior thoroughly. Only the absence of annotation-level safety context 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?

Schema description coverage is 0%, so the description must compensate—and it does: it explains limit (count of recent lines), with_timestamps (attaches timestamps/continuation symbols vs raw text), and session_id (defaults to active session). It adds clear semantics beyond the bare schema types.

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 (Retrieve) and resource (recent chronological line history) with clear scope ('captured by the background daemon'). The distinction from sibling read_buffer (buffer content) is implicit via 'chronological line history' but the tool's identity as a history-retrieval tool 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?

Implies usage context through defaults and the session_id parameter, but provides no explicit when-to-use versus alternatives like read_buffer or exec_expect. No when-not-to-use guidance 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 burden, and it does clarify that both physical and virtual ports are returned. However, it says nothing about whether the call is read-only, how results are ordered, or whether it can fail, which for a zero-arg listing is a modest but real 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 front-loaded sentence with no filler. Every word contributes to identifying the verb, the resource, and the scope.

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 (zero params, zero nesting) and an output schema exists, so return values need not be described. The description is sufficient for correct invocation, missing only usage context that would help routing.

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 are no parameter semantics to explain; the baseline of 4 applies. Nothing in the schema is left ambiguous by the 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 ('Enumerate') and resource ('physical and virtual serial ports on the host'), which is clearly distinct from session-oriented siblings like list_sessions or switch_session. It is precise about scope (host-attached, both physical and virtual), though it does not name an alternative by name.

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 or alternatives are given. An agent can infer it is a discovery step before opening a port, but nothing in the text states that or points to a related tool such as serial or list_sessions.

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 burden. It discloses that results are limited to 'active' sessions and include a health status field, and the read-only nature is implied by 'List', but it says nothing about pagination, ordering, permissions, or whether inactive/terminated sessions are excluded.

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

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

A single front-loaded sentence with no filler; the scope ('all active') and the returned value ('runtime health status') are both stated immediately.

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 listing tool with an output schema present, the description covers the essentials and need not document return fields. The only shortfall is absent guidance on when to use it versus the sibling introspection 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify about arguments, and it correctly refrains from inventing any.

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 specific verb ('List') and a well-defined resource ('all active PTY and Serial sessions'), plus the payload characteristic ('runtime health status'). That is enough to separate it from siblings such as list_ports, get_history, or status, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer you call this to enumerate currently live sessions. There is no statement of when to prefer it over status, get_history, or list_ports, and no exclusions or prerequisites given.

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 itself. It usefully discloses the non-blocking contract and that 'clear' mutates buffer state, but says nothing about behavior when no new text is available (empty return vs. error) or about invalid session IDs. An output schema exists, so return-format details are not 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 behavior is front-loaded in a single tight sentence, followed by a compact Args block. No filler, though the Args restatement is somewhat formulaic.

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, non-destructive read tool with an output schema, the description covers purpose, blocking semantics, and both parameters adequately. The main omission is behavior on an empty buffer, which an agent would benefit from knowing when polling.

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 do the work, and it does: it explains that 'clear' flushes the buffer after fetching and that 'session_id' defaults to the currently active session. Both parameters gain meaning not present in the bare schema types.

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 ('Read newly accumulated text from the stream buffer') and adds a differentiating behavioral qualifier ('without blocking') that sets it apart from blocking read siblings like expect/exec_expect. It is clear about scope but never names a sibling explicitly, so it stops short of full differentiation.

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 implied rather than stated: 'newly accumulated' and 'without blocking' suggest a polling use case as opposed to a blocking wait or a get_history call for past data. There is no explicit when-to-use or when-not-to-use guidance relative to the many sibling read/wait tools.

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

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

No annotations are provided, so the description carries the full burden. It explains the raw character handling and escape sequences, which is helpful, but doesn't disclose side effects, authentication needs, rate limits, or what happens if the session doesn't exist. It also doesn't mention return behavior, though an output schema exists.

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 a clear statement followed by parameter explanations. However, the parameter list is somewhat redundant given the input schema, but since coverage is 0%, it's necessary.

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 (sending raw input to sessions) and the lack of annotations, the description covers the basics but omits important behavioral details like what happens on success/failure, session state requirements, and potential side effects. The output schema exists, so return values needn't be explained.

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 documents all three parameters: text (with escape sequence examples), send_enter (appends newline), and session_id (defaults to active session). This fully covers the parameters and adds meaning 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 states a clear verb+resource: 'Send raw characters or escape sequences' to a session. It distinguishes itself from siblings like spawn or expect by focusing on raw input. However, it doesn't explicitly rule out other sending tools like exec_expect.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The agent must infer that this is for sending raw input to an already-spawned session, but no alternatives or conditions are mentioned.

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

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

With no annotations, the description carries the full behavioral burden and falls short: it does not say whether connecting creates a persistent session that must later be closed, whether the port is held exclusively, or what happens on a busy/invalid port or when baudrate is wrong. The device-type examples add useful domain context but no operational 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?

A single front-loaded purpose sentence followed by three terse, example-bearing argument lines. Nothing is padded and the most important information (what it connects to) comes first.

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

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

The output schema means return values need not be described, and parameters are covered. But for a stateful connect operation surrounded by 11 session-related siblings, the description is silent on the session model (creation, switching later, closing) and on port discovery, which is what an agent most needs to sequence calls 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% (titles and defaults only), so the Args block does real work: it explains port as a device path with platform-specific examples ('/dev/ttyUSB0', 'COM3'), baudrate with typical values, and name as an optional friendly identifier for the session. This compensates well for the coverage gap, though it omits the practical defaults already encoded 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 clear verb+resource: connect to a hardware or virtual serial device, with concrete device categories (UART / router console / microcontroller) that disambiguate the otherwise vague tool name 'serial'. It does not, however, differentiate itself from siblings such as spawn, list_ports, or switch_session, so an agent gets the action but not the routing.

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: it never says to call list_ports first, nor how this relates to switch_session/close_session/session lifecycle. There are no stated prerequisites or alternatives, so the agent must infer usage entirely from the sibling list.

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 says 'persistent interactive process in a PTY', which hints at lifespan and interactivity, but discloses nothing about permissions, resource limits beyond defaults, what happens on failure, or cleanup behavior for a long-lived process.

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 core action in the first line, then lists args compactly. Formatting is slightly redundant (a docstring-style Args block) but every line 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 explained. Still, as a session-creating tool with no annotations and 0% schema coverage, the description leaves lifecycle and error behavior unexplained, making it only adequately complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does by explaining all six params (command default, name, cwd, env, rows, cols with defaults). However, it doesn't clarify formats, units beyond 'rows/cols', or why env/name matter, so the compensation is incomplete.

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 (spawn) and resource (persistent interactive process in a PTY) with example technologies. It distinguishes the create action from siblings like close_session and list_sessions, though it doesn't name a sibling that also creates sessions (if one 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?

No explicit when-to-use or when-not-to-use guidance. An agent must infer that 'spawn' is for creating sessions versus the other session-management siblings, but nothing states prerequisites or the conditions that select this over 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 present, so the description carries the full behavioral burden. It usefully discloses the three categories of information returned (health, buffer stats, daemon status), but says nothing about whether it is side-effect free, whether it requires a live connection, or what happens when the session is stale.

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 substantive sentence is front-loaded and earns its place. The trailing 'Args:' block is slightly heavy for a single optional parameter, but it is compact and does not bury the main point.

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 the one optional parameter is documented. The remaining gap is routing guidance within the sibling set, which is a usage concern more than a completeness one.

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

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

Schema description coverage is 0% and the schema only shows a nullable string with a null default. The description compensates by explaining the sole parameter's meaning and its default-to-active-session behavior, which an agent could not infer from the schema alone.

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

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

The description gives a specific imperative verb ('Check') and enumerates the concrete resources inspected: connection health, buffer statistics, and background daemon status. This is far more informative than the bare name 'status', though it never distinguishes itself from siblings like read_buffer or list_sessions that also surface buffer/session state.

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 tool versus alternatives, no prerequisites, and no exclusions. In a toolset with 11 siblings, that omission leaves the agent to guess whether status is a prerequisite check, a diagnostic, or a substitute for read_buffer.

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 implies a state mutation. It omits whether the previous active session is preserved, what happens on an invalid ID, whether permissions are required, or if the change is reversible.

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 is front-loaded in a single short sentence and the arg line is terse. The 'Args:' boilerplate is slightly formulaic but costs little.

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 state-changing tool with zero annotations and no usage context, the description is too thin. An output schema exists so return values need not be explained, but prerequisites, error behavior, and session-lifecycle relationships are 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% and the schema only titles the field 'Session Id,' so the description's 'Target session ID to make active' adds minor clarifying value. It still gives no format, sourcing, or validity constraints for the ID.

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: 'Switch the default active session.' An agent can tell this mutates session state. However, it never distinguishes itself from siblings like close_session or spawn, which also manipulate session lifecycle.

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 mention of alternatives. It does not say to first call list_sessions to obtain a valid session_id, nor how this differs from close_session or spawn.

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