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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the agent knows this is a non-destructive mutation on the open web. The description adds genuinely useful behavior beyond that: fail-fast termination, that plain-English steps consume a model and are billed while action objects are free, and that coordinates are viewport CSS pixels. Strong additions, though return/pagination detail is thin.

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?

Front-loads the core purpose and fail-fast rule, then layers in examples and the cost distinction. It is dense and example-heavy, but every clause (billing, coordinates, return format) carries information an agent needs given the polymorphic input, so it largely earns its 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?

With no output schema, the description still explains return behavior ('one line per step saying what happened', plus the evaluate return value). For a two-param, high-complexity polymorphic tool, an agent has what it needs to select and invoke it correctly.

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

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

Schema coverage is 100%, but the description adds substantial meaning: concrete action-object shapes (click, hover, goto, scroll, evaluate, right-click, drag), the 1-to-100 step contract, and the plain-English-vs-object distinction with its different execution/cost model. This far exceeds what the schema alone conveys.

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

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

States a specific verb+resource ('do one or more steps on the session's browser page') plus the fail-fast semantics ('in order, and stop at the first one that fails'). It implicitly distinguishes itself from single-action siblings like browser_click ('when saying what to click is easier than finding its selector') but never names them explicitly.

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

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

Gives clear when-to-use context: batching several things in one call, or when natural-language targeting beats finding a selector, plus the constraint that plain-English steps require a plan that includes them. It stops short of naming the alternative single-step tools or stating when-not to use it.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description adds selector format and click-variant routing but says nothing about side effects (navigation, form submission) or failure behavior when a selector matches nothing, which are meaningful for a mutation-capable click.

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, zero waste, with the primary input forms front-loaded and the alternative-tool routing placed second. Every clause earns its place.

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

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

For a 4-param click tool with annotations covering safety and no output schema, the description covers input forms and the key sibling boundary. Missing only edge-case behavior such as what happens on an unmatched selector or whether the click may trigger navigation.

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 only 25% (just sessionId), so the description must compensate. It does: it identifies selector as a Playwright selector with concrete examples (`text=Sign in`, `#submit`) and clarifies x/y are page coordinates, and that selector and coordinates are alternatives. sessionId is left to the schema reference.

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

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

States a specific verb (click) and resource (an element via Playwright selector, or page coordinates), and explicitly names the sibling (browser_act) it is not for right/double/modified clicks. An agent can distinguish it from browser_act, browser_type, and browser_press without opening any schema.

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

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

Explicitly routes the agent away for right-click, double-click, and key-held clicks, naming browser_act as the alternative. It does not fully spell out selector-vs-coordinate preference, so guidance is clear context 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 only declare the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false); the description adds genuine behavioral context beyond them: that the action executes against the live browser and the screen is then captured, that coordinates are screenshot pixels, and that maxWidth rescales both the screenshot and the coordinates. It stops short of describing failure modes or what exactly the returned screen payload contains.

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, the core verb and the single-action constraint front-loaded, with the payload-shape examples and coordinate scaling packed efficiently into the second. Dense but no filler; the parenthetical examples are load-bearing rather than decorative.

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 nested-object, side-effecting tool with no output schema, the description covers the two things the schema cannot: the shape of the opaque action payload and the coordinate/scale invariant. It briefly signals the return ('then see the screen'), leaving the response structure and error behavior unstated, which is the only notable gap.

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

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

Schema coverage is only 50%, and the free-form 'action' object (additionalProperties: {}, propertyNames: string) is nearly meaningless from the schema alone — the description rescues it by naming both accepted provider shapes. It also explains maxWidth's scaling contract and the coordinate frame, though it never explains the 'screenshot' boolean or its default.

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

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

States a specific verb and resource — run one computer-use action — and pins down the exact payload shapes accepted (Anthropic {action:'left_click', coordinate:[x,y]} vs OpenAI {type:'click', x, y, button}). It does not explicitly contrast itself with the many close siblings (browser_act, browser_click, browser_press, browser_type), so an agent must infer the distinction from the provider-shape framing.

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 capitalized 'ONE' conveys that actions must be issued singly rather than batched, which is real usage guidance, and 'as a model's computer tool gives it' implies this is the passthrough path for provider-native action objects. However, there is no explicit when-to-use-this vs browser_click/browser_act/browser_type, and no prerequisite callout (the schema, not the description, carries the session_create dependency).

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

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

Adds substantial context beyond the annotations: the password, 2FA code, and sign-in link are never exposed to the caller, the credential is restricted to its own sites, and push/url codeSource variants can block for minutes. It also states the return value ('the page it ends on') and the browser-session prerequisite, none of which the 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?

A single dense paragraph that front-loads the core action, then the secrecy guarantee, then the url constraint and timeout caveat. Nearly every clause earns its place, though the sentence runs long and could be split for fast scanning.

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?

Complete for a 3-param browser action: it covers the session prerequisite, the credential source, the url constraint and default, the long-running timeout case, and the return value despite there being no output schema. An agent has everything needed to call it correctly and to warn the user about codes.

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, but the description adds real meaning: credential is a name from credentials_list, and url must be on one of the credential's sites with the first site as the default. That default and the site-restriction constraint go beyond the schema text.

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

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

States a specific verb and resource ('sign the session's browser in with a saved password credential') and immediately scopes it as a one-call operation that types on the credential's own sites only. This clearly distinguishes it from browser_type/manual typing and from credentials_list, which merely enumerates.

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 strong context: the url must be one of the credential's sites (default the first), and that push/url codeSource credentials wait up to the timeout so the call may take minutes and the user should be told a code is needed. It also notes 'Needs a session with a browser.' No competing sibling is named explicitly, but the routing is inferable.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds nothing beyond that: it does not say the navigation mutates the session's current page state (affecting browser_read/browser_click), whether it waits for load, or what happens on failure.

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

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

A single front-loaded sentence with no wasted words, which is fine for structure. But the brevity reflects under-specification rather than tightness, so it earns only a middling score.

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 stateful, open-world browser action with no output schema and no annotation detail about load behavior, the description is too thin. An agent cannot tell whether the call blocks until the page loads or what state the session is left in afterward.

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 50% schema description coverage, sessionId is documented but url is a bare string. The description mentions 'URL' generically but adds no format constraints such as requiring an absolute URL with scheme, which the schema leaves 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?

States a specific verb ('Open') and resource ('a URL in the session's browser'), so the agent knows exactly what it does. However, it offers no differentiation from siblings like fetch_url, screenshot_url, or browser_login, which could all be mistaken for fetching a URL.

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

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

There is no guidance on when to use this versus fetch_url, crawl_site, or browser_login, nor any prerequisites such as needing an active session from session_create. The only hint is the required sessionId parameter, which is schema-level information, not description 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: keys are delivered to the page and never the desktop, and the target environment is Linux. It stops short of saying what happens when no element has focus or what is returned.

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?

Roughly five sentences, front-loaded with the core action before the syntax detail. Every sentence carries real information about the keys format, though the key-syntax guidance could be tightened slightly.

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 2-param, no-output-schema tool whose annotations already carry the safety profile, the definition is nearly complete: key syntax, aliases, platform conventions and delivery target are all covered. The only gap is explicit when-to-use guidance against sibling interaction tools.

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% (baseline 3), and the description exceeds it substantially, documenting combo syntax with '+', space-separated sequences, Playwright naming, accepted aliases (ctrl, cmd, Return), Shift-for-capital behavior, and ControlOrMeta portability. Only sessionId is left unexplained, but its schema note ('from session_create') is sufficient.

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

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

States a specific verb and resource: pressing keys on the session's browser page, with the scope narrowed by 'never to the machine's desktop'. It distinguishes itself implicitly from shell_exec/browser_computer via that desktop distinction, but never names the closest siblings (browser_type, browser_click) to make the boundary explicit.

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

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

The description thoroughly explains how to form the keys argument but never says when to choose browser_press over browser_type, browser_click or browser_computer. Usage is implied by the key syntax rather than stated as selection 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the format options and says nothing about truncation, length limits, or the need for an active session, so it contributes limited behavioral context beyond the structured fields.

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

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

A single short sentence with the verb and output scope front-loaded and no filler. It is efficient, though arguably under-specified rather than optimally concise.

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 should carry more of the return-shape burden; it does indicate the output format but omits the session prerequisite and any truncation behavior. Adequate but with clear gaps for a content-extraction 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 50%: sessionId is documented in the schema ("from session_create") while format is left to its self-explanatory enum. The description's phrase "markdown or plain text" merely restates the enum values rather than adding meaning, 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?

States a specific verb (read) and resource (the current page) plus the output formats it produces. It implicitly distinguishes itself from browser_screenshot (image capture) and fetch_url (arbitrary URL), but never names or contrasts those siblings explicitly, so an agent must infer the boundary.

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?

"Current page" implies it operates on a page already loaded via browser_navigate, but there is no explicit when-to-use statement and no mention of alternatives like fetch_url or browser_screenshot. No exclusions or prerequisites are given.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered, but the description adds nothing beyond that. It does not say whether the image is returned inline or written to disk, what format/size it is, or that an active session is required.

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 single sentence is front-loaded and free of padding, so it is not bloated. But at five words it is under-specified rather than genuinely concise, leaving essential behavior unstated.

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 no annotations covering return behavior, the description should explain the result format and the effect of fullPage, and should note the session dependency. None of that is present for a 2-parameter 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 only 50%: sessionId is documented but the fullPage boolean has no description anywhere. The description never explains that fullPage switches between viewport and full-page capture, so it fails to compensate for the gap.

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

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

The description contains a clear verb-and-resource pair ('Screenshot the current tab'), so the basic action is unambiguous. However, it does not distinguish this tool from the very similar sibling 'screenshot_url', nor does it clarify that 'current tab' means the tab belonging to the session identified by sessionId.

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

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

There is no guidance on when to use this versus building a URL screenshot with screenshot_url, nor any note about needing an active session first. The agent must infer all routing from the tool name alone.

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 (which only say non-read-only, non-destructive, open-world) by disclosing that secrets are typed without the agent seeing them, that passwords are confined to the named field and the sites they were saved for, that otp with codeSource push/url blocks until the user's code arrives, and a hard rule against asking users to paste passwords.

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?

Front-loads the core action and the credential alternative, and every sentence carries information. The password/otp sentences are dense and slightly run-on, which costs a point on structure but not on relevance.

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 5-param mutation tool with no output schema, the description covers the risky credential path thoroughly. It leaves out success/failure signaling and any field-clearing behavior, and never mentions sessionId, but nothing essential to invoking it correctly 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?

With only 60% schema coverage, the description carries real weight: it defines 'credential' as a name from credentials_list, explains the 'field' enum values including that otp is the current 2FA code, and clarifies that text/credential are alternatives. This is meaningfully more than the schema conveys.

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

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

States a specific verb and resource ('Type text') plus the optional targeting mechanism ('into the element matched by selector'), which cleanly separates it from siblings like browser_press, key, and browser_login. An agent can identify the action without opening the schema.

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

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

Explicitly routes between two modes: plain 'text' versus 'credential' from credentials_list, and specifies when to add 'field' and which enum value applies. It doesn't address when to prefer this over browser_press/key or browser_login, so it falls short of full 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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral facts: "Never shows a value" (no secret leakage), the meaning of codeSource values (totp, push, url, null), and the exportable scope semantics including the dangerous "shell: true, which also lets the AI put it into bash commands" case.

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?

Front-loaded with the core action and the returned field list before the dense scope/flag explanations. The middle sentences pack multiple nested clauses (browserType, exportable, shell: true) into one run-on, which costs some readability, but each sentence carries distinct 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?

With no output schema, the description has to carry the return shape itself, and it does: name, type, sites, browserType, codeSource with enumerable values, and exportable. Combined with the annotation-covered safety profile, an agent has everything needed to call and interpret 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the per-field semantics provided instead describe return values rather than inputs. Baseline 4 applies for a parameterless 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?

Opens with a specific verb+resource ("List the project's saved credentials") and immediately enumerates what each entry contains. It also names the sibling tools that consume credentials (browser_type, browser_login, session_create), so an agent can place it precisely in the credential lifecycle.

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?

States explicitly where you would use a returned name — browser_type's credential, a password's name in browser_login (a secret cannot sign in), or an exportable name in session_create's credentials — and closes with a when-not (credentials are added via console/CLI/SDK, not here). It does not spell out a trigger condition for calling this list itself, so it falls short of an explicit when-to-use.

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 irreversibility is signposted. The description adds real value beyond that: it discloses recursive deletion ('a folder with everything in it') and the non-obvious idempotent-like behavior that a missing path is not an error, both of which the agent needs.

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

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

Three short sentences, all earning their place, with the destructive scope and irreversibility front-loaded and the non-error edge case last. 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 destructive two-parameter mutation with no output schema, the description covers scope, recursion, irreversibility, and the missing-path edge case. It could still say what comes back (or that nothing does) and any session/permission dependencies, but the essential behavioral picture is 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?

Schema coverage is 50%: sessionId is documented but path is not. The description references path behavior (non-existent path tolerated) but adds no format or syntax guidance for it, so with the schema doing half the work a 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 names a specific verb (delete) and resource (file or folder, recursively) and scopes it to the session workspace, which cleanly separates it from siblings like files_write and files_read. It also disambiguates recursive folder deletion from single-file deletion.

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

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

Usage is implied by the scope ('session workspace'), but there is no explicit statement of when to use this versus alternatives like files_write, nor prerequisites or warnings about permissions. It also doesn't say how to reach the destructive target beyond the path concept.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: a stopped session's saved files remain listable without resuming it, which affects how the agent sequences calls.

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

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

Two short sentences, front-loaded with the core purpose and followed immediately by the one non-obvious constraint. 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 read-only list tool with no output schema, the definition covers purpose and one session-state edge case, but leaves the path parameter's semantics and the shape of the returned listing unexplained. Adequate but with visible 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?

Schema description coverage is only 50%: sessionId is documented ('from session_create') but the 'path' parameter has no schema description at all. The description says nothing about what 'path' means (a directory filter? relative to workspace root?), so it fails to compensate for the coverage gap.

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

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

Names a specific verb ('List') and resource ('files in the session workspace'), which cleanly separates it from sibling operations like files_read, files_write, and files_delete. It stops short of naming a sibling alternative the way a 5 would, but 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 stopped-session sentence implicitly tells the agent it does not need session_resume to enumerate a stopped session's files, which is genuinely useful routing guidance. However, there is no explicit when-to-use/when-not-to-use statement relative to files_read or session_list.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it reads text (not binary) from the session workspace, and crucially that a stopped session's files are read without resuming — a non-obvious trait an agent would otherwise have to guess.

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

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

Two short sentences, no filler. The core action is front-loaded and the second sentence carries only the non-obvious stopped-session behavior, so every clause earns its place.

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

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

For a simple two-parameter read tool with no output schema, the description covers what the tool does and its notable session-state behavior. It does not describe what is returned or error behavior for a missing path, but those gaps are minor for a straightforward read.

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 50%: sessionId is documented in the schema, but path has no description. The phrase 'from the session workspace' adds implicit meaning about how path is rooted, but format details (relative vs absolute, path separators) are left unspecified in both the schema and the 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?

States a specific verb and resource ('Read a text file') and constrains the scope to 'the session workspace,' which naturally separates it from the write/delete siblings. It stops short of explicitly naming an alternative, but 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?

There is no explicit when/when-not statement or named alternative, but the second sentence functions as an implicit usage rule: files from a stopped session can be read without resuming, telling the agent it need not call session_resume first. Guidance is present but implied rather than spelled out.

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 declare destructiveHint=true and readOnlyHint=false, but the description adds the concrete consequence: an existing file at that path is overwritten. That is exactly the kind of detail annotations cannot convey. It stops short of mentioning permission or workspace-boundary constraints.

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

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

Two short sentences, front-loaded with the action and its scope, then the destructive consequence. No filler or redundancy.

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

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

No output schema exists, so return behavior is undefined but not required. For a mutating write tool the description covers the overwrite risk but omits path format rules, size/encoding limits, and error behavior - adequate but with clear 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?

Schema description coverage is only 33% - just sessionId is documented. The description adds nothing about path semantics (relative vs absolute, whether it must stay inside the workspace) or content encoding, so it fails to compensate for the coverage gap even though the parameter names are largely self-explanatory.

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 (Write) and resource (text file) with the scope clarified as the session workspace, which distinguishes it from files_read, files_list and files_delete. It does not explicitly name a sibling or contrast itself with shell_exec, but 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?

No guidance on when to use this over alternatives such as shell_exec for file creation, nor any stated prerequisites beyond the implied session context. Usage is left entirely to 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), disclosing billing behavior ('billing runs until it stops'), timeout floor and default ceiling, the fact that browser_* tools are refused in shell-only mode, and the exportability constraints on credentials. These are real operational consequences an agent cannot infer from structured fields.

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?

Front-loaded with purpose and the sessionId contract, and every clause is informative for an 11-parameter tool. It is, however, a dense run-on paragraph that would be easier to scan as structured bullets; length is justified but the structure is not optimal.

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 still covers the return value (sessionId and how to use it), all parameter behaviors, and the cross-tool constraints (credential exportability, browser_* refusal). Nothing an agent needs to invoke this correctly 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 only 45%, so the description carries the burden and does: it explains browser/shell defaults, blockAds and cookieBanners semantics (including the 'reject' default), proxyType/proxyCountry/proxyCity including the two-letter country format, profile vs persistProfile, timeout bounds, and the credentials export rules. Nearly every undocumented parameter is filled in.

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

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

States a specific verb and resource ('Create a new isolated session') and enumerates exactly what is provisioned (Chrome browser, bash shell, shared /workspace disk). It also names the return value (sessionId) and its downstream role, which distinguishes it from siblings like session_resume and session_stop.

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 conditional guidance: 'browser: false with a shell is a shell-only session (no live view; the browser_* tools are refused)' and routes sign-in to 'browser_type with a credential' instead of credential export. However, it never states when to create a new session versus resuming an existing one (session_resume), the most relevant sibling choice.

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 known. The description adds genuinely new context beyond them: the scope of destruction (saved data, recording, logs) and the irreversibility warning. It stops short of noting permission requirements or whether deletion of an active/stopped session behaves differently.

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

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

Two short sentences, front-loaded with the consequence of deletion and closed with the safer alternative. Every clause carries information; nothing is 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?

No output schema exists, and the description plus annotations together convey destruction scope, irreversibility, and the alternative. It does not address error behavior (e.g. invalid or already-deleted sessionId) or whether deletion of an in-progress session is allowed, which are the remaining minor 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?

Only one parameter and schema description coverage is 100%, with the schema itself explaining the sessionId and its origin (session_create). The description adds no parameter-level detail, which is acceptable given the schema fully documents the single input.

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

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

States a specific verb+resource ('Delete a session') and immediately scopes it ('for good: what it saved, its recording and its logs are deleted now'). It is clearly distinguishable from session_stop and session_resume among the 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?

Explicitly routes the agent: 'This cannot be undone; use session_stop to keep it.' That names the alternative and the condition under which it should be chosen instead, which is exactly the when/when-not guidance needed for a destructive tool.

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, destructiveHint=false and openWorldHint=false. The description adds real behavioral context beyond that: newest-first ordering, that the last line yields the 'after' cursor for the next page, and that stopped sessions are included and revivable via session_resume. Missing only explicit default page size framing outside the parameter list.

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?

Front-loaded with the core purpose and return shape, then filters, then pagination and the resume pointer. Information-dense with little waste, though a couple of clauses (return-field enumeration, comma example) slightly overlap 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?

No output schema exists, so the description correctly enumerates the returned fields (id, status, kind, created) and explains pagination via the trailing cursor. Nothing an agent needs to call or interpret results is missing for a five-parameter list 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 already 80%, yet the description reinforces filter semantics with the comma-joined example ('RUNNING,STOPPED'), the q behavior (id prefix or userMetadata text) and the limit range with default. It adds a worked example and the cursor-pagination flow that the schema alone does not connect.

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

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

States a specific verb and resource (list the project's sessions) plus the exact return fields (id, status, kind, created) and default ordering (newest first). An agent can tell it apart from session_create, session_stop, session_resume and session_delete without opening any schema.

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

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

Gives an explicit use case ('Use it to find a session id again') and routes stopped-session recovery to session_resume. It clarifies that stopped sessions appear here too, but stops short of an explicit when-not-this-tool rule, so it is strong context rather than complete 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 already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds real value beyond that by disclosing that resume happens 'on a fresh machine', which explains the non-read-only hint. It does not say what happens to the original stopped session (consumed, replaced, deleted) or whether the returned session id is reused.

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

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

Two sentences, no filler, and the core behavior is front-loaded before the sibling caveat. Every clause carries information an agent can 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?

One required parameter with 100% schema coverage, no output schema, and annotations already carrying the safety profile, so little more is demanded of the description. The remaining gap is the lifecycle outcome (what happens to the old session and whether its id stays valid), which would matter for an agent chaining calls.

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% and the schema already documents sessionId ('Id of the stopped session, from session_create'), so a baseline 3 is warranted. The description adds a constraint beyond the schema by twice emphasizing the id must belong to a stopped session, which guards against passing a live session id.

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 (resume) and resource (stopped session) plus the outcome ('as it was when it stopped (same id, tabs and files)'), which tells an agent exactly what state is restored. It also positions itself relative to the other session tools, so it is distinguishable from siblings like session_create and session_stop.

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 second sentence ('The other session tools also do this on their own when given the id of a stopped session') is a genuine when-not hint: an agent learns this tool is often unnecessary because other session tools auto-resume. It stops short of an explicit 'use this only when...' directive, and there is no guidance on prerequisites or the fresh-machine side effect.

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 non-readonly, non-destructive, closed-world behavior, and the description adds material context beyond them: what is preserved (every tab, the files), that billing stops, and the retention-then-deletion lifecycle. It doesn't cover idempotency (what happens if the session is already stopped) or auth prerequisites, which keeps it from a 5.

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

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

A single front-loaded sentence pair with zero filler: effect, reversal path, and lifecycle are packed into two clauses and nothing is repeated from the schema or annotations.

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 lifecycle mutation with a single required param and no output schema, the description covers preservation, billing, resume path, and eventual deletion – enough for correct invocation. Minor gaps (idempotency on repeat calls, and the vague 'plan's retention days' without a definite value) keep it below 5.

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

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

Only one parameter, and schema description coverage is 100% – the schema already documents sessionId and its origin. The description adds no format or validation meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Stop a session') and immediately distinguishes the operation from a hard delete by noting the session is saved intact and only later deleted. Naming session_resume as the reversal path lets an agent separate it from session_delete without opening either schema.

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

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

Explicitly names the companion tool and condition ('Resume it later with session_resume'), which tells the agent this is the reversible-pause choice. It stops short of an explicit when-to-use-this-vs-session_delete exclusion, so the agent must infer the delete alternative from the 'then deleted' clause.

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 openWorldHint=true, but the description adds non-obvious behavior the schema cannot convey: state persistence (cd and export persist), initial working directory, the ./downloads location, and the timeout escape hatch. It omits what happens on timeout (killed vs. returned) and the default timeout, which are meaningful for a destructive 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 tight sentences, all front-loaded: capability first, then environment context, then the long-running escape hatch. Nothing is padding, though the downloads-location aside is the least essential sentence for the primary invocation decision.

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 open-ended shell tool with no output schema and no annotations until now, the description covers prerequisites, state semantics, and long-job handling well. It is missing return-value behavior (stdout/stderr/exit code) and timeout outcome, which an agent calling this tool would want.

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 only 33% (only sessionId documented), so the description must compensate. It references timeoutMs semantically ('longer than timeoutMs') and implies command is free-form bash, but it never documents the default, the 1-hour cap, or failure semantics on timeout. Partial compensation only, so baseline 3.

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?

'Run a bash command in the session's persistent shell' gives a specific verb (run) plus resource (bash command/shell) with the key qualifier 'persistent'. That qualifier alone separates it from every sibling (files_read, browser_*, session_*), so an agent can identify it without opening the schema.

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

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

It states the prerequisite ('Needs a session with a shell'), the working-directory context, and an explicit alternative path for long jobs: background with nohup and read job.log later via files_read. It does not say when to prefer this over e.g. files_write or browser tools, so it falls short of the when/when-not bar at 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?

The 'It only reads' clause merely restates readOnlyHint=true and earns no credit. The genuine addition is pagination behavior: pages come back 10 at a time and the returned `after` token continues the walk. That is useful operational context beyond the annotations, though it omits what signals the end of a crawl or how invalid crawlIds fail.

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

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

One sentence, front-loaded with what is returned and the pagination rule packed into a parenthetical. Every clause carries information; only the slightly broken grammar of the opening fragment 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?

With no output schema and no parameter descriptions, the description has to cover the return shape, and it only loosely does ('the state ... and its next pages'). An agent must call it to learn the response fields, how to detect completion, and what happens on an expired or invalid crawl. Adequate but with real 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?

Schema description coverage is 0%, so the description must carry the load. It does clarify that `after` is a continuation token returned by the previous call rather than an offset or page number, which is meaningful, but `crawlId` is left entirely undefined (presumed to come from web_crawl_start). Partial compensation for a two-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 names a specific resource (the state and next pages of a crawl) and ties it to the producing sibling, web_crawl_start, so an agent can distinguish it from web_search/web_extract/web_fetch. The phrasing is a sentence fragment ('The state of a crawl...') rather than a clean verb+resource, but the intent 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?

It establishes sequencing with web_crawl_start and describes the pagination loop ('pass the after it gives to go on'), which is real usage guidance. It never states when not to use this tool or how it relates to other read siblings such as web_fetch or browser_read, so usage is implied rather than fully specified.

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 openWorldHint=true and destructiveHint=false, so the safety profile is partly covered; the description adds the non-obvious behaviors: robots.txt compliance, same-host scoping by default, a bounded wait of waitSeconds, and the asynchronous partial-result contract with web_crawl_get. Only missing detail is whether an in-flight crawl can be cancelled or resumed.

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

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

Three sentences, no filler, and the critical facts (what it does, default scope, partial-return behavior) are front-loaded. Every clause carries distinct 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?

For an 8-parameter asynchronous crawl tool with no output schema, the description covers scope, safety, timing, output formats, and the two-phase retrieval pattern. An agent has everything needed to start a crawl and know what to expect back.

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 75%, and the description fills the gaps for the undescribed parameters: format (markdown/text/HTML), sameHost (host scoping), and waitSeconds (default 45). It adds no semantics for exclude/include/maxDepth/maxPages beyond what the schema already documents, but those are already well-described.

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

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

States a specific verb and resource (crawl a website from a start URL), names the output formats, and explicitly contrasts itself with the session-based siblings ("no session needed"). It also names web_crawl_get as the continuation path, so an agent can place it precisely among web_fetch/web_extract/web_crawl_get.

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 real routing context: no session required, public pages only, and "while it is still running, web_crawl_get gives the rest" tells the agent exactly what to do next. It does not explicitly say when to prefer web_fetch or web_extract over a crawl, so it stops short of full 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?

Beyond the readOnly/destructive/openWorld annotations, the description discloses rich behavior: cost model ('Uses a model, billed like other model calls'), a hard scope limit ('Public pages only'), and output fidelity ('A page that does not show a value gives null, never a guess'). These are exactly the traits annotations cannot express.

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?

Dense and front-loaded: the core action leads, then inputs, then output/cost/scope caveats. Every clause earns its place with no filler.

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

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

For a read-only tool with no output schema, it covers return format, missing-value behavior, cost, session needs, and page scope. It omits failure/error behavior and does not resolve the 'at least one of url/urls and prompt/schema' requirement left implicit by the zero required params.

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 50% schema coverage, the description carries meaningful param meaning: it clarifies url-vs-urls (single vs up to 10) and frames prompt and schema as alternative ways to specify fields. It does not document the url/urls exclusivity rules further, but it adds real value over 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 states a specific verb+resource+scope: 'Read up to 10 pages in a real browser and return the data asked for as JSON'. This is concrete and actionable. It implicitly separates itself from session-based browser tools ('no session needed') but never names a sibling like web_fetch or web_crawl_start, so the differentiation is not explicit.

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

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

It tells the agent how to supply inputs ('give url or urls, and a prompt... or a JSON Schema') and notes 'no session needed', which hints at the class of tool. However, there is no explicit when-to-use-this-vs-alternatives statement naming web_fetch, web_search, or web_crawl_start, so usage is only implied.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), but the description adds genuine behavioral context: rendering happens 'through a real browser', no session state is required or created, and blockAds is disclosed as a load-time refusal of ad/tracker sites rather than a post-fetch filter. It does not mention timeouts, failure behavior, or page-size limits.

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

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

Two tight sentences, front-loaded with the core action and return types, followed by the one non-obvious option. Nothing redundant; every clause carries information.

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

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

For a stateless read-only fetch with no output schema, the description covers the action, output formats, browser-based behavior, session independence, and the ad-blocking flag. Remaining gaps (error/empty handling, redirects, timeouts) are modest for a tool of this complexity.

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 carries the full burden and largely succeeds: it enumerates the three format values and explains blockAds as refusing ad and tracker sites during load, which adds meaning beyond the bare boolean name. The 'url' parameter is only implied ('a web page'), not characterized for expected input form.

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

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

The description names a specific verb and resource ('Fetch a web page') plus the return representations ('markdown, HTML or text'), and the phrase 'through a real browser' separates it from a plain HTTP fetcher. It never names a sibling tool explicitly, so the differentiation from web_extract, browser_read, or browser_navigate is left for the agent to infer.

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

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

'(no session needed)' gives a real selection signal against the session-based browser_* siblings, and blockAds is contextualized. However there is no explicit when-to-use/when-not statement and no alternative is named, so the routing guidance remains implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds genuinely useful context beyond that — the fresh, session-less browser (isolated context, no cookies/state carryover) — but says nothing about output format, image size, wait-for-load behavior, or timeouts for a rendering 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 short sentences, zero filler, with the fresh-browser context and the sibling routing instruction front-loaded. 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?

For a two-parameter, no-output-schema tool with full annotation coverage, this covers the routing decision and the one ambiguous parameter. Return-value detail isn't needed in the description, and nothing an agent needs to call it correctly 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 0%, so the description carries the burden; it fully explains the non-obvious parameter with "fullPage captures the whole page instead of the first screen," which is exactly the ambiguity an agent would hit. The remaining url parameter is self-evident from its name, so the gap is minor.

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

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

States a specific verb+resource ("take a screenshot of a web page") and immediately scopes it as running "in a fresh browser (no session needed)," which cleanly separates it from browser_screenshot among the siblings. An agent can pick the right tool without opening either schema.

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

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

Explicitly names the alternative ("To see the page a session is on, use browser_screenshot") and gives the condition that selects it, plus the precondition that no session is required for this tool. Both the when and the when-not are covered.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the return shape (titles, URLs, snippets) and a concrete cost model (counts against monthly searches, same search within an hour is free) that an agent cannot infer from 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 compact sentences, front-loaded with the identity and scope, then return shape, then the fetch/cost details. Nearly every clause earns its place, with only mild density packing two distinct ideas into the final sentence.

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

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

No output schema exists, so the description correctly carries the return-format burden and does so (titles, URLs, snippets). With annotations handling safety and the schema handling most params, the remaining gap is only the undescribed query/recency parameters, which is minor.

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 67% and the description reinforces the fetch semantics ('top 1 to 5 pages as Markdown in the same call'), which slightly exceeds the schema's bare wording. However, query and recency are undocumented in the schema and the description says nothing about recency values, keeping this at the baseline for a partially-covered schema.

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

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

States a specific verb+resource ('Search the web') and immediately differentiates scope with 'no session needed', which separates it from the many session-based sibling tools (browser_login, session_create, etc.). It also names the follow-up siblings (browser_navigate, web_fetch), so an agent can place it precisely in the toolset.

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 no session is required and routes the agent to browser_navigate or web_fetch to open a result, and to the fetch parameter to get pages inline in one call. It does not compare against other content-retrieval siblings (web_extract, web_crawl_start), so the 'when not' side is incomplete.

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