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

Annotations cover the safety profile (destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds substantial context beyond them: cursor movement, auto-scroll, a visible click highlight in the video, possible navigation side effects, and a named failure mode (ELEMENT_OBSCURED) that names the covering element. Only retry/timeout behavior is left unstated.

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

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

Three sentences, no filler, and the primary action is front-loaded ahead of side effects and error behavior. Every clause carries information an agent needs.

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

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

With no output schema, the description usefully discloses that it reports a started navigation, and it documents the main failure mode. It stops short of covering timing, retries, or what the navigation report actually contains, but is otherwise sufficient for a one-parameter click tool.

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

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

There is a single parameter with 100% schema description coverage; the schema already explains the ref format and its provenance. The description adds no ref-specific semantics, so the baseline 3 applies.

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 (click) and resource (element), and the mechanism is fully spelled out: moves the visible cursor, scrolls into view if needed, and clicks. This is clearly distinguishable from siblings such as type, press, scroll, and navigate.

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 the precondition (a ref from the latest snapshot, per the schema) and gives recovery guidance via ELEMENT_OBSCURED, but never states when to choose click over press, type, or navigate. Usage is implied rather than explicitly framed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; "safe to call any time" largely restates it. The description does add genuine behavioral context by naming the recorder states (idle, starting, recording, paused) and the permission surface it inspects, which matters since there is no output schema to enumerate return 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?

A single dense sentence front-loads the core answer (connected + what the recorder is doing) with no filler. The trailing "Safe to call any time" is slightly redundant with readOnlyHint=true, a minor cost.

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

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

With no parameters and no output schema, the description carries the return-value burden and does enumerate the reported fields and state values. It omits the shape of the response (nesting, how permissions are represented), which keeps it below a 5.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The sentence about what it inspects is not a parameter concern.

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 (report) and resource (recorder/extension status) and enumerates exactly what is reported: connection state, recorder state, mode, active tab, permissions. It is clearly distinct from the mutation siblings stop_recording, pause_recording, and resume_recording.

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?

"Safe to call any time" gives a clear condition for use with no exclusions needed for a read-only status check. It does not route the agent to related siblings such as probe_capture for permission probing or to start_recording for state transitions, 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?

Adds useful context beyond annotations — namely that it waits for load, returns the final URL and title (important after redirects), and that prior snapshot refs are invalidated ('Refs from earlier snapshots stop working'). That last point is a real consequence an agent needs. However, it doesn't mention that this is a state-changing navigation (readOnlyHint=false) that could trigger page-level side effects, or any auth/rate considerations. Reasonable but not rich.

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

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

Three short sentences, front-loaded with the core action and scope, then the return value, then the caveat about snapshot refs. Every sentence earns its place with no filler.

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

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

Covers the key facts an agent needs: it's an http(s) navigation in the recorded tab, it waits for load, what it returns, and that snapshot refs are invalidated. No output schema exists, and the description compensates by naming the return values. Could be slightly stronger on when navigation alone is sufficient versus when a wait_for is needed, but it's solid.

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% — both url and timeoutMs are fully described in the schema, including maxLength, min/max bounds, and default. The description adds nothing about parameters beyond what the schema provides, which is the baseline 3 when the schema does the heavy lifting.

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 ('Open') and resource ('http(s) URL'), plus the critical scoping detail that it happens 'in the tab the user handed to Recordful'. This distinguishes it clearly from siblings like click, snapshot, or get_status, which operate on an already-loaded page.

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?

Positions the tool implicitly as the entry point to a browsing session — you navigate before you snapshot, click, or type. It doesn't explicitly say 'use this first' or name alternatives for loading content, but the workflow context is clear enough for an agent to place it correctly among the recording/browsing siblings.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description's 'No-op if already paused' largely restates the idempotency hint, and it omits behavior such as what happens if no recording is active or what state changes occur internally.

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, followed by usage guidance and an important edge-case note. No filler or redundancy.

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

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

For a no-parameter tool with annotations covering safety and idempotency, the description is nearly complete. It is slightly light on edge behavior when no recording is in progress, which would help an agent know whether a call is meaningful.

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

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

There are zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are needed for this tool.

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

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

The description states a specific verb and resource: 'Pause the current recording.' The action is unambiguous and naturally distinguished from resume/stop/start siblings, 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?

It gives a concrete when-to-use scenario ('while you plan the next step so the video has no dead air'), which is clear context. It does not, however, name alternatives like stop_recording or resume_recording or state when not to use it.

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

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

Annotations declare non-readonly, non-idempotent, open-world behavior, so the safety bar is partly covered. The description adds genuinely useful disclosure beyond that: the key press triggers the page's real effect (submitting, moving focus, deleting) because synthetic keys are otherwise ignored, which explains the non-idempotent side effects and warns of consequential actions.

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 capability and its examples are front-loaded in the first sentence, with the behavioral caveat following. It is dense but every clause carries information; only the double-embedding of examples and the parenthetical aside slightly dilute readability.

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 single-parameter tool with no output schema and rich annotations, the description covers purpose, valid inputs, and side-effect behavior. It omits edge cases such as pressing keys with no focused element or a missing target, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100% and the schema already enumerates valid keys, modifiers, and the regex pattern. The description's examples mirror that content rather than adding new semantics (e.g., no guidance on focus requirements, timing, or what happens when no element is focused), so baseline 3 applies.

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 ("Press a key in the focused element") and immediately grounds it in recognizable scenarios (submit, move focus, close dialog, menu navigation). It is trivially distinguishable from siblings like click, type, and scroll, which operate on different targets.

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 examples effectively communicate when to reach for this tool rather than type or click, and the modifier syntax (Shift+Tab, Control+a) tells the agent what shapes of input are expected. There is no explicit statement of when NOT to use it or a named alternative, 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?

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description adds real value: it states the operation is non-recording, requires no user click, and is refused during an active recording. That refusal constraint is meaningful behavioral context an agent would otherwise miss.

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 dense sentence front-loaded with 'Diagnostic:' and with no wasted clauses — each sub-clause (no user click, permission scope, recording refusal) earns its place.

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

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

For a read-only, single-optional-param diagnostic with no output schema, the description conveys what the check evaluates (capture feasibility and permission grants). It stops short of describing the return shape, but the tool is simple enough that this is a minor gap.

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

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

Only one parameter, tabId, and schema description coverage is 100% with the default behavior (active tab of last focused window) fully documented in the schema. The description adds nothing beyond the schema, so the baseline 3 is appropriate.

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

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

Names a specific verb (check) and a precise resource (whether the extension can capture the target tab without a user click, plus which optional Chrome permissions are granted). This clearly distinguishes it from siblings like get_status, screenshot, or start_recording.

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 'Refuses while a recording is running' clause is an explicit when-not condition, telling the agent this is a pre-recording diagnostic. It doesn't name an alternative tool for the same check, but the context is well established.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The no-op clause adds a concrete edge-case behavior (wrong-state calls neither error nor mutate), which is useful but closely overlaps the idempotent hint; nothing is said about permissions or the resulting recording 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?

Two sentences, no filler, with the action first and the edge-case caveat second. Every clause earns its place.

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

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

For a no-parameter, no-output-schema control tool with annotations covering safety, the description supplies what an agent needs to call it correctly. It is slightly thin on what state the recorder is left in after the call, but nothing essential is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies.

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

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

States a specific verb+resource ("Resume a paused recording") and the word "paused" implicitly distinguishes it from the sibling start_recording, which begins a new capture. An agent can pick the right tool without opening any 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?

"No-op if not paused" gives a clear usage condition and tells the agent it is safe to call opportunistically without checking state first. It stops short of explicitly naming the alternatives (pause_recording/stop_recording) or stating exclusions, so it is strong context rather than 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?

Annotations declare readOnlyHint and openWorldHint, so the safety profile is already covered. The description adds a real operational precondition not present in the annotations: the tab must be the active tab of its window, plus the 'right now' timing semantics that imply a live capture. It does not describe return format, but no output schema is needed for an image.

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, no filler, with the core action and its purpose front-loaded and the precondition placed second. Every clause earns its place.

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

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

For a zero-parameter read tool with annotations covering safety and no output schema, the description supplies purpose plus the one precondition an agent must satisfy. It stops short of relating itself to the surrounding flow (navigate, wait_for, snapshot), but nothing critical to invoking it is missing.

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

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

The tool takes zero parameters, which is the baseline-4 case. There is nothing parameter-wise the description needs to compensate for, and it correctly avoids inventing arguments.

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 (what the recorded tab shows now) plus the output form (as an image), so the agent knows this returns a picture rather than data. It does not explicitly differentiate itself from the similarly named sibling 'snapshot' or 'probe_capture', leaving a small ambiguity about which one produces an image.

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?

'to check the page looks right' implies a verification use case, which is decent context. However, it never tells the agent when to prefer this over siblings like snapshot or probe_capture, nor when not to use it.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds the genuinely useful behavioral detail that scrolling is smooth and that amount defaults to most of a screen, but says nothing about the viewport change affecting later screenshot/snapshot output or about any 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?

A single front-loaded sentence that covers the verb, both modes, and the default magnitude with no filler. The phrasing 'by amount pixels' is slightly awkward but costs nothing in length.

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

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

For a 3-param, no-output-schema tool the description covers both modes and the amount default adequately for correct invocation. It omits where refs originate (presumably the sibling snapshot tool), a minor but real gap for an agent that has not yet captured one.

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

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

Schema description coverage is 100%, so ref, amount and direction are already documented, including the default and the enum. The description restates the same facts ('by amount pixels or most of a screen') without adding format, range, or interaction detail beyond the schema, which is the baseline-3 case.

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) plus resource (page/element) and decomposes the tool into its two operating modes: bring a ref into view, or scroll the page in a direction. The scope is unambiguous, though it never names or distinguishes itself from siblings like navigate or snapshot.

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?

"Either bring an element (ref) into view, or scroll the page in a direction" explicitly frames the two mutually exclusive usage modes and which parameter selects which. It gives no exclusions, prerequisites, or named alternative tools, 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real behavioral context beyond them: refs persist while an element remains on the page, which explains the non-idempotent listing behavior flagged by idempotentHint=false. It does not mention limits or truncation on very large pages.

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

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

Two sentences, both front-loaded: the first leads with what is listed and what each entry contains; the second carries the ref-stability caveat. Every clause earns its place with no redundancy.

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

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

There is no output schema, so the description correctly carries the full burden of describing the return shape (ref, role, accessible name, value/state, bounding box in CSS pixels). It omits the 'scope' parameter and any behavior for very large pages, but is otherwise complete for a single-optional-param read tool.

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

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

Schema description coverage is 100% and the single 'scope' enum is fully documented in the schema itself (page vs viewport). The description adds no information about the parameter, so the baseline of 3 applies.

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 ('interactive elements ... and headings in the recorded tab'), and enumerates the element kinds and the exact fields returned. An agent can distinguish it from screenshot (visual capture) and from click/type (which consume the refs this tool emits).

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 'each with a ref to pass to click/type/scroll/wait_for' makes the workflow role explicit: call this to obtain refs for the interaction tools. However, it never states when NOT to use it (e.g. versus screenshot for visual inspection) or any prerequisite about recording state.

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

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

Beyond the annotations, it discloses meaningful behavior: settings are pulled from the user's saved Recordful config (mode, microphone, camera, countdown), that the promise resolves once capture is actually live, and that it reports failure reasons. Annotations only carry safety hints, so this additional state-machine context is genuinely valuable; it stops short of 5 only because it doesn't mention permissions or rate/side-effect details.

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 resource, followed by resolution semantics and the sequencing precondition. Every sentence earns its place with no filler.

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

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

For a no-required-parameter action tool with full schema coverage and safety annotations, the description covers what it does, what config it applies, how it resolves, and when to call it. It could be more complete by noting what happens on an already-recording tab or linkage to pause/stop, but it is essentially sufficient to invoke 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 both parameters (tabId, timeoutMs) are fully documented in the schema, making the baseline 3 appropriate. The description adds only indirect context (settings come from saved config) without clarifying parameter behavior beyond the schema.

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

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

States a specific verb and resource ('Start a Recordful recording on the target tab') and distinguishes itself from siblings by naming the state transition it performs versus stop_recording/pause_recording/resume_recording. An agent can route to the correct tool from the description alone.

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

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

Gives a clear prerequisite/precondition for success ('Navigate to the page you want to show before calling this'), which explains when and how to sequence this against the navigate sibling. It does not explicitly name when not to use it or point to alternatives, so it stops short of 5.

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

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

Annotations state destructiveHint=false and readOnlyHint=false, but the description adds the key non-obvious behavior: stopping also opens the editor exactly as a manual Stop click would. This side effect is real added value beyond the annotations. It doesn't cover timeout semantics, but the schema does.

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, front-loaded with the core action, followed by the editor side effect and return value. No filler.

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

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

A single optional-param, no-output-schema tool with annotations covering safety. The description covers the essential side effect and return shape (editor tab ID when known). Lacking only explicit precondition (recording in progress) and behavior when no recording is active.

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?

Only one optional parameter (timeoutMs), and schema coverage is 100% with its own description. With zero required params, the baseline is 4; the description adds no param detail but nothing is needed.

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

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

States a specific verb+resource (stop the current Recordful recording) and is clearly distinguished from siblings like start_recording, pause_recording, and resume_recording. The agent knows exactly which lifecycle action this performs.

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?

Implied usage is clear from the name and the surrounding recording lifecycle siblings, but the description never explicitly states when to prefer this over pause_recording (temporary halt vs. finalize) or that a recording must be in progress. Minor ambiguity remains for the stop-vs-pause decision.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds behavior not in the structured data: that a click is performed first, that typing occurs at a human pace, and that without 'clear' text is appended rather than replacing. It does not disclose failure modes or what happens with an invalid ref.

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, front-loaded with the core action, then the replace option, then the alternative tool. Every sentence carries distinct information with no repetition.

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 4-parameter interaction tool with full schema coverage and annotations, the description covers purpose, target element types, key parameter intent, and the sibling alternative. Only error/edge-case behavior (stale ref, non-editable element) is 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 100%, so the schema already documents ref, text, clear, and delayMs with defaults and bounds. The description only echoes the 'clear' semantics ('replace what is already there') and adds nothing about ref or delayMs, so the baseline 3 applies.

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 ('Click the field, then type the text') and scopes the supported targets (text inputs, text areas, content-editable areas). It is clearly distinguishable from the sibling 'press', which it explicitly names as the tool for non-text keys.

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 routing rule: 'Use press for Enter, Tab and other keys', which tells the agent when to pick the alternative. It also explains the 'clear' choice for replacing existing content. It lacks guidance on failure/edge cases (e.g. stale refs) or when to prefer click/scroll instead.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld, non-idempotent), and the description adds genuinely useful behavior: it keeps waiting across navigations and fails with WAIT_TIMEOUT rather than hanging. It stops short of describing what a successful wait returns, though no output schema exists to cover that.

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

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

Two sentences, front-loaded with the primary success condition and followed by the failure mode. Every clause carries information; nothing is padding.

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

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

For a four-parameter, no-output-schema wait tool, the description covers the core trigger conditions, the hidden-state variant, cross-navigation persistence, and the timeout failure. The only gap is return value on success, which is minor for a blocking primitive.

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 100% — text vs ref exclusivity, case-insensitive matching, the state enum, and the timeout default/range are all documented in the schema. The description restates the state semantics but adds no syntax or format detail beyond it, so the baseline of 3 applies.

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) and the two triggering resources (text on page, element ref), plus the inverse mode (state "hidden"). Nothing in the sibling list does the same thing, so an agent can route to it unambiguously.

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 the description — you call it when you need to block until content appears or disappears — but there is no explicit when-to-use versus siblings like snapshot or get_status, and 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.