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

The description goes far beyond the readOnlyHint annotation by detailing search scope (main document, shadow roots, same-origin iframes), exclusions (cross-origin iframes, closed shadow roots), behavior for ambiguous and zero results, and how location narrowing works. This provides rich behavioral transparency that annotations alone could not 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 lengthy but information-dense, with each sentence contributing value. It opens with the core purpose, then adds a concrete example, usage guidance, and detailed behavioral notes in a logical flow. While slightly long, it is well-structured and front-loaded with the most critical information.

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

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

The description is comprehensive for a read-only element-finding tool: it explains output (refs and notes on what wasn't searched), ambiguity handling, scope of search, limitations, and how to narrow via location. Despite no output schema, the agent receives enough information to call the tool correctly and interpret results.

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 compensates by explaining the 'role' parameter ('narrows any query to one element role'), the 'location' parameter (region, ref, form, table narrowing), and implying 'kind' via the listed search methods. It does not explicitly define the 'kind' enum values or explain 'page' and 'limit', but the core parameters are meaningfully clarified beyond the bare 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 clearly states the tool finds elements via text, role, natural-language description, CSS, or XPath, and returns actionable refs plus a note on what wasn't searched. It also distinguishes itself from sibling get_page_view by positioning it as a cheap targeted follow-up, 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?

Explicitly names get_page_view as the complementary tool and specifies when to use this tool ('the cheap targeted follow-up'). It also explains how ambiguity and zero results are handled, giving clear context for expected behavior in common scenarios.

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

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

Annotations declare readOnlyHint: true, and the description aligns by saying 'Read the action log.' It adds behavioral context beyond annotations: the log is paginated, returns one record per call, and carries specific fields. It also discloses the non-forensic, non-evidence nature, which is critical for appropriate use. This significantly enriches the safety profile.

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-structured: it leads with the core action, enumerates the record contents, then adds operational context and limitations. It is a bit long but every sentence adds meaningful information, and the structure is logical. It does not waste words.

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 four parameters and no output schema, the description needs to explain how to paginate (limit, start_index) and how to filter (tool, session). It does not. It describes what the log contains but not how to control retrieval. An agent would not know how to request a specific page or filter by tool without inspecting the schema, which itself has no descriptions. The description is incomplete for effective invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain any of the four parameters (tool, limit, session, start_index). It only mentions 'paginated' generically, which hints at limit/start_index but does not explain their meaning or usage. The 'tool' and 'session' filters are entirely unexplained. The description adds essentially no parameter-level meaning.

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 and resource: 'Read the action log.' It explicitly lists what each record contains (timestamp, lane, page, URL, resolved target, etc.), which distinguishes it from all sibling tools. None of the siblings (wait_for, get_page_view, find_elements, etc.) read the action log, so 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 context on when to use it: 'This is an operational record for the user, so you can always know exactly what was done even where a web action cannot be undone.' It also warns of limitations: 'It is not forensic and not evidence.' It doesn't name specific alternative tools, but no sibling appears to offer similar functionality, so the guidance is adequate.

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 though annotations already declare readOnlyHint=true, the description goes far beyond that: it details token-budget guarantees, fallback behavior for since tokens, handling of shadow DOM (open vs closed), same-origin vs cross-origin iframes, and the completeness block counting unread content. This is rich, candid behavioral disclosure that helps an agent predict side effects and limitations.

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 structured as a dense, information-rich paragraph with logical flow from output composition to specific parameter modes to edge-case behaviors. Every clause adds substantive detail about capabilities or limitations; it is not padded, though it could arguably be tightened without losing meaning.

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

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

Given the tool's complexity, the absence of an output schema, and 0% schema parameter descriptions, the description is exceptionally complete. It covers what is returned, how tokens are managed, what happens with shadow DOM and iframes, how to perform cheap repeat reads, and what the completeness block reports. An agent has enough information to call this tool correctly in most scenarios.

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 is the only source for parameter meaning. It explicitly explains 'location', 'budget_tokens', 'mode', and 'since' with usage context, and 'page' is self-evident. However, it leaves 'view' and 'detail' completely unexplained, which is a gap for a tool with 7 parameters, though the core behavioral parameters are well covered.

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 clear, specific verb ('Read') and resource ('a page') and immediately distinguishes it from a transcript by calling it an 'ORIENTATION'. It also enumerates the specific output components (identity, landmark regions, interactive surface, etc.), making the tool's function unambiguous and distinct from siblings like get_text.

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 strong context for when to use the tool: it positions it as an orientation with a token budget, and gives concrete parameter guidance (e.g., 'budget_tokens=2500 suits a subagent', 'mode='links' includes in-prose links', 'since=<read_token> is the cheap repeat read'). However, it does not explicitly name alternative sibling tools or state when not to use it, leaving the comparative routing implicit.

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 far more than the readOnlyHint annotation: it details pagination, hidden-content handling (stripped/counted vs. included via include_hidden), labeling with origin, shadow-root behavior (open read, closed counted), and iframe handling with per-frame headers. It explains design rationale (display:none as injection channel), making the tool's behavior fully predictable. 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 a single dense paragraph, but every sentence adds value: it front-loads the core purpose, then expands on hidden content, shadow roots, and iframes. It is longer than typical, but the complexity of the tool justifies the length. No filler or repetition, so it is efficient despite its size.

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 5 parameters, no output schema, and only readOnlyHint annotation, the description covers all critical behavior: pagination, hidden content, shadow roots, iframes, and origin labeling. It explains the output format conceptually ('labeled data with origin stated'), which is sufficient for an agent to know what to expect. Nothing essential is missing for safe and 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 coverage is 0%, so the description carries the entire burden. It explains start_index (paginated), include_hidden (explicitly described), and location ('one region of it'). It implies max_chars via 'bounded pieces' but does not name it, and page is obvious from context. It adds substantial meaning to most parameters, though max_chars and page are not explicitly described—still a strong compensation.

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 ('Extract'), a clear resource ('readable prose from a page or one region of it'), and distinguishes itself by mentioning pagination and the origin-labeling of text. It differentiates from sibling get_page_view by specifying that it extracts prose and handles shadow roots/iframes in a defined manner, so an agent knows exactly what this tool is 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: it extracts readable prose, is paginated, and handles hidden content deliberately. It explicitly references get_page_view when comparing shadow-root behavior, implying when to use which, but does not state explicit exclusion criteria (e.g., 'use get_page_view for visual layout instead'). Still, it gives enough situational guidance for a competent agent.

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 annotation readOnlyHint: true already indicates the tool is read-only, and the description does not contradict this. However, no additional behavioral details are provided 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 overly long and repetitive, with redundant phrases like 'Packs are chosen at launch rather than at runtime' and 'Tool availability reflects the packs this server was started with.' It lacks clear structure and concise wording.

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

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

The description provides no information about the output format, expected results, or how to interpret the returned data. It also leaves the parameter semantics unexplained, making it incomplete for a user to effectively use the 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?

The single parameter 'topic' is not described in the schema, and the tool description does not explain what values it accepts or how it affects the output. The listed topics do not map to 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 the verb 'Get' and the resource 'recipes', but the meaning of 'recipes' is vague and the long list of topics confuses rather than clarifies the tool's exact function. It does not clearly distinguish this tool from siblings.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description implies it provides information about various topics, but does not state conditions or 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 only indicate readOnlyHint=false, so the description must carry behavioral context. It does: it explains that sessions belong to the server process, that close ends the browser and the session never survives, that status reads liveness first, and that contexts=2 gives independent cookie jars. These details go beyond the annotation and help the agent predict side effects.

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

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

The description is long (about 8 sentences) and dense, but it is structured as a logical flow from core concept to operation list to parameter effects. It front-loads the key idea and uses consistent formatting for operation names. It is not wasteful, but the sheer length could overwhelm an agent; still, given the tool's complexity, the detail is mostly necessary.

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, multiple operations, and no output schema, the description is fairly complete. It covers session lifecycle, sharing, liveness checks, and some parameter semantics. It references an alternative workflow. However, it omits explanations for many parameters and the op/action distinction, leaving gaps for an agent to fully understand all use cases.

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

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

Schema description coverage is 0%, so the description must compensate for all 17 parameters. It explains auth_state, contexts, device, viewport, locale, and timezone, but leaves many parameters (note, path, site, token, reason, context, session, expires_minutes, op, action) unexplained. Critically, it does not clarify whether 'op' or 'action' is the primary operation selector, which is a major ambiguity 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 explicitly defines the tool as managing sessions, where one session equals one browser, and enumerates distinct operations (open, close, status, capabilities, budget, reset_budgets, handoff, export_handle, import_handle, lanes, profiles). It is specific and clearly distinguishes this tool from siblings by focusing on session lifecycle and configuration rather than page interactions.

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 context on when operations are automatic ('the first navigate of a conversation can open one for you') and explicitly references an alternative for session transfer ('see get_workflows(task='session-transfer')'). It does not, however, give explicit guidance on when NOT to use this tool in favor of other siblings, but the scope is clearly session management.

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 readOnlyHint=false, it discloses side effects: it mints page handles, invalidates them on close, and reports invalidation instead of failing later; also notes cookie-jar association.

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

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

Four dense sentences, each conveys one essential behavioral fact; no redundant 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?

With no output schema, it still describes what is returned (page handles, focused tab, cookie-jar labels, invalidation notices), enough to call and interpret results.

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?

Though the schema has no per-parameter descriptions, the prose maps action to verbs, page to handles, context to cookie jar, and session to browser state; url is implied for open but not named.

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

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

The description names the concrete actions (list, open, select, close) and the resource (tabs/pages), and explicitly positions tab management as distinct from navigation/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?

It explains when the tool is needed—any time another tool needs a page handle—and clarifies multi-cookie-jar context selection, but it does not explicitly contrast with sibling tools like navigate or manage_session.

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 is unusually rich: it discloses deterministic state, no push behavior, dedicated headless session, rate limits (floor/caps/429), and pause-on-failure. These details go well beyond the minimal readOnlyHint annotation and set accurate expectations.

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, but some phrasing is cryptic (e.g., 'reports stale with the failure, never unchanged') and information is packed into run-on semicolon clauses. It could be clearer without adding length.

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

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

It provides helpful operational context (session isolation, rate limits, failure behavior) but no return format or output schema, and no guidance on how fields like since/value/label are used. Given the 9-parameter schema and no output schema, this is not fully complete.

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?

It maps several schema fields indirectly: condition types, selector_count, action values, interval floor, and URL. However, parameters like since, value, and label are not explained, leaving important semantics ambiguous.

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 clearly states the tool watches one URL for a deterministic change while the server runs, and the four condition types are enumerated. It does not explicitly describe the full lifecycle of creating/managing monitors, which slightly reduces clarity.

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

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

It gives some action guidance: 'report is how you ask what happened, and check_now forces a check,' and states nothing is pushed. It does not compare this tool to sibling alternatives like wait_for or get_page_view, so when to choose it over those is mostly implicit.

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 important behavioral traits: it opens a bundled Chromium session if none exists, returns handles, follows redirects, reports the final identity, and identifies bot walls, CAPTCHAs, and login walls so blocked requests are surfaced as blocked rather than as timeouts or empty pages. It also notes it waits for the load state. These details go beyond the minimal readOnlyHint annotation and provide useful context for the agent.

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 efficient: it front-loads the core actions, then adds the first-call behavior and return values in a compact manner. Every sentence adds value, 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?

Given there is no output schema, the description does a good job of explaining what the tool returns (final identity, HTTP status, robots.txt advisory, block verdict). It also covers the session-opening scenario and error handling for blocked pages. However, it does not explain all parameters, notably timeout_ms, and does not address edge cases like navigation failures beyond the block detection. Still, it is quite complete for a navigation 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 coverage is 0%, so the description carries the burden of explaining parameters. It hints at 'url' (Go to a URL), 'action' (go back, forward, reload, stop), 'page' (with no `page`), and 'wait_until' (the load state you name), but it does not mention 'timeout_ms' at all, and it does not formally define the values or defaults. The description adds some meaning but is not comprehensive enough to fully compensate for the lack of schema documentation.

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

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

The description states a specific verb ('go to', 'go back', etc.) with a clear resource (URL, browser navigation) and distinguishes itself from siblings by being the first call that opens a session and returns session/page handles. It also names the return values (final identity, HTTP status, robots.txt advisory, block verdicts), making the tool's 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 mentions 'Can be the FIRST call' as a usage context, implying when it should be used (to initiate a browser session), but it does not explicitly compare this tool to siblings like wait_for, scroll, or manage_tabs, nor does it state when not to use it. The guidance is implicit rather than explicit.

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 readOnlyHint annotation by disclosing stateful behavior (remembers position across calls), output reporting (reachable/remaining content), and virtualized container handling. This transparency helps agents anticipate side effects and results.

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 that efficiently enumerate modes, statefulness, and output characteristics without redundancy. It is front-loaded with the primary action and maintains a clear structure.

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 major behaviors and output, but omits parameter-level details and edge cases. Given the complexity of multiple scroll modes and stateful behavior, it is mostly complete but could benefit from explicit parameter mappings and examples.

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 0% parameter description coverage, and the description only vaguely hints at action, amount, and location. It does not define the page, timeout_ms, or the structure of the location object, failing to compensate for the missing schema details.

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 explicitly states the tool scrolls by amount, to an element, to the end, or within a container, and introduces a next-chunk mode. It clearly identifies the action and its variants, leaving no ambiguity about the tool's 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 implies when to use the next-chunk mode for long pages, but it does not explicitly contrast with sibling tools like navigate or find_elements. It offers clear context for usage but lacks explicit alternatives or exclusions.

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

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

The description discloses key runtime behaviors: immediate success on already-satisfied conditions, wildcard handling for URLs, real timeout behavior, and failure message content. This goes well beyond the minimal readOnlyHint annotation and sets accurate expectations.

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 and includes useful information, but the parenthetical aside about URL wait expiration is awkward and reduces clarity. It is a single unstructured paragraph rather than a clean purpose-plus-behavior format.

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

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

Given the input schema has five parameters and no property descriptions, the description is not sufficient to fully understand expected values or return behavior. Allowed condition values, the shape of `location`, and how `page` is used are left unspecified.

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

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

Schema property descriptions are absent, and the description only partially clarifies parameters. It mentions URL wildcard behavior for `value` and implies `timeout_ms`, but `page`, `location`, and `condition` semantics are not explicitly defined, leaving significant ambiguity.

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's purpose: waiting for text, element states, URL matches, or JS predicates. It distinguishes wait_for from siblings like navigate and find_elements by focusing on conditional waiting.

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 to use the tool and important behavioral nuances, such as immediate return if the condition already holds and URL substring/glob matching. It does not explicitly contrast with alternatives, but the purpose is clear enough to guide selection.

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