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

With no annotations, the description must carry the full behavioral burden. It discloses two important traits: the expected-screen precondition and the authorization requirement for write/irreversible controls, but it omits what happens on mismatch, how authorization is validated, and whether the click has immediate side effects.

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

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

The description is two tightly written sentences with the key precondition front-loaded. There is no redundant or filler content.

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

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

For a six-parameter mutation tool with no annotations and no output schema, this is under-specified. It covers the main safety idea but leaves critical operational details undocumented, including parameter roles, failure behavior, and authorization mechanics.

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 six parameters, so the description must compensate. It only indirectly touches expected_screen and authorized_effects through 'expected map state' and 'explicit authorization'; it says nothing useful about anchor_id, app_id, port, or target_url.

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: 'Click a mapped browser control.' It clearly distinguishes a browser control click from generic desktop/click siblings, though it does not explicitly name alternatives such as pulse_desktop_click.

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 clear precondition: use only when the current screen still matches the expected map state. It also notes that write and irreversible controls require explicit authorization, but it does not name alternative tools or explain what to do when the precondition fails.

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

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

With no annotations, the description carries the full burden and does so well: the value is ephemeral (never stored or returned), the form is never submitted, and an authorized_effects:["write"] grant is required. It also discloses the non-obvious side effect that focus is dropped by default and explains why, plus the exact set of field types that are refused.

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 dense sentences, front-loaded with the action, then safety, then refusals, then the focus caveat. Nothing repeats the schema or the name, and the caveat about focus is placed exactly where an agent needs it before composing a multi-step call.

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 behavioral and safety picture is complete for a mutation tool with no annotations and no output schema, but the description never addresses how the target browser session is identified (app_id, port, target_url, expected_screen) — four of eight params left undefined in both schema and prose. An agent knows what will happen but not fully how to address the right context.

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 only explains value, keep_focus, authorized_effects, and indirectly anchor_id ('mapped browser field'). The target-selection parameters — app_id, port, target_url, expected_screen — get no meaning at all, which matters for a tool that must act on the right browser session.

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 — 'Type a value into one mapped browser field' — which is unambiguous and clearly separable from pulse_browser_key (key presses) and pulse_browser_click (clicks). The scope word 'one' also tells the agent this is a single-field operation, not a bulk fill.

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?

Gives an explicit sequencing rule: 'Set keep_focus when a fill is followed by pulse_browser_key', naming the sibling and the condition that selects it. It also enumerates the field types that are refused, which tells the agent when this tool will not work. No general 'use X instead' routing for the other browser siblings, so it stops 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?

No annotations are supplied, so the description carries the full burden. It discloses the allowlisted key set, the form-submission effect of Enter, and the authorized_effects write requirement, but it does not explain escape behavior, screen-mismatch handling, or what the call 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?

Three front-loaded sentences with no filler; the core action, side effect, and authorization requirement appear immediately.

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

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

With six parameters, no schema descriptions, no annotations, and no output schema, the description is too thin to fully support correct invocation. It omits the roles of port, app_id, and target_url, as well as the exact semantics of expected_screen.

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 gives meaning to key and, loosely, expected_screen and authorized_effects. It leaves port, app_id, and target_url completely unexplained, so an agent cannot tell from the prose how to target the correct browser.

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 the action and resource precisely: send an allowlisted key (enter or escape) to the focused element on the expected screen. It implicitly separates itself from click/fill/scroll siblings by being the keyboard-key tool, though it does not explicitly name those 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?

It describes what Enter does but gives no explicit when-to-use or when-not-to-use guidance relative to pulse_browser_click, pulse_browser_fill, or desktop equivalents. The prerequisites mentioned are the focused element, expected screen, and authorized_effects write.

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

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

With no annotations, the description carries the full burden. It usefully discloses three side effects — observing the page, writing DOM controls into a spatial grid, and storing the screen — but says nothing about permissions, whether prior grid state is overwritten, or how the stored screen is keyed.

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 dense rather than wasteful, though packing three distinct actions into one clause slightly blurs the emphasis.

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 and no annotations, so the description should do more. It partially compensates by describing the observable result (a mapped spatial grid plus a stored screen), but leaves the undocumented parameters and any environment prerequisites as 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?

Three parameters (port, app_id, target_url) have 0% schema description coverage, and the description explains none of them. 'Local Chromium page' only faintly implies what port and target_url are for, and app_id is entirely 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?

The description uses concrete verbs (observe, map, store) and a specific resource (the active local Chromium page, visible DOM controls), so the agent knows exactly what the tool does. It does not, however, distinguish itself from siblings like pulse_desktop_observe or pulse_map_get, which sound similar at a glance.

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 call this instead of pulse_desktop_observe, pulse_browser_targets, or pulse_map_get. The agent must infer that observation precedes clicking/filling, and no prerequisites (e.g., Chromium running, port chosen) are stated.

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

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

With no annotations, the description carries the whole burden and does well: it discloses that each step validates its expected screen and halts on divergence, enumerates the returned fields (screen_id, title, viewport, anchor_count, anchors, screenshot_sha256) so no confirmation observe is needed, and flags that write/irreversible effects need explicit authorization. It omits what actually happens on divergence (error vs partial execution) and whether the page is left mutated.

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, front-loaded with the core action, then behavior, then return value, then the authorization caveat. The return-field enumeration is dense but each item earns its place by replacing a confirmation call.

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

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

Given no annotations, no output schema, and 0% schema coverage on 6 parameters, the description compensates well on returns and safety but leaves the parameter contract and failure mode undefined. An agent knows what it gets back but not confidently what to put in.

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 6 parameters, and the description explains almost none of them: start, target, target_url, app_id and port are never mentioned. Only 'explicit authorization' loosely gestures at authorized_effects without naming it or clarifying the write vs irreversible distinction.

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: 'Execute a previously verified route in one browser call.' The phrase 'previously verified route' plus 'in one browser call' distinguishes it from the single-step siblings pulse_browser_click / pulse_browser_observe, though no sibling is 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?

'previously verified route' implies a prerequisite (the route must already exist / be verified) and 'Write and irreversible effects require explicit authorization' implies a gate. But there is no explicit statement of when to pick this over pulse_browser_click, pulse_desktop_replay, or pulse_routine_*, and no 'when not to use' guidance.

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

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

With no annotations the description carries the full burden, and it does disclose two real traits: the delta is 'bounded' and scrolling is scoped to the expected mapped screen. It omits error behavior on screen mismatch, what happens when scrolling past the viewport edge, and the side effect implied by 'map the resulting screen'.

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 with the core action front-loaded and the scoping constraint second; no filler. The wording is slightly cryptic ('expected mapped screen') but structurally 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 6-parameter tool with no annotations, no output schema, and zero schema descriptions, the description leaves most parameters and all failure/return behavior unexplained. An agent could not reliably construct a correct call from it alone.

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, but it only gestures at dx/dy ('pixel delta') and expected_screen. Three parameters (port, app_id, target_url) are 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 (scroll) and resource (browser viewport) plus the secondary effect (map the resulting screen). It is distinguishable from click/fill/observe siblings by action, though it never contrasts itself 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?

No indication of when to choose scrolling over pulse_browser_observe or pulse_map_get, nor any when-not guidance. The only usage signal is the implicit precondition that a screen must already be mapped, which is never spelled out.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the tool both enumerates targets and reveals the default selection a later call would make, implying a read-only inspection tool, but it never states what happens if port is omitted (it is optional) or what the returned tab listing looks like.

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, zero waste, with the core function front-loaded and the follow-on guidance second. Nothing repeats the schema or title.

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

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

For a two-optional-parameter discovery tool with no annotations and no output schema, the agent still lacks the default port behavior, the shape of the returned tab list, and error conditions for an invalid or unreachable port. It is adequate to attempt a call but not to interpret the result 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 explain both parameters. It meaningfully ties `port` to a CDP port and explains `target_url` as the pinning selector for multi-tab ports, but leaves `port`'s optionality/default behavior and the matching semantics of target_url (exact URL vs. substring) undefined.

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

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

States a specific verb and resource: 'List the page tabs one CDP port serves and report which one a call would choose.' The second sentence implicitly separates it from the sibling browser action tools (observe/click/fill/scroll) by framing it as the target-discovery step that feeds target_url into those calls.

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?

Gives a clear conditional: use target_url on other browser calls 'when a port holds more than one tab,' which tells the agent both why to call this tool and what to do with its output. It stops short of explicit when-not guidance or naming the sibling tools it complements.

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

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

With no annotations, the description still discloses two important behaviors: execution is gated on the live screen matching the mapped expectation, and write effects require explicit authorization. It leaves undisclosed what happens on a mismatch (abort vs error) and whether effects are reversible, but the safety profile is substantially better conveyed than the structured fields alone.

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, the critical guard condition leading, the authorization requirement second, with no filler. Every clause carries operational weight.

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 mutation-capable desktop click with no annotations and no output schema, the description covers the safety gate but not failure behavior, effect propagation, or the app_id/application distinction. Adequate to call safely in the happy path, incomplete for edge cases.

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% across five parameters, so the description carries the full burden. It indirectly explains anchor_id, expected_screen, and authorized_effects ("write effects require explicit authorization"), but app_id and application are completely undocumented in both places, and their apparent overlap is a real ambiguity for a caller.

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 ("Click an anchored desktop control"), which clearly separates it from browser siblings such as pulse_browser_click and from the observation tools. It does not name an alternative sibling explicitly, but the desktop-vs-browser distinction 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 gives a concrete precondition for use — only click when the live desktop still matches the expected mapped screen — which implies observing first via pulse_desktop_observe. It does not state when not to use it or name explicit alternatives, so it falls short of 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the implementation path and OCR fallback when accessibility bounds are missing, but omits permissions, side effects, output shape, latency, whether capture is read-only, and whether app focus matters.

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?

Single sentence, front-loaded with the core action and no filler. It is appropriately sized for a tool of this complexity, though some implementation detail could be trimmed.

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 annotations, no output schema, and 0% parameter coverage, the description is not complete enough for correct invocation. It explains the capture mechanism but not what is returned or how app_id/application affect the observation.

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 two parameters (app_id and application), and the description never mentions them. It gives no meaning, defaults, or targeting semantics, so the agent cannot tell what these parameters select.

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 (Capture) and resource (active Linux desktop), plus supporting mechanics such as accessibility mapping and OCR fallback. However, it does not explicitly distinguish itself from siblings like pulse_browser_observe or pulse_desktop_click/replay, so sibling routing is left to inference.

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, when-not-to-use, or alternative-tool guidance is provided. The phrase 'active Linux desktop' implies a desktop context, but the description does not tell an agent when to choose this over browser observation or desktop replay/click tools.

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

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

With no annotations, the description carries the full burden and does disclose two real traits: per-step screen verification with stop-on-divergence, and an explicit authorization requirement for write effects. It omits the consequences of divergence (error vs. partial application), reversibility of 'irreversible' effects, and return 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 action and followed by the two most decision-relevant facts (verification and authorization). No filler, though the last sentence is slightly under-specified for the space it takes.

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 five-parameter execution tool with no annotations, no output schema, and zero schema coverage needs far more: parameter meaning, return shape, and divergence/failure semantics are all absent.

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

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

Schema description coverage is 0%, so the description must compensate and does not: start, target, app_id, and application are never explained, and 'explicit authorization' only vaguely gestures at authorized_effects without naming it or its 'write'/'irreversible' 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?

States a specific verb and resource: 'Execute a verified desktop route in one call.' The word 'desktop' implicitly separates it from pulse_browser_replay, but the sibling is never named explicitly. The purpose is clear without opening the schema.

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

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

Implies usage: use it with a 'verified' route, and writes need authorization. But it never says when to prefer this over pulse_browser_replay, pulse_desktop_click sequences, or pulse_map_route, nor what preconditions make a route 'verified.'

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 implies a read-only retrieval and mentions the optional full-grid expansion for one screen. With no annotations, it does not disclose permissions, failure behavior, whether the operation has side effects, or what the returned map contains.

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 front-loaded sentence with no wasted words. It communicates the core action and optional expansion efficiently.

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

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

For a tool with two parameters, no annotations, no parameter descriptions, and no output schema, the description is too sparse. It leaves app_id semantics, return content, and error conditions unspecified.

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

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

Schema description coverage is 0%, so the description must compensate. It explains screen_id as optionally including one screen's full grid, but it does not explain the required app_id or what constitutes a screen map.

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

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

The description uses a specific verb and resource: 'Read a stored screen map.' It is clear what the tool retrieves, though it does not explicitly distinguish itself from siblings such as pulse_map_route or pulse_map_record_screen.

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

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

Usage is implied by 'Read a stored screen map' and the optional inclusion of one screen's full grid. However, there is no explicit guidance on when to use this versus pulse_map_route, pulse_map_record_screen, or other map tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a write operation and mentions returning a grid, but it does not disclose persistence, permissions, idempotency, side effects, or what 'grid' contains.

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 front-loaded and free of filler, stating the core action and return value. It is concise, though extremely terse relative to the tool's complexity.

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 mutation tool with 8 parameters, nested objects, no annotations, no output schema, and no schema descriptions. The description provides only the broad purpose and a vague return reference, leaving key invocation details unspecified.

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 nested viewport and anchors objects. The description only mentions normalized anchors and does not explain app_id, url, title, viewport dimensions, rows, columns, or screenshot_sha256.

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: 'Record a screen observation' and adds that it returns a grid. It is clearer than a tautology, but it does not explicitly distinguish this from sibling tools such as pulse_map_record_transition.

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

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

The description gives no conditions for when to use this tool versus alternatives like pulse_map_get or pulse_map_record_transition. It implies recording a screen observation but provides no exclusions, prerequisites, or comparison guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that verified transitions affect route planning, but it does not explain permissions, whether recording is idempotent, what happens to unverified transitions, or what the operation 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 two short sentences with no filler. The core action is front-loaded, and the second sentence adds a meaningful constraint about verified transitions.

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 five required parameters, no annotations, no output schema, and no parameter descriptions, the description is too thin. It gives purpose and one behavioral note, but it does not provide enough context to confidently invoke the tool without inspecting or guessing from 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?

All five parameters have 0% schema description coverage, and the description only partially clarifies the 'verified' parameter's effect on route planning. It says nothing about app_id, source, target, or anchor_id, leaving most required inputs semantically 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 gives a specific verb and resource: 'Record a transition.' It also indirectly connects the tool to route planning, but it does not define what a transition is or explicitly distinguish this tool from siblings like pulse_map_route or pulse_map_get.

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

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

The only guidance is 'Only verified transitions are used by route planning,' which implies a condition for verified transitions but does not say when to use this tool versus alternatives or when not to use it. No sibling tools are named or contrasted.

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

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

With no annotations and no output schema, the description carries the full burden but only implies read-only behavior via "find". It doesn't state what happens when no verified route exists (error vs empty), what "verified" means, or whether the result includes intermediate hops.

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 well-formed sentence with the direction of travel front-loaded and zero filler. It is efficient, though the terseness is part of why behavioral and usage gaps remain.

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

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

For a 3-required-parameter tool with no annotations and no output schema, the description covers neither failure modes, prerequisites, nor the app_id parameter. An agent would have to guess at the calling conditions and return shape.

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

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

Schema description coverage is 0%, so the description must compensate: it does explain that "start" is a mapped screen and "target" may be either a screen or an anchor label, which meaningfully disambiguates two of three params. "app_id" is never explained, leaving one required parameter opaque.

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

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

The description gives a specific verb ("find") and resource ("shortest verified route") with explicit endpoints ("from a mapped screen to a screen or anchor label"), which distinguishes it from map-mutation siblings like pulse_map_record_transition. It stops short of naming an alternative tool or clarifying how routing relates to pulse_map_get.

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

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

No when-to-use guidance, no prerequisites (e.g. whether the map must first be populated via pulse_map_record_screen/record_transition), and no exclusions or alternatives among the 16 siblings. The agent must infer that this is a path-query tool used after mapping.

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

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

With no annotations, the description carries full disclosure burden; "Read" does correctly signal a non-mutating lookup. However, it says nothing about error behavior for unknown ids, what a "routine candidate" payload contains, or whether the saved routine is live or draft.

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

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

One short sentence with the lookup key front and center; nothing is wasted. The terseness borders on under-specification, which is captured in other dimensions.

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 simple single-parameter getter without an output schema needs little, but the description never explains what a "routine candidate" is or how to obtain a valid routine_id, both of which an agent needs.

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

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

Schema coverage is 0%, so the description must compensate. "by id" does map onto the sole routine_id parameter, but gives no format, source, or default guidance beyond that.

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 a saved routine candidate by id" gives a specific verb (read), resource (routine candidate), and key (id). It implicitly contrasts with pulse_routine_save and pulse_routine_list, but never names them, so the differentiation is inferred rather than stated.

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

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

There is no guidance on when to use this versus pulse_routine_list (to find an id) or pulse_routine_save (to persist one). The agent must infer from the one-liner that this is a follow-up fetch after listing.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation but it says nothing about return format, ordering, pagination, or whether routine details are included — significant gaps for a tool with zero annotation coverage.

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 wasted words. Appropriately sized for the tool's simplicity.

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 annotations and no output schema, the description should describe what is returned (candidate fields, count, ordering), but it stops at restating the action. Inadequate for a list tool where the agent needs to know the response shape.

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

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

Schema coverage is 0%, so the description must compensate; it does clarify the single param's purpose as an application filter. However, it doesn't specify the expected format of app_id (bundle id, package name, etc.), leaving a meaningful 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 (List) and resource (saved routine candidates) with an optional filter. It is distinguishable from siblings like pulse_routine_get and pulse_routine_save, though it doesn't explicitly contrast itself with them.

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

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

The phrase 'optionally filtered by application' implies when to pass a filter, but there is no explicit guidance on when to use this vs pulse_routine_get, nor any prerequisites or 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the saved routine becomes a reviewable candidate and is not executed, but omits important behavior such as permissions, overwrite or duplicate handling, validation, and what happens to the provided evidence and final state.

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

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

The description is a single efficiently structured sentence with the action and the key non-execution constraint front-loaded. There is no wasted wording.

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 six required parameters, no annotations, and no output schema, the description is too sparse. It gives the high-level purpose and the important non-execution behavior but lacks the parameter, validation, and persistence details an agent needs 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?

The schema has six required parameters and 0% description coverage. The description mentions verification and candidacy at a high level but does not explain any parameter, including id, app_id, steps, final_state, or evidence, so it does not compensate for the schema gap.

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

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

The description states a specific verb and resource: saving a routine. It also clarifies the resulting artifact is a reviewable candidate and that execution is not performed, making the core purpose clear. It does not explicitly differentiate from sibling routine tools, 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?

The phrase 'successfully verified routine' implies a precondition for calling the tool, and 'this does not execute it' clarifies one boundary. However, it does not name alternatives or explain when to use this instead of related routine or map tools, leaving usage guidance implied rather than explicit.

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