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

With no annotations, the description carries the full behavioral burden. It states nothing about what happens on a failed assertion (raise an error? return a boolean? abort the session?) or about success output, which is the single most important behavior for an assert tool. The "buffer mode only" caveat is the only behavioral detail offered.

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

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

A single tight sentence with the assertion condition front-loaded and the mode restriction last. No filler, though the em-dash clause is doing a lot of unelaborated work.

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?

Since an output schema exists, return values need not be explained, and the description does state the mode restriction. However, for a zero-annotation, zero-schema-coverage assertion tool it leaves the failure behavior, coordinate conventions, and session parameter unexplained, so it is only minimally viable.

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 names `text` and implies row/col, but gives no coordinate semantics (0-based vs 1-based, screen vs buffer origin) and never mentions `session_id` at all. Three of four parameters are only implicitly acknowledged.

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

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

The description names a specific verb (assert) and the exact condition tested (`text` at (row, col)), which cleanly separates it from the weaker sibling assert_contains and from expect_text. It stops short of explicitly contrasting itself with those siblings, so it's clear but not fully self-differentiating.

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?

"buffer mode only" is a real usage constraint — it tells the agent this tool is not for screen-scraping assertions — but it is stated as a restriction without naming the alternative (e.g. expect_text / capture_screen) or explaining when buffer mode is the right choice. Usage is implied rather than directed.

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 failure behavior ('on failure includes a screen excerpt'), which is the key trait of an assertion tool, but says nothing about success behavior, whether it blocks/waits/polls, timeouts, or how failure is signalled to the agent (error vs. status flag).

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

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

A single tight sentence with the assertion condition front-loaded and the failure side-effect appended. No filler or 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 return-value documentation is not required. For a simple assertion tool that is adequate, but the two undocumented optional parameters and the absence of any annotation coverage or session/buffer semantics leave gaps an agent must guess at.

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% across three parameters. The description clarifies only `text` (the required match string); `session_id` (which session's screen is asserted) and `use_buffer` (an undocumented anyOf/null flag) get no explanation in either schema or description, leaving real ambiguity for a multi-session 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 verb and resource: assert that the current screen contains `text`. It is clearly distinguished from positional siblings like assert_at_position and get_screen_region, but it does not differentiate itself from the similar-sounding expect_text, which an agent would also consider for this task.

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 or when-not-to-use guidance, and never mentions the close alternative expect_text or any prerequisites (e.g. that a TUI session must be launched and active first). Usage is only inferable from the word 'assert'.

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 hints that output shape depends on mode ('buffer display in buffer mode, cleaned stream otherwise'), but never confirms this is a read-only, non-mutating operation, nor describes session prerequisites, error behavior, or how include_ansi interacts with the two output modes.

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 a parenthetical qualifier; no filler or repetition. It is efficient, though the brevity is partly under-specification rather than disciplined conciseness.

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, but for a zero-annotation, zero-parameter-documentation tool the description is too thin. It leaves mode selection, session targeting, and interaction of include_ansi with the output modes 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% across all 3 parameters, so the description must compensate. 'Buffer mode' loosely maps to use_buffer and 'cleaned stream' loosely to include_ansi, but session_id is never mentioned and the default/null semantics of use_buffer are 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 and resource ('Capture the current screen') and the parenthetical clarifies what the capture yields. It implicitly separates this from line/region siblings like get_line and get_screen_region by scoping to the whole screen, though it never names 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?

There is no explicit guidance on when to prefer this over get_screen_region, get_line, or get_cursor_position, nor any stated preconditions (e.g., an active session). The agent must infer usage purely 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?

Annotations are absent, so the description carries the full behavioral burden. 'Reap its process' usefully discloses that a backing process is terminated, which goes beyond the tool name, but it omits idempotency, behavior on an unknown/already-closed session, and whether termination is graceful or forced.

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

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

One short sentence with the effect front-loaded and no filler. Nothing is wasted or 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?

An output schema exists, so return values need not be described, but with no annotations and 0% parameter coverage the definition leaves the session targeting (including the 'default' value) and failure behavior entirely 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 for the single parameter and it does not mention session_id at all. The schema's odd default of 'default' is left unexplained, so an agent gets no help understanding which session is targeted.

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 ('Close') and resource ('a session'), plus a second effect ('reap its process'). No sibling in the list also closes a session, so the tool is distinguishable, but the description never names the complementary tools (list_sessions, launch_tui) to sharpen the contrast.

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 alternative is named. That it is the teardown counterpart to launch_tui must be inferred from the name 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?

No annotations are provided, so the description carries the full burden. It does disclose the key blocking semantics and the two termination conditions (timeout, EOF), which is meaningful for a wait tool. It does not say what happens on timeout (error vs. silent return) or whether this blocks the session, leaving the most important behavioral question unanswered.

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

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

A single front-loaded sentence with zero filler. The action, the target, and the exit conditions are all stated up front with no redundant restatement of the name.

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

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

An output schema exists, so return values need not be explained. But for a blocking wait tool with no annotations and undocumented parameters, the definition should at minimum state timeout units and the outcome on timeout. As written, an agent can call it but cannot predict failure behavior.

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

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

Schema description coverage is 0% with three parameters, so the description must compensate. It clarifies that 'pattern' accepts a regex or plain text and implies the timeout behavior, but the timeout unit (seconds?) is unstated despite a default of 10, and session_id is never mentioned, so the compensation is only partial.

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: 'Wait until a regex/text pattern appears in the output.' An agent immediately knows this is a blocking wait-for-pattern tool. However, it makes no attempt to distinguish itself from the sibling assert_contains, which presumably serves a similar matching role, so it falls short of a 5.

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

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

There is no when-to-use guidance and no mention of alternatives such as assert_contains or capture_screen. The closest thing to routing information is the parenthetical '(or timeout/EOF)', which describes behavior rather than when to select this tool.

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 usefully discloses the 'buffer mode only' scope constraint, which affects invocation validity, but says nothing about what happens in screen mode (error vs. empty result) or whether it is a non-destructive read, leaving a gap for a tool with zero annotation cover.

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 line with zero waste, front-loading the resource and the mode constraint. Nothing is padded or repeated from structured fields beyond the return shape that adds real value.

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 need not be explained, and the description nonetheless gives the (row, col) shape. For a one-parameter getter with no annotations, however, the undocumented session_id and the unexplained screen-mode behavior leave 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% and there is one parameter (session_id) that the description never mentions. The name and default make it semi-inferable from siblings like list_sessions, but the description does not compensate for the schema's silence on which session is being queried.

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 resource and return shape: the current cursor as (row, col). It is distinguishable from siblings like get_screen_region and assert_at_position, though it never names them. The purpose is clear without opening the schema.

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

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

'buffer mode only' functions as an explicit exclusion, telling the agent this does not apply to screen mode, which is implied usage guidance. However, no alternative is named (e.g. use get_screen_region or assert_at_position in screen mode), so the routing guidance is 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?

With no annotations, the description carries the full behavioral burden and falls short: it implies a read but never states what happens outside buffer mode (error? empty result?), whether it requires an active session, or any other constraint. 'Buffer mode only' hints at a limitation without disclosing its consequence.

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 core action front-loaded and no wasted words. The brevity is efficient, though the trailing qualifier is under-explained rather than merely terse.

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 needn't be described, but the definition still leaves the 'buffer mode' restriction, both undocumented parameters, and the tool's relationship to its many siblings unaddressed. For a 2-param tool with zero annotation and zero schema-description coverage, this is too thin.

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 neither 'row' nor 'session_id' is documented anywhere. The description implies a line index via 'one screen-buffer line' but says nothing about valid ranges, the default session, or how row maps to the buffer, so it fails to compensate for the coverage 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?

The description states a specific verb and resource ('Get one screen-buffer line'), which is clear enough to distinguish from full-screen siblings like capture_screen or get_screen_region. The trailing 'buffer mode only' adds a scope qualifier but never explains what buffer mode is, so the differentiation is only partial.

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 only usage signal is the cryptic 'buffer mode only' constraint. No sibling tool is named as an alternative, no condition is given for preferring this over get_screen_region or capture_screen, and the mode restriction is left undefined.

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. 'Buffer mode only' is a genuinely useful operational constraint, but there is no disclosure of the coordinate origin, indexing base, behaviour of the open-ended col_end, error conditions, or session semantics. The rest of the safety and behavior profile is left to inference.

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 or repetition. It is efficient, though its brevity shades into under-specification rather than active concision.

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, but with 5 parameters at 0% schema coverage and no annotations, the definition leaves the agent without coordinate conventions, mode limitations, or session behavior. For a region-extraction tool where off-by-one and mode errors are easy, this is too thin.

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% across 5 parameters, so the description must compensate and does not. It never clarifies whether row/col indices are 0-based, whether row_end/col_end are inclusive or exclusive, or what a null col_end (the default) means — precisely the ambiguities that would cause a mis-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?

States a specific verb ('extract') and resource ('rectangular screen region'), which naturally distinguishes it from siblings like capture_screen (whole screen) and get_line (single line). It does not explicitly name those siblings, but the scope of the operation is clear from the description alone.

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 only guidance is the constraint 'buffer mode only', which tells the agent this won't work in some other (unspecified) mode but never says when to prefer this over capture_screen, get_line, or get_cursor_position, nor what to use instead in non-buffer modes. No conditions, prerequisites, or alternatives are 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?

With no annotations, the description carries the full behavioral burden, and it discloses little beyond the parameters. It does not say a session is spawned and must be closed with close_session, whether the call blocks, what happens on timeout, or whether sessions persist across calls. Only the mode distinction (buffer = position/cursor aware) hints at runtime 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 purpose sentence followed by a compact argument list — front-loaded correctly with no padding. Minor waste in restating trivially named parameters ('command: The command to launch'), but nothing obstructive.

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, as a mutation-ish tool that spawns a process with no annotations, the description should cover session lifecycle, error/timeout behavior, and the prerequisite relationship to close_session — none of which appear.

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 does the documenting: it explains all five parameters, gives units for timeout ('seconds'), a format for dimensions ('WIDTHxHEIGHT'), and semantics for mode. This is a genuine addition over the bare schema, though the entries for command and session_id largely restate their 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?

States a specific verb and resource ('Launch a TUI application for testing'), which clearly identifies it as the session-creation entry point among siblings like send_keys, capture_screen, and close_session. It does not explicitly name those siblings or spell out the relationship, so it stops short of 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 statement of when to call this versus alternatives, but the mode guidance ('stream' for CLI tools, 'buffer' for full TUIs) implicitly tells the agent which scenario each configuration serves. Usage is implied rather than explicit, and the obvious prerequisite (call this before send_keys/expect_text) is left to inference.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose a non-obvious side effect: dead/expired sessions are 'reaped', meaning this read-like call can mutate session state. That is genuinely useful context an agent would not get from the empty schema, though permissions or failure behavior are not 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?

A single sentence with the core action front-loaded and the behavioral caveat in a compact parenthetical. Nothing is wasted and nothing important is 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?

An output schema exists, so return values need not be described, and the zero-parameter schema requires no parameter guidance. The description covers purpose and the reaping side effect; it could say slightly more about what happens if no sessions exist, but it is essentially complete for this tool's complexity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The parenthetical scope note ('active sessions') usefully defines what the empty-argument call returns.

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

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

Specific verb+resource: 'List active sessions' is unambiguous and clearly distinct from the mutation-oriented siblings like close_session and launch_tui. It stops short of explicitly naming a sibling it is not, so it does not reach 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?

Usage is only implied — an agent can infer this is the discovery/read step before close_session, but the description never states when to call it or when to prefer an alternative. No exclusions or prerequisites are 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 full burden of behavioral disclosure. It conveys the keystroke effect but says nothing about side effects, whether it blocks or waits, what happens on an invalid key, or what error/response results when no matching session 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?

A single sentence with the core behavior front-loaded and an inline example that earns its place; there is no filler or 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 is present, so return values need not be explained. However, for an input-injecting tool with no annotations and a session-scoped parameter, the definition omits session targeting, required session state, and failure behavior — leaving meaningful 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?

Schema description coverage is 0%, so the description must compensate. It does clarify the required 'key' parameter's meaning via the Ctrl-C example, which is genuinely useful, but the second parameter (session_id, default 'default') is never mentioned, leaving its targeting semantics undocumented.

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 — sending a Ctrl+<key> combination — with a concrete example ('c' sends Ctrl-C) that makes the effect unambiguous. It does not differentiate itself from the sibling send_keys, so an agent must infer that this tool is the Ctrl-modifier specialization.

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: it never says to prefer this over send_keys for modifier combinations, nor when to use plain send_keys instead. The existence of a session_id parameter implies it acts on an existing TUI session, but no precondition (session must exist / be active) 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?

With no annotations, the description carries the full burden, and it does disclose one genuinely behavioral fact beyond the schema: escape sequences are decoded unless raw=True. It omits other important traits such as which session receives the input, whether it blocks, and what timing behavior applies, so the disclosure is partial.

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 sentences with the core action front-loaded and no filler; the raw-flag caveat is placed immediately after the main verb. It is appropriately sized, though extremely terse for the behavioral burden it must carry.

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, but for a 4-parameter, zero-annotation mutation-style tool the definition is under-specified: session targeting, delay semantics, and interaction with expect_text/capture_screen are all absent.

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% across 4 parameters, so the description must compensate. It partially clarifies 'keys' and 'raw', but says nothing about 'delay' (units? per-key or total?) or 'session_id' (which session is targeted, and the 'default' fallback), leaving half the parameters undocumented.

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 ('Send keyboard input'), which is unambiguous against read-oriented siblings like get_cursor_position or capture_screen. It does not, however, distinguish itself from the closest sibling send_ctrl, leaving the boundary between 'keys' and 'control keys' implicit.

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 offers no when-to-use guidance, no prerequisites (e.g. a session must already be launched via launch_tui), and no routing advice against send_ctrl or expect_text. An agent must infer the intended workflow entirely from context.

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