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

With no annotations, the description carries full burden, and it does disclose two real behavioral traits: no retry/healing on failure and per-action ok/error/timing results. It omits whether execution halts on the first error versus continuing through the remaining actions, and says nothing about what page state the actions mutate.

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 clipped sentences, no filler, with the action list front-loaded ahead of the failure-mode caveat and the return shape. Every sentence 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?

No output schema exists, and the description does cover the return shape (per-action ok/error/timing), which is the most valuable thing it adds. However, for a mutation-heavy execution primitive with zero annotations, the meaning of stage_id and the error-handling policy (stop vs continue) are left unaddressed.

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

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

Schema description coverage is 0% at the top level: stage_id is completely undefined in both schema and description, and timeout_ms has no explanation. The description restates the action type enum already present in the schema, so it adds almost nothing beyond structured fields for the parameters that genuinely need explanation.

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 (execute) and resource (an ordered list of click/fill/press/hover/select/scroll actions) scoped to a stage, which clearly separates it from capture, wait_for, and measure. It does not name a sibling it differs from, so sibling differentiation is implicit rather than explicit.

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 extra steps, no retries, no healing" implies this is the raw low-level primitive, contrasted implicitly with the higher-level scenario_run sibling, but the description never says when to prefer one over the other or what prerequisites apply. Usage is inferable, not stated.

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

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

With no annotations, the description carries the full burden and does disclose two important traits: it is user-visible (opens a window with an overlay, a visible side effect) and it is asynchronous (returns immediately, requires polling). It omits cleanup/teardown behavior (whether stage_close ends the session) and what happens if a session is already active, so not fully transparent.

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

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

Two tightly packed sentences: the action comes first, then the asynchronous follow-up. No filler, no restatement of the title, 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?

There is no output schema, so the description should indicate what the call returns to make the polling instruction actionable (e.g., a session id or status token) — it does not. Cleanup/termination and required parameter meaning are also missing. It is adequate for the happy path but leaves gaps for a stateful UI side-effecting 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% across three parameters (url, width, height), and the description mentions none of them. An agent gets no explanation of what url refers to (the app page to overlay?) or what units/conventions width and height follow, so the description 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?

States a concrete action and outcome: opens a visible window with a drawing overlay for the user to mark parts of the app and attach notes. That is clearly an annotation-session starter, distinct from read-only siblings like annotations_list or annotations_get. It does not explicitly contrast with stage_open, which also opens a visible window, leaving a small ambiguity for an agent choosing between 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?

Gives explicit lifecycle guidance: the call returns immediately and the agent should poll annotations_list until status is ready. That is a real when/how-to-use instruction pointing at a named sibling. It lacks any exclusion or precondition (e.g., what to do if a session already exists), so it stops short of full routing 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 clarifies the return payload, which is useful because there is no output schema, but it does not state error behavior for a missing/invalid ID, permissions, or explicitly confirm read-only side-effect-free behavior.

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

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

A single front-loaded sentence names the returned bundle and lists the key contents without filler. Every phrase 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?

The description compensates for the missing output schema by listing returned fields, which is valuable for a getter. However, it leaves the sole parameter undocumented and does not cover missing-record behavior or usage context, leaving clear gaps for an agent.

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 required parameter, annotation_id, is not mentioned in the description. The parameter name is self-explanatory, but the description adds no meaning about its format or expected value.

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

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

The description states a clear verb ('Return') and resource ('an annotation bundle'), and enumerates the bundle contents (element, rect, note, cropped images). It does not explicitly differentiate itself from siblings such as annotations_list or annotations_resolve, so it falls short of a 5.

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

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

There is no explicit guidance on when to use this tool versus alternatives like annotations_list or annotations_resolve. The retrieval intent is implied by 'Return', but no conditions, exclusions, or alternatives 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a read-only listing and mentions that marks and notes are returned verbatim, but it omits pagination, ordering, permission requirements, and whether the optional status argument filters the list or just describes returned status values.

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 and front-loads the core purpose. The second sentence about verbatim marks and notes is useful. There is little wasted text, though the description could be slightly more explicit about the listing behavior without becoming long.

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 simple listing tool with one optional enum parameter and no output schema, so the description does not need to explain return values in depth. However, it leaves out how status filtering works and whether there are pagination or ordering constraints, which are relevant for an agent invoking a list endpoint.

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 optional status parameter is only documented by its enum values. The description does not explain that status filters sessions, what 'all' means relative to the other enum values, or whether omitting the parameter is equivalent to 'all'. It therefore fails to compensate for the schema coverage gap.

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

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

The description states a specific verb and resource: listing annotation sessions and their status. It also adds that marks and notes are returned verbatim, which clarifies the result content. It does not explicitly distinguish itself from the sibling annotations_get, but the basic purpose is clear.

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 tool versus annotations_get, annotations_resolve, or annotate_start. The description implies a listing operation but does not state whether it lists all sessions by default, how the status argument should be used, or when another sibling is more appropriate.

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 state-changing operation ('mark as handled') but says nothing about permissions, whether resolution is reversible, whether the annotation remains retrievable afterward, or what the note is used for beyond 'how it was addressed'.

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 filler. However, its brevity contributes to the missing behavioral and parameter detail rather than being purely 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 mutation tool with no annotations, no output schema, and entirely undocumented parameters, the description is too sparse. It does not explain the effect on annotation state, the expected note content, or what the caller should expect after invocation.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It only indirectly hints that 'note' records the resolution rationale; 'annotation_id' is never explained, and no format, length, or requiredness details are given.

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: 'Mark an annotation as handled' and 'record how it was addressed', which is clearer than the title alone. It does not explicitly separate itself from siblings such as stage_close or findings_store, so sibling differentiation 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?

There is no statement of when to use this tool versus annotations_get, annotations_list, stage_close, or findings_store. The intent can be inferred from 'mark as handled', but there are no explicit conditions, 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?

No annotations exist, so the description carries the full disclosure burden. It usefully says the result includes a timestamp and an image block, but it says nothing about prerequisites (must a stage be open? does it change focus?), side effects, or any capture limits.

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 written sentences with the core action front-loaded and no filler. Nothing in it 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 return shape is partially covered, which matters since there is no output schema, but with zero annotation coverage and an undocumented nested parameter, an agent still lacks enough to invoke it confidently in edge cases like full_page.

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, including a nested clip object. The description only hints at stage_id via 'current stage' and never explains the clip region or what full_page toggles (full document vs. viewport).

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: 'Take a PNG of the current stage', plus what it returns (an image block plus metadata). It is clear what the tool does, but it never names the neighboring tools (stage_state, measure, diff) it is meant to be distinguished from.

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 clause 'it does not judge the frame' draws a scope boundary, implying evaluation belongs elsewhere, but neither the alternative tools nor the conditions for choosing them are stated. Usage 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns changed pixel counts and a bounding box and writes a diff image, and that it does not judge acceptability. However, it omits important behavioral details such as where the image is written, overwrite behavior, permission requirements, or what happens when no baseline exists.

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

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

The description is three tight sentences with no wasted language. It front-loads the core comparison, then states return values and side effects, then adds the key limitation.

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

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

For a two-parameter tool with no annotations or output schema, the description covers the main action, return summary, side effect, and a boundary condition. It still leaves gaps around parameter semantics, baseline-missing behavior, image output location, and overwrite behavior.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. The phrase 'named capture from a run' only implicitly maps to name and run_id; it does not explain expected ID formats, whether run_id refers to a specific run record, or how capture names are scoped.

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 and resource: comparing a named capture from a run against the promoted baseline for its scenario. It is clearly a visual diff operation, but it does not explicitly distinguish itself from siblings such as capture, measure, or scenario_run.

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 the tool is used: comparing a capture to its baseline. It also states a useful boundary, 'Does not decide if the change is acceptable,' but it does not name alternative tools or give explicit when-to-use/when-not-to-use routing 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 usefully discloses that this is a write/persist operation and explicitly excludes grading, dedupe, and resolution, but omits idempotency, append-vs-replace behavior, permission requirements, and error handling.

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 tight sentences with the core action and boundary stated up front. Every sentence adds useful scope information without 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?

With no annotations, no output schema, and sparse parameter documentation, the description should do more. It does not explain return behavior, run_id semantics, duplicate handling, or what happens to verdict 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 only 33%. The description restates that each finding needs a claim and at least one evidence reference, which the schema already enforces, and says nothing about run_id, verdict, selector, or step.

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: persist findings. It also draws a clear boundary by saying it does not grade, dedupe, or resolve, though it does not explicitly name 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?

Implies the tool is used when the caller has findings to store and is not for grading, deduplication, or resolution. However, it does not state when to prefer this over sibling tools or mention prerequisites such as a valid run_id.

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 does disclose that every rule returns its definition and threshold, which is genuinely useful output context. However, it never states that this is a non-mutating read, whether it navigates or waits, or how long a run takes, leaving the mutation/safety profile to inference.

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

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

Two dense sentences with the rule inventory front-loaded, and no filler. The closing claim about rule definitions and thresholds is slightly terse but still earns its place by describing output shape.

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, no-output-schema tool, the description mostly suffices: it substitutes for an output schema by describing that results are per-rule with definitions and thresholds. It is still incomplete on the stage_id contract and on the precondition of an open, loaded stage.

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 single parameter stage_id has 0% schema description coverage, and the description never mentions it at all — not what a stage is, how to obtain an id, or what happens if it refers to a closed stage. The description therefore fails to compensate for the documentation 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 ('run rule-based measurements') on a specific resource ('the live page') and enumerates the exact rule categories covered: overflow, broken images, missing alt, tap targets, clipped text, plus console/page/network errors. This is clearly distinguishable from siblings like capture (visual snapshot) or diff (comparison).

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 guidance on when to use this versus capture, diff, or act, and no exclusions or prerequisites stated beyond the implicit hint that a live page must exist. The agent must infer that a stage must be open and the page loaded before measuring.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: 'Steps are never invented, repaired, or retried' — so a failing step aborts rather than being silently recovered. It also states where runs are stored. Missing are permission requirements, timeout/failure semantics, what happens to a partially completed run, and what the caller receives back.

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 core behavior front-loaded and the important constraint (no invention/repair/retry) placed last for emphasis. 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?

This is a complex, nested-step composite tool with no annotations and no output schema, yet the description says nothing about what a run returns, how to reference captured frames afterward (diff/baselines), or failure behavior beyond 'no retry'. For this complexity level it is under-specified.

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 only 20%, so the description should compensate, but it covers just url and steps generically. It never explains width/height, timeout_ms, selector, the action enum, or that `name` keys baselines — the sole field the schema itself annotates.

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 compound action: open a URL, execute supplied steps, capture frames, and persist a run under qa/runs/<run_id>. That is concrete and distinguishable from atomic primitives, but it never names the sibling tools (act, capture, diff) it relates to, leaving the differentiation 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?

There is no when-to-use or when-not-to-use language. An agent must guess whether to drive a flow with scenario_run or compose it from act/capture/wait_for; the description offers no routing signal, 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 burden of behavioral disclosure. It identifies the action as closing a stage and browser context, implying a mutation, but omits critical details like irreversibility, side effects, authentication needs, or what happens to associated resources.

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 is appropriately sized for a simple tool, though its brevity contributes to gaps 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?

Given the lack of annotations, output schema, and parameter documentation, the description is insufficient. It states what the tool does but leaves out essential behavioral and usage context that an agent would need 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% for the single parameter stage_id. The description does not mention the parameter at all, adding no meaning beyond the schema's type and required flag.

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

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

The description states a specific verb (close) and resource (stage and its browser context), making the tool's action clear. However, it does not explicitly differentiate from sibling tools like stage_open or stage_focus, 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 description provides no guidance on when to use this tool versus alternatives, such as stage_open or stage_focus. There are no stated conditions, 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 burden. It discloses the core behavior (moving an off-screen window and focusing it) but does not mention side effects such as focus stealing, error behavior if the stage does not exist, or what the tool returns. For a simple one-parameter action, this is partially transparent but incomplete.

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 states the action and outcome immediately.

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

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

For a simple tool with one parameter and no output schema, the description covers the essential action but omits return behavior and failure conditions. It is minimally complete but does not fully substitute for missing annotations or schema documentation.

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 single parameter 'stage_id' is undocumented in the schema. The description refers only to 'a stage window' and does not explain what stage_id represents, its expected format, or where to obtain it. The parameter name is somewhat self-explanatory, but the description adds little.

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: moving a stage window from off-screen to the visible desktop and focusing it. This is clear and distinct from a generic 'open' action, though it does not explicitly contrast itself with siblings like stage_open or stage_state.

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

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

The phrase 'from off-screen to the visible desktop' implies when this tool is appropriate, but it does not explicitly state when to use it versus alternatives such as stage_open or stage_close. Usage is implied rather than prescribed.

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

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

With no annotations, the description carries the full behavioral burden and does reveal two real traits: the window is parked off-screen by default and a stage_id is returned. It omits whether multiple stages can coexist, what a well-formed vs. rejectable URL looks like, error behavior, and whether the caller must eventually close the stage, leaving meaningful gaps for a stateful browser tool.

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

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

Four short sentences, front-loaded with the core action and its side effect, then the return value. There is no filler; the final 'Does not choose what to test' line is slightly cryptic but still earns its place as a scope disclaimer.

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 the description compensates by naming the returned stage_id. For a single-required-parameter setup tool, the remaining omissions (errors, multi-stage concurrency) are minor enough that an agent can call this 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 coverage is 100%, so url, width, height, and hidden are all documented with defaults and bounds in the schema itself. The description only echoes the hidden parameter's effect ('parked off-screen unless hidden=false') without adding format, interaction, or edge-case detail beyond what the schema already says.

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 ('Open a URL in a real browser window') and adds an ownership scope ('owned by this server'), which separates it from generic browsing. The closing line 'Does not choose what to test' distinguishes it from orchestration siblings like scenario_run, though no sibling is named outright.

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?

'Does not choose what to test' implies this is a low-level setup primitive rather than a test driver, which is useful directional guidance. However, it never states when to call this versus stage_focus, stage_state, or scenario_run, nor any preconditions such as pairing with stage_close for cleanup.

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. 'Report' strongly implies a read-only operation, and the description usefully enumerates the returned state fields, but it does not explicitly state side effects, permissions, rate limits, or whether any state is modified.

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 filler. Every listed field contributes useful information about what the tool reports.

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

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

The tool is simple, and the description adequately enumerates the returned fields in the absence of an output schema. However, it leaves the required stage_id parameter undocumented and provides no usage context, which are meaningful gaps for an agent deciding whether and how to invoke 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?

Schema description coverage is 0%, and the description never mentions the required stage_id parameter, its format, or how to obtain one. The parameter name is self-explanatory, but the description does not compensate for the missing schema 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 uses a specific verb ('Report') and clearly states the resource: state information for a stage, including URL, viewport, capture staleness, and error counts. It is distinguishable from mutation siblings like stage_close or stage_open, though it does not explicitly compare itself to stage_focus or capture.

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 that this is a status-inspection tool by listing the reported fields, but it gives no explicit guidance on when to use it versus alternatives such as stage_focus, capture, or scenario_run. There are no stated preconditions 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?

No annotations exist, so the description carries the full behavioral burden, and it only discloses one trait (no implicit ready check). It does not say what happens on timeout (throw, return false, empty result), whether waiting is blocking, what the default timeout is, or whether both conditions must be met — all critical for a wait primitive with no output schema.

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 primary condition and timeout bound front-loaded, and the 'no implicit ready heuristic' caveat placed immediately after as a genuine behavioral clarification. Nothing is padded.

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 four-parameter tool with zero schema coverage, no annotations and no output schema, the description leaves meaningful holes: required stage_id, timeout failure behavior, and combined-condition semantics. An agent can guess the happy path but cannot predict the failure path or the required identifier.

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 define all four parameters. It conveys the meaning of selector, text and timeout_ms at a rough level, but stage_id — the only required parameter — is entirely unexplained, and it never clarifies whether selector and text are ANDed or alternatives.

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 (wait) plus the two concrete conditions it resolves on (selector visible, text appears) and the timeout bound, so the action is unambiguous. It does not name or contrast any sibling (act, capture, measure, stage_state), but the semantics are distinct enough that an agent can place it without opening a 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?

The line 'There is no implicit ready heuristic' implies you must call this before acting, which is a useful usage cue. However, it never says when to prefer selector vs text mode, whether both may be supplied, or which sibling to use instead if the condition is already satisfied.

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