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

Annotations already flag destructiveHint=true and non-idempotent, and the description usefully confirms the risk model by demanding a fresh safe-area confirmation and re-observation afterwards. It says nothing about the human-like motion parameters (jitter, overshoot, duration, pause policy) or what failure looks like when the guard is violated.

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?

Three short sentences with the guard requirement front-loaded and the follow-up instruction last. Compact and ordered, though the terseness tips into cryptic in places.

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 10-parameter, nested-schema, destructive, no-output-schema tool, the description is far too thin. An agent gets the safety contract but not enough to reason about coordinate/target semantics or the mouse-path tuning knobs it must supply.

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 10 parameters including a nested pause_policy object with seven fields. The description only alludes to safe_area/safe_area_confirmed and leaves hwnd, x, y, jitter_px, duration_ms, overshoot_px and threshold_px entirely unexplained, 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?

"Guarded safe client click" conveys a click action constrained to a safe region, which is more specific than the bare name. However, "Distinct" gestures at a sibling (presumably human_mouse_click) without naming it, so an agent cannot tell precisely how this differs from the other click 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?

Preconditions are stated: the caller must freshly confirm the safe area does not edit, navigate or submit, and must re-observe before further input. That is real guidance, but the description never says when to choose this over human_mouse_click or human_mouse_drag.

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 already cover the safety profile (readOnly, non-destructive, closed-world), so the description's added value is the explicit disclosure of blind spots: no chat messages, page contents, or other input tool calls. That is genuine behavioral context an agent cannot get from the annotation block, though return shape and format remain unstated.

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 purpose front-loaded and no filler. The phrasing "truthful limits" is slightly idiosyncratic but costs little space.

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

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

With no parameters and no output schema, the description should explain what the report actually returns (which modes exist, what a 'limit' looks like). It names the limitations but not the returned structure, leaving a gap an agent must discover by calling it.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to clarify; baseline for a parameterless tool applies. No misleading parameter language is present.

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?

"Report human mode and truthful limits" gives a verb (report) and a subject (mode/limits), but the subject is abstract and the description never separates this tool from close siblings like human_status or human_mode. The second sentence clarifies scope rather than the tool's own output, so the agent still has to infer what a 'capabilities report' contains.

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 human_status, human_mode, or human_observe. The visibility disclaimer implies a use case (asking what the service can perceive) but does so indirectly, and no exclusions or alternatives are offered.

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 already declare destructiveHint=true, non-idempotent and not read-only; the description adds genuinely new context with 'contents never inspected,' a privacy trait nothing else states. However, it never reconciles the surprising destructiveHint for a copy (that the system clipboard gets overwritten?) nor explains what the target window must be.

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 zero filler, and the key behavioral caveat is front-loaded. It is efficient to the point of under-specification, but that shortfall is penalized elsewhere rather than here.

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 a nested seven-field policy object, a patterned window handle, no output schema, and no doc coverage, the description is far too thin. An agent cannot construct a correct call beyond guessing defaults for pause_policy and threshold_px.

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, and the description supplies no parameter meaning at all. The required hwnd (a window handle as a decimal string) and the seven-field pause_policy object (stable_ms, window_ms, lifetime_ms, sustained_ms, large_path_px, large_range_px, small_excursion_px) are entirely opaque to the agent.

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?

Names a specific verb+resource ('Explicit Ctrl+C using the system clipboard'), which is concretely distinguishable from human_cut/human_paste siblings by the keystroke it emulates. It stops short of explicitly naming those siblings, so an agent must infer the cut/copy/paste split.

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

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

No statement of when to call this versus human_cut, human_paste, or human_input_plan, and no prerequisites such as needing the target window focused. The word 'Explicit' hints at a contrast but never names it.

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

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

Annotations already declare destructiveHint=true and non-read-only, and 'may modify content' is largely a restatement of that. The description does add genuinely new context—this is an explicit synthetic keystroke and the clipboard contents are not inspected or verified—which helps the agent understand failure modes, but permissions and target-focus requirements remain unstated.

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?

Three short clauses, front-loaded with the action, and each clause carries information (action, side effect, limitation). The fragmentary style is efficient though slightly cryptic in places.

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

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

For a destructive tool with a nested timing/threshold configuration object and no output schema, the definition leaves too much unexplained: what hwnd must reference, what pause_policy actually governs (input-stability pacing), and what the caller observes after the keystroke. Annotations cover safety only.

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

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

Schema description coverage is 0% and the description mentions no parameters at all. The tool has a required hwnd plus a nested pause_policy object with seven sub-properties (stable_ms, window_ms, lifetime_ms, etc.) and a threshold_px, all of which are documented only by bare min/max bounds, so the description entirely fails to compensate.

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?

Names the concrete action (Ctrl+X) and the resource implicitly (current selection to clipboard), which distinguishes it from human_copy/paste in the sibling list without an explicit comparison. It is clear but telegraphic rather than a full statement of purpose.

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?

'Explicit Ctrl+X' gives an implied context (send the cut shortcut) but there is no when-to-use guidance, no statement of prerequisites such as the target window needing focus, and no routing to human_copy or human_key for other editing operations.

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 already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is substantially covered. The description adds a useful caveat that it does not resume input or prove model receipt, but it does not explain what destructive state change occurs, what permissions are required, or what a successful acknowledgement means beyond the annotation hints.

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 front-loads the action, with the caveat following immediately. It is not padded, though its terseness contributes to the gaps in parameter and usage detail; from a conciseness standpoint, it is efficient.

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 four required parameters, 0% schema description coverage, no output schema, and destructive/idempotent annotations, the description is insufficient. It does not explain parameter sourcing, expected response behavior, or the consequences of acknowledgement, leaving the agent under-informed before 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 carry parameter meaning. It references an 'event token', likely receipt_token, but provides no explanation for event_id, session_epoch, pause_generation, or the token's format and source. Three of four required parameters remain undocumented in both schema and 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 gives a verb and resource: 'Acknowledge ... receipt using the event token.' However, 'MCP caller receipt' is jargon-heavy and does not clearly explain what the tool actually acknowledges or how it differs from sibling event/resume tools. The caveat 'Never resumes input' provides partial differentiation, but the overall purpose remains vague to an agent.

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 use this tool versus alternatives such as human_resume, human_events, or human_pause. The statement 'Never resumes input' is a negative clarification but not a usage guideline. The agent is left to infer the appropriate context for calling an event acknowledgement.

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 already declare readOnly=true, destructive=false, openWorld=false, so safety is covered. The description earns credit for adding genuinely non-obvious behavior: discovery is delayed and there is no push channel, meaning the caller must re-poll rather than expect notifications. That is context the annotations cannot express.

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, front-loaded with the core verb and resource, then the polling caveat. Nothing is padded, though "bounded" is an ambiguous word that costs more confusion than it saves.

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?

No output schema exists and all three parameters are undocumented, so the description should compensate but does not: it never says what an event record contains, how the sequence cursor advances, or how pending_only interacts with human_event_ack. For a paginated read tool this leaves the agent guessing at the call protocol.

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%: limit, after_seq, and pending_only have no descriptions, types aside. The description says "bounded" but never explains that limit caps the batch, that after_seq is a pagination cursor, or that pending_only filters unacknowledged events — the three facts an agent most needs to call this correctly.

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?

"Read bounded event history" states a verb and resource, so an agent knows this retrieves event records. But "events" is undefined (input events? timer events? agent events?) and nothing distinguishes it from siblings like human_observe, human_status, or human_event_ack, which plausibly also expose event-ish data.

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?

"Discovery is delayed; agent push is unsupported" implies a polling model, which is a useful hint, but it is timing trivia rather than when-to-use guidance. There is no statement of when this tool should be chosen over human_event_ack (the natural acknowledgement counterpart) or human_observe.

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 already declare readOnlyHint=true and destructiveHint=false, so the description's job is the extra context, and it delivers: previews emit no input, perform no cancellation, and typing previews are pure with no hwnd. The 'page freshness is the caller responsibility' caveat is a genuinely useful disclosure that the preview does not validate live UI state, though it says nothing about what the returned preview contains or its cost.

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?

Three short sentences, front-loaded with the core distinction (preview, no input), then the per-kind hwnd rule, then the freshness caveat. Dense but every sentence carries information; no repetition of the name or of annotation-declared safety facts.

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?

This is a five-variant oneOf tool with no output schema, and the description covers the dry-run contract and hwnd asymmetry but omits the 'reading' kind entirely and never says what a successful preview returns or how that result is subsequently used. For a tool whose whole value is the preview artifact, that gap is significant.

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

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

Schema coverage is high (100%), so the baseline is 3, but the description adds real meaning the schema cannot: it explains why hwnd is conditionally required — typing needs none, pointer kinds need hwnd to resolve client bounds. That rationalizes the oneOf split. It leaves the timing/tuning parameters (jitter_px, overshoot_px, pause_policy, threshold_px, wpm, typo_rate) entirely to the schema.

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

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

States a specific verb and resource ('Preview a bounded plan') and immediately narrows it with 'without input or cancellation', which separates it from executor siblings like human_type or human_mouse_click. It never names an actual alternative or explains what a 'plan' is in this system, so the agent must infer the domain from the kind enum rather than the prose.

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 phrase 'without input or cancellation' implies a dry-run to be used before committing real input, but no explicit when-to-use, when-not-to-use, or named alternative is given. An agent can guess the ordering (preview first, execute later) but the definition never confirms it.

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

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

Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely non-structured context: the key must be on an allowlist, Enter may submit (the reason it is destructive), and clipboard operations are out of scope. It omits the most operationally important traits – that the target must be focused/foreground, and how pause_policy/threshold_px alter timing 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?

Three short sentences, front-loaded with the constraint, and no filler. The terseness is close to under-specification rather than padding, so it is efficient but leaves little substance behind.

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?

This is a destructive, nested-schema tool with no output schema and no parameter documentation; the description should carry far more of that burden. Critically, an agent cannot learn which keys are on the allowlist, how to obtain a valid hwnd, or what pause_policy governs – all of which are required to invoke it correctly.

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

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

Schema description coverage is 0% across 5 parameters, including a nested pause_policy object with seven unexplained integer fields. The only semantic aid is the word "allowlisted," which implies the key parameter is constrained to a known set the schema does not enumerate; hwnd, modifiers, pause_policy and threshold_px receive no explanation in either place.

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 phrase "One allowlisted editing/navigation chord" identifies the resource (a single key chord from a restricted set) but uses no verb and never mentions the hwnd/target window, so what the tool actually does to the system has to be inferred. It partially differentiates from clipboard siblings (human_copy/human_cut/human_paste) but not at all from human_type or human_input_plan.

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?

"Clipboard actions require dedicated tools" is an explicit when-not-to-use that routes to named siblings, which is real guidance. However there is no positive statement of when to prefer this over human_type/human_input_plan, and no mention of the precondition that the target window must be active or how to get an hwnd.

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 already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable context beyond them: every process starts disabled, and a mode change cancels in-flight work before returning. It doesn't say whether the cancellation is recoverable or what the query returns, keeping it below 5.

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, front-loaded with the query-vs-set choice and followed by the critical behavioral caveat. No wasted words.

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

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

For a one-parameter toggle with no output schema, the description covers usage and the key side effect. The main gap is not describing what the query form returns, which an agent must infer without an output schema.

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

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

Schema coverage is 0%, so the description carries the burden for the single parameter. It explains that empty arguments mean query and passing 'enabled' toggles human input, which maps the boolean to intent reasonably well, but it doesn't state the default or explicitly tie true=enable/false=disable.

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: query the current mode, or explicitly enable/disable human input. This is clear and distinguishable from general status tools like human_status, though it doesn't explicitly name or contrast with its closest siblings (human_pause/human_resume), 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?

It gives clear when-to-use guidance: call with empty arguments to query, or pass 'enabled' to change the mode. It offers no explicit exclusions or named alternatives for the toggle behavior (pause/resume), so it is not a full 5.

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

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

Annotations already declare destructiveHint=true and non-idempotent behavior. The description adds meaningful context beyond that: the call waits for completion (synchronous), requires the cursor to already be in the client, and warns that the target must be freshly established to avoid stale UI.

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 tight sentences: the action is front-loaded, followed by the critical preconditions. Nothing 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?

The essential behavior and preconditions are covered, but with 8 parameters at 0% schema coverage and no output schema, an agent lacks guidance on the optional tuning parameters. Adequate for the core action, but not complete for correct parameterization.

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 8 parameters, including a nested pause_policy object with 7 undocumented fields. The description only implies that x/y are client coordinates and hwnd is the target client; it says nothing about jitter_px, duration_ms, overshoot_px, threshold_px, or pause tuning.

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 verb and resource: 'Move to a client point and pulse the left button once,' which clearly distinguishes a click from a move-only sibling like human_mouse_move. It does not explicitly name an alternative, but the action itself 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?

It states clear preconditions — the cursor must already be inside the target client, and the caller must freshly establish the intended UI target. There are no explicit exclusions or named alternatives, but the usage context is well defined.

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 already disclose destructive=true, idempotent=false, and readOnly=false. The description adds operationally important behavior: left-button drag, synchronous wait for completion, and no cursor pre-positioning. It still omits failure and permission details, but against the annotation baseline this is useful context.

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

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

Two sentences, front-loaded with the operation and then a key constraint; neither sentence is filler. It is arguably terse for the schema complexity, but there is no structural waste.

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

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

For a destructive tool with 8 parameters, a nested pause_policy object, and no output schema, the description is too sparse. It does not explain hwnd targeting, optional drag controls, pause policy semantics, or failure behavior, leaving the agent under-informed beyond the core action.

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

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

Schema description coverage is 0%, and the description only maps x/y as the client target and start point as the current cursor. It leaves hwnd, jitter_px, duration_ms, overshoot_px, threshold_px, and the nested pause_policy fields unexplained, which is a major gap for an 8-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 names a specific operation—left-button drag—and defines both endpoints (current observed cursor to a client point), plus the completion behavior. It is distinguishable from human_mouse_move and human_mouse_click because it explicitly performs a drag and says it does not pre-position the cursor.

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 the tool is for dragging from wherever the cursor currently is and warns that it will not move the cursor first, which is useful context. However, it does not state when to choose this over human_mouse_move plus human_mouse_click, nor what prerequisites such as an observed cursor must be met.

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?

Beyond the annotations (destructive, non-idempotent, non-readonly), it discloses two genuinely important traits: the call blocks until completion ('waits for completion') and it has a side effect on other subsystems ('Cancels background reading first'). These are exactly the kind of facts an agent cannot infer from structured fields.

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?

Four short clauses, front-loaded with the verb and the primary behavioral fact, with zero filler. 'No auto focus' is terse to the point of being slightly cryptic, and the side-effect sentence would land better before the precondition, but the density is appropriate.

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

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

For an 8-parameter tool with a 7-field nested tuning object and no output schema, the description covers behavior well but parameters almost not at all, leaving the entire pause/trajectory tuning surface opaque. An agent can call it with the three required fields but cannot reason about the optional ones.

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 8 parameters, and the description never mentions x, y, hwnd, jitter_px, duration_ms, overshoot_px, threshold_px, or any of the seven nested pause_policy fields. 'Bounded human-style path' vaguely gestures at the tuning knobs but gives an agent nothing actionable about units, defaults, or trade-offs.

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 and resource: 'Move ... the observed cursor through a bounded human-style path', which clearly separates it from human_mouse_click, human_mouse_drag, and human_scroll. It does not explicitly name those siblings as alternatives, but the operation 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?

'The cursor must already be inside the target client (use human_activate to enter)' gives an explicit precondition and routes to the right sibling when it is unmet. 'No auto focus' adds a clear negative constraint, though there is no guidance on when to prefer click/drag over a bare move, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description reinforces that it has no side effects ('does not focus a window'), but it does not explain the surprising idempotentHint=false for a pure read, nor anything about cost or rate of polling.

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 tightly packed sentences with the capability list first and the exclusions second; no filler and every clause carries information.

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

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

A one-parameter read tool with annotations covering safety and no output schema, so the description needn't explain return values. However, the undefined 'hwnd' input and unclear semantics of the returned identity/geometry data leave the agent guessing on the one thing it must supply.

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% — the single required 'hwnd' parameter has only a regex pattern and no prose. The description never explains what the handle identifies or where to obtain it, so it fails to compensate for the schema gap on the one parameter that matters.

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?

Uses a specific verb ('Read') followed by an enumerated set of resources: native target identity, client geometry, focus, foreground, DPI and cursor. The negative clause carves it away from screenshot, activation and reading tools, though 'native target identity' remains domain jargon an agent must interpret.

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?

Explicitly states three things it does not do (capture images, focus a window, cancel reading), which steers the agent toward human_activate or reading_cancel for those needs. It stops short of a positive 'use this when you need X' statement or naming the alternative siblings directly.

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

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

The description adds useful context beyond the destructiveHint annotation: 'may modify content' warns of mutation and 'No clipboard content inspection' clarifies that it does not read clipboard data. It still does not explain focus requirements, clipboard prerequisites, or what happens to existing selected content, which matters for a paste operation.

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

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

The description is very short and front-loaded: action first, then mutation warning, then clipboard-inspection limitation. It is concise, though the fragmentary phrasing is terse to the point of feeling cryptic.

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

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

For a destructive, non-idempotent tool with a required window handle and a nested pause-policy object, the description is far too sparse. It gives no explanation of targeting, pause behavior, thresholds, or clipboard prerequisites, and there is no output schema to fill in return semantics.

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

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

Schema description coverage is 0%, and the description mentions none of the three parameters. The required hwnd value, the nested pause_policy fields, and threshold_px are completely unexplained, so the description does not compensate for the schema's lack of documentation.

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 action, 'Explicit Ctrl+V,' so an agent can tell it performs a paste keystroke rather than reading the clipboard. It does not explicitly mention that the paste is directed at a target window identified by hwnd, leaving the resource context partly 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?

There is no explicit guidance on when to use this tool instead of siblings like human_type, human_key, human_copy, or human_cut. 'Explicit Ctrl+V' and 'No clipboard content inspection' imply some usage, but the agent is left to infer the selection conditions.

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 already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description hints at cleanup and admission latching, but it never explains what gets destroyed, whether the pause is reversible, or how the two stated modes differ.

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 single sentence is brief and front-loads "Pause", but it is under-specified rather than clarifying. The "or" implies two modes, yet the structure leaves both unexplained.

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

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

For a destructive tool with an undocumented optional parameter and no output schema, the description omits critical usage, behavioral effects, and parameter guidance. It is not complete enough for an agent to call this safely or correctly.

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

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

The schema has one optional parameter, operation_id, with 0% description coverage, and the description does not mention it at all. It adds no meaning about what operation_id identifies or when it should be supplied.

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 only immediately understandable verb is "Pause", while "cleanup barrier" and "latch admission while idle" are unexplained internal jargon rather than a specific resource or scope. The description does not clarify what is being paused or how this differs from human_stop/human_resume.

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, no exclusions, and no comparison to sibling tools such as human_stop or human_resume. An agent has no basis for choosing this tool over its alternatives from the description.

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

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

With destructiveHint=true and idempotentHint=false already disclosed, the description adds useful context by noting that pause cleanup precedes a fresh native observation and that uncertain effects require exact external outcomes. It still does not explain what cleanup destroys, what happens on ambiguous resolution, or what the tool returns.

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

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

The description is short and front-loaded, with each sentence carrying potential operational meaning. Its density and jargon reduce clarity, but it is not padded or verbose.

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

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

For a destructive, non-idempotent tool with four parameters, a complex oneOf resolution schema, zero schema descriptions, and no output schema, the description is too cryptic. It omits the semantics of the resolution variants and the roles of operation_id and pause_revision, leaving major gaps.

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

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

Schema description coverage is 0% for four parameters, including a complex oneOf resolution object with continue/observed/finish/remaining_gesture variants. The description only vaguely gestures at empty arguments and external outcomes; it does not explain operation_id, pause_revision, external_checked, or which resolution variant to choose.

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 phrase "Explicit checked continuation" largely restates the name "human_resume" in jargon rather than stating a concrete verb and resource. "Fresh native observation follows pause cleanup" hints at resumption after a pause, but the agent is left to infer what is being resumed and under what workflow.

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 conditional guidance: empty arguments only clear an idle pause, and uncertain effects require exact external outcomes. However, it does not compare this tool against siblings such as human_pause, human_observe, or human_status, so the routing guidance is only implied.

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 already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds useful behavioral constraints: wheel deltas are in Windows units, must be multiples of 120, and no pixel/line inference is performed. It does not describe what application state may change from scrolling or how the target hwnd is affected, which is a gap even with annotations present.

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 two-sentence description is front-loaded and has no filler. 'No pixel/line inference' is a meaningful constraint rather than repetition. It is efficient, though its brevity contributes to the larger completeness gaps.

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 non-idempotent, destructive scroll operation with five parameters, a nested pause_policy object, and no output schema, the description is too sparse. It says nothing about hwnd targeting, axis behavior, threshold_px, pause_policy tuning, or what the caller should expect after scrolling. The annotations cover safety hints but not operational 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?

Schema description coverage is 0%, so the description must compensate, but it only explains delta semantics: Windows units, multiples of 120 up to 1200. It leaves hwnd, axis, threshold_px, and the entire nested pause_policy object undocumented in both schema and prose. This is inadequate for a five-parameter tool with a nested object.

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: 'one explicit wheel operation'. The Windows-unit and 120-multiple constraints make the core action unambiguous. It does not differentiate this scroll tool from siblings such as human_mouse_move or human_mouse_drag, so it stops short of a 5.

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

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

There is no guidance on when to use human_scroll versus alternatives like human_mouse_move or human_mouse_drag. The description also omits prerequisites, such as whether the target window must be active or focused. Usage is only implied by the tool name and the phrase 'one explicit wheel operation'.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that pending safety events are included and reinforces that the tool does not resume or cancel, but it does not explain optional operation_id behavior, result shape, or whether omitting operation_id returns all statuses.

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 short sentences with no wasted words, and the core readonly/status scope is front-loaded before the non-resume/cancel clarification.

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

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

For a simple read-only status tool with clear annotations, the description covers the high-level purpose. However, because there is no output schema and the optional operation_id is undocumented, an agent is left guessing about both the parameter's effect and the exact status/event return structure.

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 is one optional operation_id parameter with 0% schema description coverage, and the description never mentions it or explains whether omitting it returns all operations. The description therefore provides no meaningful parameter semantics beyond what the bare schema shows.

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 the specific resource: readonly operation status and pending safety events. It also distinguishes the tool from mutating siblings by saying it does not resume or cancel, though it never names the relevant alternatives such as human_resume or human_stop.

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

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

It gives a useful exclusion by stating the tool does not resume or cancel, which implies it is for inspection only. However, it does not explicitly say when to use this instead of human_events, human_capabilities, reading_status, or timer_status.

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?

Adds real context beyond the annotations: it discloses that the stop is blocking ('wait until no future injections are possible') and states the boundary that it does not return the cursor or release user-owned input. That complements destructiveHint/idempotentHint rather than repeating them.

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

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

Two sentences, both load-bearing, with the core action front-loaded and the non-effects stated second. 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 destructive, blocking control tool with no output schema, the description covers the main semantics but leaves open how long it waits, what happens if input is already stopped, and what the caller gets back on success or timeout. The undocumented reason parameter is a further 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% and the single parameter (reason, 1-512 chars) is never mentioned. The description offers no hint about what the reason is for, whether it is recorded, or whether it affects behavior.

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

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

States a specific verb (cancel) and resource (current or pending input) plus the blocking invariant that follows. An agent can distinguish it from observation/status siblings, though it never names human_pause or human_resume, which are the nearest alternatives.

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

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

The description implies when this is appropriate (a hard stop before no further injections can occur) but gives no explicit when-to-use/when-not guidance and does not contrast it with human_pause/human_resume, which an agent would plausibly confuse it with.

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 already declare destructive=true and non-idempotent, and the description adds real context: it cancels in-flight work via a 'barrier' and replaces the target while explicitly not focusing or moving a window. However, the definition of 'barrier', what exactly gets replaced, whether the cancellation is reversible, and any permission requirements remain unexplained for a destructive operation.

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

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

Two short sentences with no filler, and the side-effect negation is placed last as a clear scope boundary. The text is efficient; the problem is missing content, not padding.

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

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

For a destructive, stateful tool involving cancellation barriers and target replacement, with no output schema and an undocumented parameter, the description is far too thin. An agent could not confidently predict what happens on invocation or how to supply hwnd 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?

There is one parameter (hwnd) with 0% schema description coverage, and the description never mentions it or explains the accepted format (a digit-only string matching ^[1-9][0-9]{0,19}$). 'Selected target' gestures at the parameter but does not establish what hwnd identifies or how a target becomes 'selected'.

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 verb phrase 'observe and replace the selected target' is obscure — neither 'target' nor 'replace' is defined in a domain sense, and the name already implies 'update'. The final negation ('Never focuses or moves a window') is the only part that clearly differentiates it from siblings like human_activate or human_mouse_move.

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?

'Cancel current work with a barrier' hints at a precondition, but there is no explicit statement of when to choose this over human_observe, human_activate, or human_mouse_click. No exclusions or alternatives are named beyond the single negative window claim.

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 already declare this as destructive, non-idempotent, and not read-only. The description adds meaningful operational context beyond that: character pulses, optional corrections, input exclusions, the IME prerequisite, and the remote-delivery caveat. It does not fully explain target focus requirements or undo behavior, but it contributes real behavioral information.

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 compact, front-loaded sentences with no filler. It leads with the core action, then immediately enumerates exclusions and constraints. Every clause contributes useful selection or invocation 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?

This is a complex input-synthesis tool with eight parameters, a nested pause_policy object, no output schema, and destructive annotations. The description covers exclusions and one IME flag but omits most parameter semantics and does not explain how hwnd targeting, typing speed, typo behavior, or pause policy affect execution. It is not complete enough for an agent to invoke the tool confidently without inspecting the schema.

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 eight parameters, including a nested pause_policy object, so the description must carry the explanatory burden. It only clarifies force_ime_off, while hwnd, text, wpm, seed, typo_rate, threshold_px, and all pause_policy fields remain unexplained. The brief mention of bounded pulses and optional corrections hints at behavior but does not define the 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 specifies a clear verb and resource: type printable text via bounded character pulses, with optional corrections. It also distinguishes scope by excluding paste, Enter, and arbitrary chords, which helps separate it from sibling input tools such as human_paste and human_key. The only gap is that it does not explicitly name the sibling alternatives.

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

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

The description gives useful when-not guidance: no paste, no Enter, and no arbitrary chords. It also states a specific prerequisite for IME changes via force_ime_off=true and warns that remote delivery is not verified. It stops short of explicitly routing the agent to human_paste or human_key for the excluded cases.

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 already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the meaningful trait that it installs a "no-future-injection barrier," but stays jargon-heavy and never says what data or in-flight state is lost on cancel.

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 action front-loaded and no padding. The second sentence is slightly dense jargon, but nothing 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?

For a destructive, idempotent mutation the annotations cover the safety profile, and the default-selection rule is given. Missing are the fate of cancelled work, the purpose of reason, and immediacy semantics, which an agent would want before invoking a destructive cancel.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It usefully documents operation_id's default (omitted selects the active operation), but says nothing about the reason parameter, leaving half the inputs 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 ("Cancel reading") that clearly separates it from siblings reading_start and reading_status. It adds a scope note ("no-future-injection barrier") but never names the siblings or contrasts behavior with them 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: the second sentence explains what happens when operation_id is omitted, which hints at when the default form applies, but there is no statement of when to prefer this over reading_status or when cancellation is inappropriate.

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

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

The annotations already flag destructiveHint=true and non-idempotence, and the description adds genuinely new behavioral facts: the traversal is autonomous, it returns promptly (i.e., asynchronous start), and is cancelled by new input, stop, target or mode changes, but not by chat messages. That cancellation contract is not derivable from the annotations.

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?

Four tight sentences with the action and precondition front-loaded and no filler. Density is high, though the compressed phrasing ('pure pointer traversal', 'target or mode changes') trades some clarity for brevity.

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 complex tool with nested objects, 5 parameters and no output schema, the description omits any parameter guidance and never says what is returned ('return promptly' implies an async handle but does not confirm it). The cancellation model is covered, but the caller still cannot construct a valid call from this text.

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, including nested segments, rect, direction, duration_ms, pause_policy and threshold_px, yet the description explains none of them. Only an oblique link exists ('explicit client regions' → segments, 'target client' → hwnd), leaving the bulk of the schema 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?

The description names a specific verb ('Begin') and a concrete resource ('autonomous pure pointer traversal of explicit client regions'), which distinguishes it from the sibling reading_status and reading_cancel tools. 'Pure pointer traversal' is somewhat jargony, but the intent remains recoverable.

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 states a hard precondition ('The cursor must already be inside the target client') and constraints ('No buttons or keys'), plus explicitly lists which events cancel the traversal and the one exception (chat messages). It never names reading_cancel or reading_status as alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine scope disclosure — "deliveryVerified=false; no page or reading-comprehension detection" — warning the agent not to over-interpret results, but it does not explain the notable idempotentHint=false on a pure status read, nor what is actually returned.

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, front-loaded with the core action, with no filler. The second sentence is terse to the point of being cryptic ("deliveryVerified=false"), which slightly hurts readability but not economy.

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

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

With no output schema and no parameter documentation, the description carries the full burden but only hints at scope via a cryptic flag. It never says what the status response contains or what the caveat applies to, leaving an agent under-informed for even this simple tool.

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

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

Schema coverage is 0% and the single parameter operation_id is undocumented in both schema and description. Critically, operation_id is optional, and the description never says what happens when it is omitted (all operations? default?). This is a real gap the description should have filled.

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

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

The first sentence gives a specific verb and resource ("Read reading operation status") and implicitly contrasts with the sibling reading_cancel by saying "without cancelling it." It is clear what the tool does, though the siblings reading_start/reading_cancel are never named 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: check status without cancelling. There is no explicit statement of when to prefer this over polling other tools or what precondition (e.g. an in-flight operation) is required, and no named alternative.

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 already declare destructiveHint=true and idempotentHint=false, so the threshold is lower, and the description adds real context by scoping out screen-pixel reads and input cancellation. However, it never says what the destructive part actually is — whether an existing attachment is overwritten, or what happens on repeated calls — which is exactly the gap the destructive hint leaves open.

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 tight sentence with the action front-loaded and no filler. The trailing negative clause is useful but compressed to the point of ambiguity about what it is contrasting against.

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

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

For a destructive, non-idempotent mutation with zero schema documentation and no output schema, the description should cover the effect on existing state, the optional timer_id, and what a caller gets back. It covers only the bare action, so an agent could call it correctly-shaped but not predict its consequences.

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 undeclared parameters. The description names the two required concepts (target, section) but says nothing about their meaning, format, or relationship, and the optional timer_id is completely undocumented in both schema and 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?

States a specific verb+resource ('attach an external-observation timer') and the two anchors ('explicit target and section'), which cleanly separates it from timer_detach/timer_prepare. It does not name the sibling alternative or explain how it relates to prepare/calibrate, 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?

No when-to-use or when-not-to-use guidance beyond the words 'explicit target and section'. With siblings timer_prepare, timer_calibrate, timer_status and timer_detach present, the agent gets no signal about ordering or prerequisites (e.g., must the timer be prepared first?).

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 already declare this as destructive, non-idempotent, and not read-only, so the safety profile is covered. The description adds the prepared-ticket prerequisite and explicit expired_observed state requirement, but does not explain what the calibration overwrites or how destructive the anchoring operation is.

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 tight sentences with no filler, front-loading the core action and following with the key conditional state requirement. Every sentence contributes 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 destructive, non-idempotent timer mutation with no output schema and zero schema descriptions, the description omits important context: timer_id semantics, the full state enum meaning, and the effect of anchoring on an existing timer. It gives some targeted guidance but is not complete enough for safe invocation without inference.

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 carry parameter meaning. It clarifies ticket_id via "prepared ticket," observed_seconds via "caller-observed seconds," and the expired_observed state, but leaves timer_id unexplained and does not clarify the running or paused_observed enum values.

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

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

The description states a specific action ("Anchor a timer") with key inputs ("prepared ticket" and "caller-observed seconds"), making the core purpose clear. It does not explicitly distinguish this tool from sibling timer_attach or timer_prepare, so it stops short of full sibling 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?

The phrase "using a prepared ticket" implies a prerequisite likely satisfied by timer_prepare, and the expired_observed condition gives one usage condition. However, it does not explicitly say when to choose this over timer_attach, timer_status, or timer_invalidate, so guidance is only implied.

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 declare destructiveHint=true and idempotentHint=false, so the agent already knows this mutates state. The description does not explain what detaching destroys, whether observation data is lost, whether the timer can be reattached, or what permissions are needed.

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

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

A single front-loaded sentence with no filler. It is structurally efficient, though the brevity reflects missing content rather than disciplined editing.

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

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

For a destructive tool with no output schema and no documented parameters, this description is far too thin. Annotations cover the mutation profile, but the agent still lacks enough context to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate, but timer_id is never mentioned. 'One external-observation timer' vaguely implies the parameter's target but gives no format, constraints, or meaning for timer_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?

States a specific verb (detach) and resource (timer), and 'external-observation timer' narrows the target. However, it does not distinguish detaching from related siblings like timer_invalidate or timer_stop, and 'without touching input' is cryptic rather than clarifying.

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 use this versus timer_attach, timer_invalidate, or timer_status. The only usage-like phrase, 'without touching input,' does not tell the agent which situation calls for detaching.

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 already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds a useful scope clarification ('does not inspect or mutate a page'), but it does not say what is lost when an estimate is invalidated, whether the timer must be re-prepared afterward, or whether the operation 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?

A single semi-colon-joined sentence with zero filler, front-loading the action and then the constraint. It is arguably too compressed for a destructive tool, but nothing 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?

With only two parameters and no output schema, the tool is simple, but a destructive operation should at minimum explain the effect on subsequent timer operations and what 'reason' is used for. The description covers scope but not consequences, leaving a real gap for a mutating tool.

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

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

Schema description coverage is 0%, so the description must compensate and it does not: the optional 'reason' parameter (1-512 chars) is never mentioned, nor is how 'timer_id' should be sourced. The only parameter-level hint is implicit in the word 'invalidate'.

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 target ('Invalidate a timer estimate') plus a qualifying condition ('after known external changes'), which separates it cleanly from siblings like timer_attach, timer_prepare, and timer_calibrate. It stops short of defining what an 'estimate' is or how invalidation differs from timer_detach, but an agent can still tell what the tool does.

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 phrase 'after known external changes' implies a trigger condition, and 'does not inspect or mutate a page' sets a boundary. However, no sibling is named as an alternative (e.g., timer_calibrate vs. timer_detach vs. this), so the agent must infer the routing decision from the sibling list 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?

Annotations already declare that the operation is destructive, non-idempotent, and not read-only. The description adds only the phrase "bounded observation ticket" without explaining ticket lifetime, whether preparation can invalidate prior tickets, what side effects occur, or what "bounded" means in practice.

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 efficient sentence with the timing condition front-loaded. Its brevity is appropriate, though the undefined phrase "bounded observation ticket" reduces clarity rather than length.

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

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

For a destructive, non-idempotent tool with no output schema and an undocumented parameter, the description is too thin. It does not explain ticket lifecycle, side effects, error conditions, or how this preparation step relates to timer_attach, timer_status, or reading_start.

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 is one parameter, timer_id, and schema description coverage is 0%, so the description needs to explain its meaning and constraints. It only indirectly references a timer and provides no detail about the identifier's format, source, or relationship to the prepared ticket.

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 preparatory action and ties it to reading a timer through an external source. However, the core resource, "bounded observation ticket," is undefined jargon, so the tool's concrete purpose remains vague and not clearly distinguished from siblings such as timer_attach or reading_start.

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

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

It gives timing guidance: use this before the caller reads a timer through an external source. It does not name alternatives, prerequisites, or when not to use it, and the relationship to adjacent timer/reading tools is left implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'never cancels input' is largely reinforcement, though it usefully targets the specific side effect an agent might fear. It does explain the return shape at a high level (anchor vs. estimate reported separately), but leaves unexplained why idempotentHint=false for a read, what makes the estimate 'uncertain', or what happens for an unknown timer_id.

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 tightly packed sentences with no filler, and the return-content statement is front-loaded before the side-effect clarification. Minor loss: 'an uncertain estimate' is compressed to the point of ambiguity about units or volatility.

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

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

With no output schema the description carries the burden of describing returns, and it only sketches them qualitatively (anchor, uncertain estimate). Combined with an undocumented required parameter and no error behavior for invalid or unknown timer ids, it is adequate but leaves real gaps for a 1-param read tool.

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

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

There is one parameter, timer_id, and schema description coverage is 0% — the schema gives only length bounds. The description never mentions timer_id, its expected format, or where an agent obtains one (presumably from timer_attach or timer_prepare), so it does not 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?

States a specific verb and resource: it returns the observed timer anchor plus a separate uncertain estimate, which is more informative than the bare name 'timer_status'. However, it never contrasts itself with sibling timer tools such as timer_calibrate, timer_prepare, or reading_status, so the agent must infer the boundary.

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

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

'Querying never cancels input' implies this is a safe, repeatable inspection call and hints that polling is acceptable, but it never says when to use this rather than timer_calibrate or timer_invalidate, nor any prerequisite such as a timer having been attached or prepared first.

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