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

Beyond the destructiveHint/openWorldHint annotations, the description discloses side effects: scrolls into view, dispatches a real press/release at centre, returns {clicked}, and fails loudly with 'Element not found' instead of silently mis-clicking. This is behaviorally 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?

Four short, information-dense sentences with no filler; the core action and target are front-loaded, and the distinctive behaviors follow. Every sentence 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?

Despite no output schema, the description reports return shape, error behavior, selection alternatives, and event semantics, giving an agent everything needed to call it correctly. tabId is left to the schema, which documents it, so no important gap remains.

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 already covers all parameters (100%), and the description adds the selector-vs-ref relationship and that refs come from session_snapshot. However, it says 'or by an @eN ref' while the schema marks selector as required, so the relationship is not fully consistent; an agent could pass only ref and fail validation.

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 the specific action ('Click'), the target element, and the two ways to identify it (CSS selector or @eN ref), so an agent immediately understands the operation. It also differentiates from sibling tools by emphasizing a real mouse press/release rather than synthetic event dispatch.

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 clear context for when to use the tool: when an element needs to be clicked with real input events ('handlers that ignore synthetic events still fire') and when a ref from session_snapshot is available. It does not name alternative sibling tools or state exclusions, but the behavior description makes selection straightforward.

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?

Goes well beyond the annotations by disclosing that closing a tab is not undoable, that the active tab is the one the user is looking at, and that the T3rnel Browser extension is required while the standalone browser refuses the call. These details match and enrich the destructiveHint annotation.

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 concise sentences that front-load the action and return value, then add essential caveats. Every sentence contributes meaningful information, from the id source to the irreversibility and environment restriction.

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?

Despite having no output schema, the description states the return shape. It also covers prerequisites, side effects, environment requirements, and the unique no-default behavior, making the tool fully actionable for a one-parameter destructive operation.

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 input schema already documents tabId as the tab to close from session_list_tabs, and the description primarily repeats that provenance. It adds the no-default context, but that is more behavioral than parameter-specific, so the schema-coverage baseline of 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?

States a specific verb ('Close'), a clear resource ('a tab'), and the required source of the identifier ('from session_list_tabs'). It also distinguishes itself from sibling tools by explicitly calling out that tabId is required and there is no active-tab default.

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?

Provides clear context by directing the agent to obtain the tab id from session_list_tabs and warns that this tool, unlike every other session tool, requires an explicit tabId. It does not explicitly name alternative tools or list exclusions beyond the active-tab contrast, but the guidance is sufficient for correct selection.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond that: return value formatting (JSON, strings, 'undefined'), and the critical warning that a trailing statement returns nothing useful. No contradiction with annotations.

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

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

The description is compact, front-loads the core action, then provides usage context, return semantics, and a practical code-writing tip. Every sentence adds value without repetition or fluff.

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

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

For an arbitrary JavaScript execution tool with no output schema, the description sufficiently covers what the tool does, when to use it, how to format code, and what return values look like. Combined with the annotation's destructive hint and the schema's tabId documentation, nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining completion-value behavior and advising the agent to end with the expression it wants back, reinforcing and extending the schema's parameter description.

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

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

The description opens with a specific verb and resource: 'Run JavaScript in the page's own context and return its completion value.' It also differentiates itself from siblings by giving concrete use cases (computed styles, walking data structures, conditions too specific for session_wait), which lets an agent distinguish it from other session tools.

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

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

Explicitly says 'Use it for what the other tools do not cover' and lists example scenarios, directly naming session_wait as an alternative for certain checks. This gives clear when-to-use guidance, though it lacks an explicit 'when not to use' list for other 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?

Beyond annotations, the description discloses that it writes through the native value setter, fires input and change events, and returns {filled} naming the field. It also clarifies support for rich-text editors. This is meaningful behavioral context not present in the annotations or 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?

Three dense sentences: the action and target, the mechanism and why it works, and the return value plus alternative routing. No filler, and the most important information is front-loaded.

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 has no output schema, but the description explicitly names the return value, {filled}. It covers the behavioral mechanism, supported field types, exclusions, and alternatives, making it complete for an agent deciding whether and how to call this 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%, so the schema already documents selector, value, ref, and tabId. The description does not add per-parameter detail beyond what the schema provides, 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?

The description starts with a specific verb and resource: 'Set a form field's value', and expands the target to input, textarea, and rich-text editors. It also names sibling tools (session_type, session_select) and explains what this tool is not, making it easy to distinguish.

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 explicit routing guidance: use session_type when a field only reacts to real keystrokes, and session_select for a dropdown. It also explains why session_fill works for React/Vue fields by firing input and change, giving the agent a clear decision rule.

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 indicate readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond these: it reports live transport status, separates two failure modes, and specifies different return shapes for standalone versus extension-attached modes. This is exactly the kind of contextual detail that helps an agent predict 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?

The description is two sentences with no wasted words. The primary purpose is front-loaded, followed by the key usage condition and then the return-value details. Every clause contributes practical information for tool selection and invocation.

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 diagnostic tool with no output schema and safety annotations already provided, the description is complete. It explains what the tool reports, why it should be called first during failures, and what fields to expect in each mode. An agent has everything needed to invoke and interpret the result.

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 has zero parameters, and the schema describes this completely with an empty properties object. Per the baseline for zero-parameter tools, no parameter explanation is required; the description adds no parameter semantics because there is nothing to document.

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: 'Report which transport is live and what it can do.' It also clarifies its diagnostic role by saying 'Call this first when another tool fails unexpectedly', which clearly separates it from the sibling action tools like session_navigate or session_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?

The description gives explicit when-to-use guidance: 'Call this first when another tool fails unexpectedly' and explains how it distinguishes root causes. It does not explicitly name alternatives or when-not-to-use scenarios, but the condition and ordering are clear enough for a diagnostic tool with no direct sibling equivalent.

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, idempotentHint=true, and destructiveHint=false. The description adds useful contextual behavior beyond that: no browser or licence is required, it 'always answers,' and it returns text. This is sufficient for a non-mutating informational 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?

The description is short and front-loaded with the core purpose. It contains a slight redundancy between 'Return setup instructions' and 'Returns installation steps as text,' but the final clause does clarify the output format, so the overall structure is still 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?

Given that the tool has no parameters, no output schema, and annotations that already cover its safety profile, the description provides everything needed: target resources, trigger context, dependency constraints, and return type. An agent can select and invoke this tool correctly without further information.

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 input schema has zero properties and schema description coverage is 100%, so the baseline for a 0-parameter tool is 4. There are no parameters to document, and the description does not need to compensate for any schema gaps.

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: it 'Return[s] setup instructions for the T3rnel Browser extension and for the free standalone automation browser.' It is clearly distinct from all sibling tools, which are runtime/automation operations, and it identifies itself as the fallback tool when another tool reports the extension is missing.

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 an explicit trigger: 'call it when another tool reports the extension is missing.' It also explains why this is the right fallback: 'Needs no browser and no licence, so it is the one tool that always answers.' No sibling tool performs installation instructions, so no alternative routing is needed.

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 establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: the returned ids are the shared contract used by all sibling tools, and omitting tabId selects the active tab, which is rarely desired. This is precisely the kind of cross-tool behavior an agent needs to know.

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 with no wasted words. The core action and return format are front-loaded, and the second sentence earns its place by explaining the practical relationship to every other tool's tabId argument.

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 list tool, the description is complete: it names what is returned, the fields in each item, and how those fields are used by sibling tools. Even without an output schema, the agent has everything needed to call this tool and interpret its results 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?

This tool has zero parameters and an empty input schema, so there is nothing for the description to clarify about parameters. The schema description coverage is 100% and the description avoids inventing parameter details, matching the baseline for a zero-parameter tool.

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

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

The description opens with a specific verb and resource ('List every open tab') and then specifies the exact return shape as an array of {id, title, url}. It clearly distinguishes this tool from siblings like session_read_page or session_snapshot by focusing on tab enumeration and the ids consumed by other tools.

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

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

The description explains when this tool is useful: to obtain tab ids for other tools' optional tabId arguments. It also gives an explicit caution against relying on the active-tab default once you have opened your own tabs, effectively telling the agent when not to omit tabId.

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 indicate this is not read-only and not destructive. The description adds useful behavioral context by explaining where the vault lives, that refusal comes from the extension rather than the bridge, and that a standalone browser profile cannot use this tool. This goes beyond what annotations alone convey.

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 front-loaded with the primary behavior, then provides prerequisite and fallback guidance. It is reasonably concise, though the 'one gate rather than two that can disagree' phrasing is slightly elaborate.

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 full schema coverage and safety annotations, the description covers the main operational context: prerequisites, error source, and fallback behavior. It does not describe return values, but there is no output schema to explain, and the core calling conditions are clear.

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 each parameter. The description reinforces the domain and fill behavior but does not add new parameter-level semantics beyond what the schema provides.

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: it decrypts stored credentials for a domain and fills them into the sign-in form. This clearly distinguishes it from manual form-filling siblings like session_fill and from credential-saving siblings like session_store_login.

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 explicitly states when the tool works (T3rnel Browser extension with Pro) and when it does not (standalone browser has no vault), including the alternative action: sign in once by hand. This gives an agent concrete decision rules.

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, the description discloses important behavioral traits: navigation returns before the page settles, it reuses the active tab unless newTab is true, and it returns a {navigated} payload plus a newTab field when applicable. This is valuable context that the annotations alone do not provide, and it does not contradict the readOnlyHint, openWorldHint, idempotentHint, or destructiveHint 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?

Three focused sentences carry a full picture: purpose, tab behavior, return value, and asynchronous timing. The most important operational detail (return before page settles) is front-loaded near the end but clearly stated, and 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?

Despite having no output schema, the description explains what is returned and the important timing caveat. For a simple 3-parameter tool with fully described schema properties and safety-relevant annotations, the description gives the agent everything needed to invoke it correctly and know what to expect next.

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 input schema has 100% parameter description coverage, so the baseline is 3. The description adds some context about active-tab reuse and returned fields, but it mostly reinforces what the schema already states rather than introducing new parameter semantics. It is adequate but not a major value-add over 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?

The description opens with a specific verb and resource: 'Navigate a tab to a URL inside the user's authenticated session.' It clearly distinguishes this from sibling tools like session_read_page or session_screenshot by focusing on navigation and the authenticated-session context. The distinction between logged-in and signed-out behavior further clarifies the tool's unique purpose.

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

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

The description gives clear context on when to use the tool (navigating within an authenticated session) and provides sequencing guidance ('follow it with session_wait before reading'). It does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for an agent to select this tool correctly in most cases.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds valuable behavioral details: it returns '{pressed}' naming the key, and it discloses the exact error behavior ('anything else fails with the supported list rather than doing nothing'). It also explains the focusing behavior ('or on a named element after focusing it'), which is not evident from the schema alone. No contradiction with annotations 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 compact and front-loaded with the core action, followed by purpose examples, return value, and supported keys/error behavior. Each sentence serves a distinct function with no filler. The structure quickly informs an agent what the tool does, when to use it, and what to expect.

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

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

For a tool with four parameters, one required, no output schema, and annotations already providing safety semantics, the description covers the essential behavioral context: focus targeting, return value, supported keys, and failure mode. The schema covers parameter details and tab/selector behavior, so nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the meaning of the key parameter by listing supported keys and clarifies the selector/ref use case ('on a named element after focusing it'), but it does not add substantial detail beyond the schema. Baseline 3 is appropriate because the schema carries the semantic weight.

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: 'Press a single keyboard key on the focused element, or on a named element after focusing it.' It clearly identifies the tool as a key-press operation and distinguishes it from sibling tools like session_click and session_type by its focus on keyboard keys. The concrete use cases (submit form with Enter, dismiss dialog with Escape, walk suggestion list with ArrowDown) reinforce the tool's unique purpose.

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

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

The description provides explicit use cases: 'Use it to submit a form with Enter, dismiss a dialog with Escape, or walk a suggestion list with ArrowDown.' This gives clear context for when the tool is appropriate, though it does not explicitly mention when not to use it or name alternative tools. Because the examples imply the alternative (typing full text with session_type, clicking with session_click), the guidance is strong but not exhaustive.

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 establish read-only, idempotent, open-world behavior, so the description adds value by disclosing the exact returned fields, the 50,000-character cap, the truncated flag semantics, and that text is rendered innerText from the authenticated session. This goes beyond the structured annotations without contradicting them.

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

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

Three concise, purposeful sentences: what it does, what it returns with key limits, and when to use it vs. a sibling. Every sentence earns its place and the most important behavior is front-loaded.

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-optional-parameter read tool with no output schema, the description fully specifies the return shape, the truncation behavior, and the sibling distinction. The agent has everything needed to invoke it correctly and understand the result.

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 already documents tabId with its integer type and default behavior ('uses the active tab when omitted'), so schema description coverage is 100%. The description does not add parameter-level detail, but none is needed given the schema's completeness.

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 page's visible text, as rendered in the user's authenticated session') and immediately contrasts with session_snapshot by scoping this tool to reading/summarizing rather than interacting. This clearly distinguishes it from its sibling tools.

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

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

The description explicitly states when to prefer this tool over session_snapshot ('when the goal is to read or summarise') and when to prefer the alternative ('when the goal is to interact'). This gives the agent direct 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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the paginated nature of the response, the return shape ({events, count}), the event type enum, and the requirement for the extension. This enriches the agent's understanding of actual behavior without contradicting annotations.

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

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

The description is concise but information-dense, leading with the core purpose, then the return structure, paging advice, and the prerequisite. Every sentence adds value with no redundant phrasing, making it easy to scan and act on.

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, paginated tool with simple parameters and no output schema, the description covers all needed aspects: return format, event types, paging behavior, and environmental requirement. An agent can correctly invoke this tool and process results without further clarification.

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 parameters are fully described in the schema (100% coverage), and the description adds practical context by explaining that limit and offset are for paging through recordings and that sessionId comes from session_record_list. This goes beyond the schema's basic definitions, providing meaningful usage insight.

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 clearly states the tool fetches captured events of a recording, specifying the order and the return structure. It distinguishes itself from sibling tools by focusing on reading events rather than recording or replaying them, making its purpose 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?

Provides explicit guidance on paging through large sessions with limit and offset, and notes the prerequisite of the T3rnel Browser extension. It does not explicitly exclude alternatives like session_record_replay, but the context makes it clear this is for reading raw events, which is sufficient for most use cases.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: it lists both running and finished recordings, specifies the return shape, and notes the T3rnel Browser extension requirement. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core purpose. Every sentence carries useful information: what it lists, why a caller would use it, what it returns, and what it requires. There is no redundancy or 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 zero-parameter listing tool, the description is complete: it names the dependent sibling tools, describes the output fields, includes both active and finished recordings, and notes the runtime dependency. No output schema exists, so the detailed return description is especially valuable.

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 has zero parameters and the schema is empty, so there are no parameter semantics to clarify. The description appropriately focuses on the return shape rather than inputs; the baseline of 4 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?

The description states a specific action and resource ('List every recording, running or finished') and clearly differentiates the tool's purpose as locating the id needed by session_record_events and session_record_replay. This makes the tool's role among many session siblings immediately understandable.

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 clear context: the caller should use this tool when they need a recording id for session_record_events or session_record_replay. It does not explicitly state when not to use it or name alternative listing tools, but the intended usage is nonetheless clear.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description goes beyond this by detailing concrete real-world effects (re-sending messages, re-submitting forms, spending money), the high-risk classification with an approval prompt, the requirement that the tab must be open, and how partial replay failures are reported. This is exactly the kind of context an agent needs for a destructive action.

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 four information-dense sentences in a logical order: action, return behavior, prerequisites, and risk warning. Every sentence earns its place and there is 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?

Despite having no output schema, the return shape is fully disclosed. The description covers preconditions, failure reporting, real-world consequences, and safety gating. With only two parameters fully documented in the schema, nothing important is missing for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates that the session must be a stopped recording but does not add new meaning beyond what the schema already provides for sessionId or speed. No extra parameter-level guidance is 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 states a specific verb (replay), a specific resource (a stopped recording), and the precise scope (in its original tab, reproducing interactions in order). It clearly differentiates from sibling record_* tools, which create, list, or inspect recordings, by focusing on the replay action.

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 clear context and preconditions: the recording must be stopped, the original tab must still be open, and the T3rnel Browser extension is required. It also warns that this acts on the live page and is gated behind an approval prompt, but it does not explicitly name alternative tools or stated when-not-to-use conditions.

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

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

Beyond the annotations, the description discloses meaningful behavior: it starts background recording of specific user interactions, requires an extension dependency, returns a structured object, and has automatic termination after tab close or four hours. These are exactly the kind of side effects and limits an agent needs to know.

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 compact and front-loaded: it states the core action, lists what is recorded, gives the return shape, and then covers prerequisites and automatic stopping. Every sentence carries useful information 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 tool with no required parameters and no output schema, the description covers everything needed to call it correctly: what happens, what is returned, what dependency is required, and when recording ends. This is sufficient context for correct invocation.

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

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

The schema already documents all three parameters with 100% coverage, so the description does not need to repeat them. It adds value by emphasizing that the sessionId is essential for subsequent recording tools, which helps an agent understand its significance, but this is a minor semantic addition over 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?

The description states a specific action ('Begin recording') and resource ('what happens in a tab'), enumerates the event types captured, and distinguishes itself from siblings like session_record_stop and session_record_events by framing it as the starting point. It leaves no doubt about what the tool does.

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

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

It provides clear context: the T3rnel Browser extension is required, the recording has automatic stop conditions, and the returned sessionId is needed by all other recording tools. It does not explicitly name alternatives or say when not to use it, but the start/stop/event sibling structure makes the use case evident.

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, the description adds the extension requirement, the performance trait ('cheap to call on a long recording'), and the error behavior when multiple recordings are active. No contradiction with idempotentHint=true or destructiveHint=false.

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 dense sentences with no filler. The primary action and return value are front-loaded, followed by necessary operational context and edge-case guidance.

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 covers the return value, prerequisite, and an important conditional requirement, which is enough for a simple one-optional-parameter tool with idempotency and destructive hints provided by annotations. Minor gaps like behavior on already-stopped recordings are not critical.

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 the schema already documents sessionId. The description restates the condition and adds a detail about the error message, but does not materially expand parameter semantics 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?

The description states a specific action ('Stop a recording') and names the exact return payload, distinguishing it clearly from sibling tools like session_record_start and session_record_events. No ambiguity about what the tool accomplishes.

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 explicitly points to session_record_events as the alternative for reading events, and clarifies when sessionId is required. It does not enumerate every sibling, but gives enough context to route the agent correctly.

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, the description adds valuable behavioral context: the output is a data: URL containing base64 PNG or JPEG, and the capture is strictly the visible viewport with no scrolling or stitching. This meaningfully enriches the tool's behavior beyond what readOnlyHint/idempotentHint convey.

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 compact sentences with no filler: the action comes first, then the return format, then the critical limitation and alternative. Every sentence 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?

With no output schema, the description appropriately explains the return value. Combined with complete parameter schemas and supportive annotations, nothing needed for 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%, so the schema already documents all four parameters including defaults and enum behavior. The description only restates the PNG/JPEG output, so it adds little beyond the structured parameter 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 states a specific verb and resource: 'Capture what is currently on screen in a tab.' It also clarifies the exact scope ('visible viewport only') and distinguishes itself from full-page capture, so an agent can understand what the tool does 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?

The description explicitly says when not to use the tool ('does not scroll or stitch') and points to the alternative ('a long page needs the extension's full-page capture instead'). This gives clear usage guidance without relying on inference.

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

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

The description discloses the silent failure mode (native value setter belonging to HTMLInputElement has no effect) and explains the tool exists to prevent it. It additionally spells out the matching order, the return object shape {selected, value, text}, and the failure behavior (lists available options). This goes well beyond the annotations (readOnlyHint false, idempotentHint true, etc.) and gives a complete picture of runtime behavior.

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

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

The description is concise yet information-dense, with every sentence serving a purpose: stating the core action and selection methods, explaining a common pitfall, detailing the matching precedence, and specifying output and error behavior. It is front-loaded with the purpose and avoids any redundant phrasing.

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 dropdown-selection tool with moderate complexity, the description covers all aspects an agent needs: how to choose (methods), why not to use alternative methods, the order of resolution, the return value, and error handling. There is no output schema, but the description compensates by specifying the return shape. Combined with the thorough schema and annotations, 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining that value is tried first, then exact text, then substring, then index, which clarifies the interplay between the value, text, and index parameters beyond their individual schema entries. It also notes that ref is used instead of selector, reinforcing the schema's wording. This adds moderate value above the schema, warranting a 4.

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

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

The description states the specific verb 'choose' and the resource 'option in a <select> dropdown', then elaborates on the three selection modes (value, visible text, index). It also contrasts itself with text-field filling, which is a sibling operation, making the purpose unambiguous and differentiated from session_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?

The description explicitly warns that filling a select as a text field does nothing, thereby telling the agent when NOT to use session_fill and implicitly steering it to this tool for dropdowns. It also details the matching priority (value → exact text → substring → index), which helps the agent decide which parameter to supply based on the target option.

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?

Even with annotations present, the description adds meaningful behavioral detail: it skips zero-size and hidden elements, caps labels at 120 characters, stops at 200 elements, and explains the ref handle format. This goes beyond the idempotent and non-destructive hints already supplied.

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. The first sentence states purpose and return shape, the second explains ref semantics and sibling-tool usage, and the third lists limits. Every sentence 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?

With one optional parameter and no output schema, the description fully covers the output structure, element shape, ref semantics, sibling relationships, and truncation behavior. Nothing needed for 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%: the only parameter, tabId, is already documented as 'Tab to snapshot; uses the active tab when omitted.' The description adds no additional parameter semantics, so the baseline of 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?

The description states a specific verb and resource: 'Capture a semantic map of a page for deciding what to act on.' It also distinguishes itself from session_read_page by framing this as the interactive-element snapshot versus a read-oriented page snapshot. The title 'Snapshot interactive elements' reinforces the purpose.

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

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

It explicitly gives the when-to-use rule: 'Prefer this over session_read_page when the goal is to interact rather than to read.' It also explains that the returned @eN refs are accepted by session_click, session_fill, session_type, session_select, and session_press, making the workflow clear.

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 indicate a write (readOnlyHint=false), idempotent, and non-destructive. The description adds the crucial security guarantee that the password is never returned or listed, and the prerequisite of the extension with Pro. This goes beyond what annotations convey.

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 concise sentences with no filler. The core action is front-loaded, followed by a critical requirement and a security guarantee. Every word contributes value.

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

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

For a simple store operation with no output schema, the description covers the purpose, prerequisite, and security behavior. It lacks discussion of error cases or overwrite semantics, but these are less critical given the idempotency hint and simplicity.

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 all four parameters are documented in the schema. The description reinforces the password's privacy but does not add substantive meaning beyond the schema. It meets the baseline but adds little extra.

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 (encrypt and store credentials for a domain) and a clear resource (the extension's vault), with an explicit purpose tied to session_login. This distinguishes it from siblings like session_login and session_record_* without ambiguity.

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 clearly indicates when to use: before session_login to persist credentials. It also notes the requirement (extension with Pro) and that the password is never returned. However, it does not explicitly mention 'when not to use' or name alternative tools, though the context of storing vs. logging in is implied.

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

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

Annotations already establish readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds useful behavioral context: it fires keyboard events, returns {typed} with the character count, and is slower than session_fill. It does not fully describe side effects of triggering real keystrokes, but with annotations present the additional information is solid.

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 focused sentences: primary behavior, when to use versus session_fill, and return/performance notes. Everything earns its place and the most important scoping information is front-loaded.

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 relatively simple tool with 4 parameters, no output schema, and a clear sibling relationship, the description covers what the tool does, when to use it, what it returns, and its performance tradeoff. No critical information seems missing for an agent to call 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 100%, so the input schema already documents selector, text, ref, and tabId. The description reinforces that text is typed one character at a time and mentions the {typed} return value, but it does not need to compensate for missing schema details, so the baseline score of 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?

The description states a specific verb and resource: 'Type text one character at a time, firing the key events a real keyboard would.' It clearly distinguishes itself from session_fill by naming it, so an agent can tell which tool to use without inspecting schemas.

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 explicitly says to use this tool instead of session_fill when a field only reacts to keystrokes, and gives concrete examples: search boxes with live suggestions, autocompletes, and per-character validation. It also tells the agent to prefer session_fill unless this tool is needed, providing clear 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?

The description discloses a lot beyond the annotations: it polls every 200ms, uses a 10000ms default timeout, returns as soon as the condition holds, fails with a named error instead of hanging, and specifies the exact return shape for each condition. Annotations already declare readOnly and non-destructive, and the description is consistent with them.

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

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

The description is dense but every sentence adds useful information: purpose, wait conditions, return shapes, timeout behavior, polling interval, and failure mode. It is front-loaded with the main purpose before going into mechanics.

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

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

For a tool with four well-documented parameters, no output schema, and safe read-only annotations, the description covers everything an agent needs to invoke it correctly: what conditions exist, what happens on success/failure, defaults, and polling 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 coverage is 100%, so the parameters are already well documented. The description adds context about behavior, such as how the value relates to URL and selector conditions, but does not significantly extend the meaning of the parameters beyond what the schema provides.

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 clearly states what the tool does: it blocks until a page reaches a known state, then releases so the next tool can act on a settled page. It names the three wait conditions (load, URL substring, selector), which distinguishes it from sibling tools like session_navigate or session_snapshot that perform actions or read 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 description gives clear context for when to use this tool: before a subsequent tool acts on a page that must be fully loaded or settled. It does not explicitly name alternatives or state when not to use it, but the intended placement in a workflow is clear enough.

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