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

With readOnlyHint=true and openWorldHint=true, the annotations cover safety, but the description adds substantial behavioral detail: ambiguous results are listed rather than resolved, zero results return nearest misses, searches cover shadow roots and same-origin iframes, and XPath does not enter shadow roots. This goes far beyond the annotations and helps the agent predict edge-case 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 long but dense and front-loaded: the core purpose appears in the first sentence, followed by the role-filter example, pairing guidance, ambiguity behavior, scope limitations, and location narrowing. Each sentence earns its place, though the paragraph-style formatting and minor punctuation issues slightly hurt scannability.

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

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

For a six-parameter tool with no output schema, the description gives a strong picture of inputs, scope, limitations, and result behavior (refs, notes on what was not searched, nearest misses, scope named in the first result line). Missing details like what 'kind' does and how pagination/limit behaves keep it from being fully complete, but the essential invocation context is present.

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 0% description coverage, so the description carries the full burden for parameter explanation. It does explain query, role, and location well (including an example for role and a location example), but it never mentions the required 'page' parameter, nor does it explain 'kind' or 'limit' beyond the default. This is a meaningful gap for a tool with two required parameters.

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

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

The description opens with a specific verb and resource: 'Find elements by text, role plus accessible name, natural-language description, CSS, or XPath.' It clearly distinguishes this tool from get_page_view by calling it a 'cheap targeted follow-up,' so an agent knows it is a retrieval/search action rather than a comprehensive read.

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 positions this tool relative to get_page_view: 'the page view tells you what string to look for, and this retrieves it for a fraction of a full read.' It also specifies scope exclusions (cross-origin iframes, closed shadow roots) and when XPath behaves differently, giving the agent concrete guidance on when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true, but the description adds significant behavioral context: pagination, specific fields returned, and a clear caveat that the log is 'not forensic and not evidence.' It also explains the purpose of the log for undo scenarios, which goes beyond the 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?

The description is well-organized: it starts with the purpose, then lists the returned fields, then gives the operational rationale, and ends with a caveat. Every sentence adds value without redundancy, and it is appropriately sized for the complexity.

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

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

Since there is no output schema, the description does explain the return content in detail, which is helpful. However, it omits any explanation of the input parameters, leaving agents to guess at filtering and pagination mechanics. For a tool with 4 parameters and no schema descriptions, this incompleteness is notable.

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

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

With 0% schema description coverage, the description was expected to compensate for parameter meaning, but it does not mention any of the four parameters (tool, limit, session, start_index). It only implies pagination without explaining how the limit/start_index work. This is a critical gap for correct invocation.

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 verb and resource: 'Read the action log'. It elaborates on the content of each record, making it distinct from sibling tools like get_page_view or get_workflows. The purpose is unambiguous.

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

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

The description provides contextual guidance ('operational record for the user, so you can always know exactly what was done') but does not explicitly compare to alternatives or state when not to use it. The use case is implied rather than explicitly routed against 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 provide readOnlyHint=true and openWorldHint=true, and the description reinforces both consistently while adding substantial context beyond them. It discloses the token-budget guarantee, what the completeness block reports for closed shadow roots and cross-origin frames (dual counts rather than a single zero), and the exact fallback behavior of the `since` read. None of this is derivable from the annotations, and it correctly explains the open-world behavior of reporting what was NOT read and why.

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?

Despite its length, every sentence earns its place: the core purpose is front-loaded, followed by return contents, then parameter guidance, then edge-case behavior. There is zero filler or tautology. The density is justified by the tool's genuine complexity, and the structure flows logically from what it returns to how to control it to what its limits are.

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 correctly explains the return payload (identity, landmark regions with expansion costs, interactive surface refs, digest/app skeleton, form/table inventories, unread account, and next call). It covers the complex edge cases of shadow roots and iframes thoroughly. The only incompleteness is the unexplained `view` and `detail` parameters, which leaves an agent guessing at part of the input surface. This is a small but real gap in an otherwise comprehensive definition.

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

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

Schema description coverage is 0%, so the description carries the full parameter-documentation burden. It explains `location` (scopes to one region ref), `budget_tokens` (with a concrete subagent value), `mode` (links at real cost), and `since` (cheap repeat read). However, three of the seven parameters—the required `page`, plus `view` and `detail`—receive no explanation. While `page` is fairly self-evident from the name, `view` and `detail` are not obvious and their interaction with the orientation read is undocumented. This is a genuine gap given the zero schema coverage.

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 precise, specific purpose: 'Read a page as an ORIENTATION, not a transcript, under a token budget it never exceeds whatever the page size.' The verb-resource pair is unmistakable, and the 'not a transcript' contrast actively differentiates it from sibling tools like get_text. An agent immediately knows this is the high-level structural read, not a raw text extraction.

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 embeds strong usage direction: `budget_tokens=2500` suits a subagent, `mode='links'` includes in-prose links, and `since=<read_token>` is the cheap repeat-read strategy with explicit fallback semantics. The 'not a transcript' phrasing plus the open/closed shadow root and same-origin/cross-origin iframe rules tell an agent exactly when this tool is appropriate versus alternatives. It even specifies when the since-read fails over to a full read, which is precisely the kind of decision guidance that matters.

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 and openWorldHint, but the description adds meaningful behavior beyond that: it requires no browser, opens no page, leaks no path or username, and reads live registry state rather than reporting product-level generalities. These are exactly the kind of side-effect and privacy disclosures an agent needs before invoking the 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?

Three dense sentences, each earning its place: the first enumerates the full report scope, the second clarifies data freshness and provenance, and the third states safety/privacy implications. Although the first sentence is long, it is information-dense and well structured rather than padded.

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

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

With no parameters, no output schema, and only safety annotations, the description carries full responsibility for making the tool callable. It enumerates all return categories, clarifies that counts describe the live connected process, and reassures about side-effect and privacy boundaries. Nothing essential is missing for an agent 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 schema coverage is 100%, so there is nothing for the description to add about parameter meaning. The provided baseline of 4 applies, and the description instead spends its effort on return-content and behavioral detail, which 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 opens with a specific verb and resource: 'Report what this server is and what it is running.' It then enumerates a comprehensive, unique scope—product and package names, version, repo, tool surface, test figures, Python, platform—that clearly separates it from browser-action and workflow siblings. Even without naming other tools, the content makes the tool's distinct purpose unmistakable.

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 clear usage context: it is safe for bug reports because it 'needs no browser, opens no page, and reveals no path or user name.' It also clarifies that counts are live from the connected process, preventing misinterpretation. However, it does not explicitly name alternative tools or state when not to use it, stopping short of full when/when-not 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 only declare readOnlyHint and openWorldHint. The description goes far beyond that: it explains pagination mechanics, how hidden content is handled (stripped, counted, and retrievable via include_hidden with per-block technique naming), the behavior for open vs closed shadow roots, and iframe handling with origin labels. It discloses the absence of a 'silent middle tier' and explains the design rationale. This is exceptionally transparent about side effects and edge cases.

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

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

The description is a single dense paragraph, but every sentence adds meaningful behavioral information. It leads with the core purpose, then covers pagination, hidden content, shadow roots, and iframes. There is no filler or repetition, though it could be tightened by moving some design rationale to a separate note. It is front-loaded and structured logically.

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 5 parameters and no output schema, the description is remarkably thorough: it explains the return format (labeled data with origin), pagination, hidden content, shadow roots, and iframes. The main gap is the 'location' parameter, which is only vaguely referenced as 'one region of it' without defining its structure. Also, the exact interaction of max_chars with pagination isn't spelled out, but the general behavior is clear. Overall it covers most of what an agent needs.

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

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

The schema has zero description coverage for its 5 parameters. The description compensates for start_index (paginated) and include_hidden (returns hidden content in labeled section), and implicitly covers max_chars via 'bounded pieces'. However, the 'location' parameter is never explained beyond 'one region of it', leaving its structure and semantics undocumented. With 0% schema coverage, the description should have covered all parameters; it covers three partially and one not at all.

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: 'Extract readable prose from a page or one region of it'. It immediately distinguishes itself from siblings by mentioning pagination via start_index and explicitly comparing to get_page_view for shadow roots. This is far more specific than a generic 'get text' and 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?

The description gives clear context for when to use the tool (for bounded, paginated prose extraction, including hidden content) and even references get_page_view to clarify shadow-root behavior. However, it never explicitly states 'use get_text when you need X, use get_page_view when you need Y' or lists exclusions. The guidance is implicit through behavioral description rather than an explicit 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?

The readOnlyHint annotation already covers the safe read-only nature, and the description adds meaningful behavioral context: tool availability reflects the server's launch-time packs alarm, and flags must be discovered here before restart. It does not describe the response format or invalid-topic behavior, but the annotation burden is lower here.

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 core purpose is front-loaded and the topic list is compact. The final two sentences about launch-time pack selection are useful but slightly redundant with each other, which costs a point.

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 documentation tool, the description explains what it returns, why it matters, and when to call it. It lacks explicit return-format details and precise parameter behavior, but the optional-topic schema and readOnlyHint annotation make those gaps non-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?

The only parameter, topic, has 0% schema coverage, so the description must compensate. The enumeration of concrete workflow topics gives the agent plausible values, but the description never explicitly maps these to the topic parameter or explains what happens when it is omitted or null. It partially compensates without fully documenting the parameter.

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

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

The description states a clear verb-resource pair ('Get recipes for this server') and enumerates the specific workflow topics returned, so an agent can tell this is a documentation/how-to tool. It does not explicitly contrast itself with sibling tools like get_server_info, but the listed content is specific enough to prevent serious confusion.

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 when-to-use context: packs are chosen at launch, so this tool is where an agent learns which launch flag is needed before restarting. It does not explicitly name alternative tools or state when not to use it, 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 (destructiveHint=true, readOnlyHint=false) already flag mutation, and the description adds substantial value on top: close kills the session but saved auth survives, status reads liveness first so dead browsers are reported, and sessions belong to the server process, not the conversation. This ownership and persistence disclosure is exactly the kind of behavior an agent needs and that structured fields cannot 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?

Every sentence is information-dense with no filler, and the core concept is front-loaded in the opening clause. However, the structure is a single unbroken prose paragraph mixing operation semantics, parameter effects, and cross-references; a dispatcher of this complexity would be far more scannable as bullets or an op-to-semantics table.

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 17 parameters, 11 sub-operations, no output schema, and no enums, the description provides substantial orientation: it discloses status output shape, session lifetime, liveness checking, and shared-state semantics. Yet it leaves major gaps — the op/action dispatch relationship, output of most operations, and the meaning of expires_minutes, note, reason, path, site, and token — so it is only partially complete 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 0%, so the description carries the full burden for 17 parameters, but it only explains a subset: auth_state, contexts, device, viewport, locale, timezone, and lane. Critical dispatcher parameters — op, action, session, note, reason, path, site, token, context, expires_minutes — are never mapped to their effects, leaving an agent to guess at the mechanics of calling 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 anchors on a strong core metaphor ('One session is one browser') and enumerates every sub-operation (open, close, status, handoff, lanes, profiles, etc.), which clearly distinguishes it from siblings like get_page_view, navigate, and monitor. However, 'manage session' is a generic dispatcher verb, and the purpose must be excavated from a dense wall of text rather than stated as a crisp mission.

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

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

There is real usage context: it tells the agent that the first navigate may auto-open a session, that handoff is for login/MFA/bot walls, and explicitly points to get_workflows(task='session-transfer') for session transfer. But it never states when NOT to use this tool versus siblings such as monitor or manage_tabs, and per-operation selection guidance is minimal for a dispatcher with 11 operations.

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

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

The annotations already signal mutation and destructiveness (readOnlyHint=false, destructiveHint=true), and the description adds valuable behavioral detail: closing a page 'invalidates its refs and its delta read tokens,' and the result announces this instead of leaving a later failure. It also reveals the cookie-jar context behavior, going beyond the structured annotation hints.

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

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

The description is dense but each sentence earns its place: the action list, the handle mechanism, the invalidation consequence, and the cookie-jar context. It is front-loaded with what the tool does, though the later sentences are somewhat intricate for the available parameter detail.

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

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

This is a multi-operation, destructive tool with five parameters, no output schema, and no enum constraints, yet the description leaves the parameter model largely implicit. It does not explain the allowed `action` values or how to request 'report which is focused' or 'capture pages a click opened in a popup,' so an agent cannot reliably construct a correct call from the definition alone.

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

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

Schema description coverage is 0%, so the description must compensate, but it only meaningfully explains `context`. The description implies action-related behaviors and page/session concepts, but it never maps parameters like `action`, `url`, `page`, or `session` to concrete values or usage, leaving the agent to guess how to invoke each operation.

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 list and resource: 'List, open, select, or close tabs, report which is focused, and capture pages a click opened in a popup.' It also states the tool's unique role by explaining it mints 'explicit page handles every other tool accepts,' which distinguishes it from the sibling tools that consume those handles.

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 conveys when to use the tool: to manage tabs and, importantly, to obtain the page handles that other tools depend on for state across calls. It does not explicitly name alternatives or give when-not-to-use guidance, 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?

Beyond the annotations, it discloses deterministic evaluation, no push delivery, stale-on-failure reporting, dedicated headless session, interval floors and quotas, honoring 429s without retry, and auto-pause on repeated failure. This is exemplary behavioral disclosure and does not contradict readOnlyHint/destructiveHint.

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 text is dense but every sentence adds a distinct constraint or behavior, and the most important information about scope is front-loaded. No filler or redundant restatement of the schema.

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

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

The behavioral context is unusually complete for a 9-parameter tool with no output schema, and it even hints at report semantics. Yet an agent still cannot fully infer how to create/select a monitor, what `since` and `label` mean, or what the exact response shape is, leaving operational gaps.

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

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

With 0% schema coverage, the description must carry parameter meaning, and it does name the four condition values and report/check_now actions while indirectly suggesting url, selector, value, and interval. However, label, since, and monitor remain unexplained, and no parameter requirements per condition are spelled out, so it only partially compensates.

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 opening line 'Watches one URL for one deterministic change while this server runs' states a specific action, resource, and scope, and the four condition names make the function concrete. It does not name a sibling for contrast, so it misses the explicit differentiation needed for a 5.

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

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

The description makes the intended use implicit: a long-running watcher for one deterministic page change, with 'report' and 'check_now' as the query/force actions. It never says when to prefer this over siblings like wait_for or get_page_view, so the agent is left to infer tool 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?

The description goes well beyond the annotations by disclosing that it can mint session and page handles, that redirects yield a final identity, and that it returns HTTP status, a robots.txt advisory, and a bot-wall/CAPTCHA/login-wall verdict. It also explains that blocked results surface as blocked rather than as timeouts or empty pages, which prevents retry loops. No contradiction with the annotations.

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

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

The description is dense but front-loaded: the first sentence gives the action, the second gives the first-call semantics, and the third gives the return value contract. No sentence is filler, and the blocked-request rationale 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 tool with no output schema and no enum definitions, the description explains the return payload and the session-bootstrapping flow well. It is missing exact wait_until states and precise action values, but the core invocation path, URL with or without a page handle, is fully specified.

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

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

With schema description coverage at 0%, the description carries the parameter-documentation burden. It clarifies the page parameter's first-call behavior, the URL target, and the broad action categories (back, forward, reload, stop). However, it doesn't give exact accepted strings for action or wait_until, nor does it explain timeout_ms, so it is strong but incomplete.

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 identifies a concrete resource (a URL/page) and a specific set of actions: goto, back, forward, reload, stop, plus waiting on a load state. It is clearly a navigation tool scoped to page loading and session bootstrapping, though it does not explicitly contrast itself with siblings like wait_for or manage_tabs.

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 says when navigation can be the first call and what happens when no page is provided, including opening a bundled headless Chromium. It also names waiting on a load state, but it doesn't give when-not-to-use guidance or name alternatives among the listed sibling tools.

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

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

Beyond the annotations, the description reveals meaningful behavior: it remembers scroll position across calls in next-chunk mode, reports reachable vs. remaining content, and explicitly identifies virtualized containers instead of presenting a partial view as complete. This is valuable transparency that annotations alone do not provide.

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 dense sentences with no filler. It front-loads the primary action modes and then adds behavioral reporting details, making it easy to scan while still packing relevant information.

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

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

It covers the main behaviors and high-level return information, but because there is no output schema, it lacks specifics about the exact response format. It also does not define the action enum values or the semantics of timeout_ms, leaving some gaps for an agent trying to invoke the tool precisely.

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

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

Schema description coverage is 0%, so the description must compensate. It alludes to action modes and 'location' as a named element/container, but it never explains allowed action values, the exact meaning of amount, how page is used, or timeout behavior. The description gives only loose mapping to the five parameters.

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

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

The description states a specific verb ('scroll') and enumerates distinct modes: by amount, to a named element, to the end, within a container, and a next-chunk mode. This makes the tool's purpose concrete and clearly distinguishes it from general navigation siblings like navigate or wait_for.

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 the next-chunk mode is useful ('a long page is walked without re-reading it') and for virtualized-container handling. However, it does not explicitly state when to choose this tool over siblings such as get_page_view, navigate, or find_elements, nor does it provide exclusions or alternative routing.

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 readOnly=false, openWorld=true, destructive=true; the description adds genuinely non-obvious traits beyond that: check-current-state-first semantics that prevent spurious timeouts, glob vs substring matching on URLs, enforcement of real (not clamped) timeouts, and failure output that names what was awaited versus observed. It does not reconcile the 'destructive' annotation, which is unexpected for a wait, but it does not contradict it either.

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 purpose is front-loaded in sentence one, and the remaining sentences carry distinct facts (check-first behavior, glob rule, failure reporting). It is somewhat dense, and the parenthetical about a URL wait expiring on a finished navigation could be trimmed without loss.

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

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

With no output schema and annotations that say little about runtime behavior, the description does cover return/failure behavior and timing semantics well. However, for a five-parameter tool at 0% schema coverage, leaving 'value', 'location', and 'timeout_ms' unexplained leaves the agent to guess how each maps to a condition type.

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

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

Schema description coverage is 0%, so the description bears the full param burden for five parameters. It clarifies condition semantics and the wildcard/substring rule for URL values, but 'value' and 'location' are never tied to their roles and timeout_ms is only alluded to via 'real timeouts', so compensation is partial.

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 opening sentence gives a precise verb and enumerates the four condition kinds the tool handles (text appear/disappear, element state, URL match, JS predicate), so the agent knows exactly what this is for. It never names or contrasts with siblings like find_elements or get_text, so it stops just short of full sibling differentiation.

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

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

The description gives real usage context: every condition is check-first and returns immediately when already satisfied, so a wait after the fact is free rather than a timeout. That's actionable guidance on when this is safe to use, but there is no explicit statement of when NOT to use it or which sibling to prefer for a plain immediate check.

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