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

Annotations only declare readOnlyHint=false and openWorldHint=true, leaving the description to explain effects: what happens if there is no history entry, whether it waits for the page to load, and whether it affects the session's forward stack. None of that is disclosed; the phrase only implies history traversal.

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 fragment with zero waste but is undersized for a tool with a required undocumented parameter. It is under-specification rather than effective conciseness.

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

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

The tool is simple (one parameter, no output schema), so a short description could suffice, but with 0% schema coverage and thin annotations the agent still lacks the session_id meaning and the no-history failure behavior. The definition is not complete enough to invoke confidently.

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% for the single required session_id parameter, so the description must explain what a session is and how to obtain the ID. It says nothing about the parameter at all, leaving the agent with an undocumented required field.

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?

"Browser back button" identifies the resource (browser history) and the action (go back), so an agent can infer it navigates backward in a session's history. However it is close to a restatement of the name and does not explicitly distinguish it from siblings like navigate, click, or switch_tab, which could also change the current page.

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

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

There is no guidance on when to use this instead of navigate, click, or switch_tab, and no mention of preconditions such as requiring existing history. The agent must infer all routing decisions 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?

Annotations only say readOnlyHint=false and openWorldHint=true; the description adds genuinely new behavior — consequential buttons (send, post, buy, delete, connect) are paused pending explicit user approval via `confirmed`, and browser confirm dialogs can be auto-accepted. That approval-gate semantics is the key non-obvious trait of this tool and is disclosed. Not fully transparent about what happens when confirmation is absent beyond being 'paused' (error? queue? no-op?).

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 targeting options, then the two behavioral caveats — a sensible ordering with no filler sentences. The line breaks and multi-line wrapping make it read as slightly fragmented, and the parenthetical "(e.g. "Messages")" example is doing more work than the surrounding prose.

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

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

Covers targeting, the approval gate, and dialog handling for a mutation tool with no output schema — the essentials an agent needs to call it safely. Missing the stale-ref failure mode, session_id semantics, and ref-vs-text precedence, which matter for a stateful open-world browser 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 0%, so the description carries the load; it documents 4 of 5 parameters (ref, text, confirmed, accept_dialog) with examples and conditions. `session_id` is left undescribed and the precedence/conflict rule when both `ref` and `text` are supplied is unstated.

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") plus the two mutually exclusive targeting strategies (snapshot `ref` or visible `text`), with inline examples. An agent can immediately distinguish this from siblings like type_text, select_option, or press_key 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 concrete operating context: `ref` must come from "the latest snapshot," which implicitly sequences snapshot → click, and it explains the text fallback's rationale ("keeps working when the page layout changes"). It also states exactly when `confirmed` must be true. It stops short of naming alternatives (e.g. use select_option instead of clicking a dropdown, or press_key for keyboard activation).

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 and openWorldHint=true. The description adds useful behavioral context: save=True (default) writes refreshed cookies back to the vault, which is a meaningful side effect beyond 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?

Two concise sentences with no filler. The primary action is front-loaded, and the save behavior is included only because it affects how the tool should be invoked.

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

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

The tool is simple, has an output schema, and annotations cover safety/open-world behavior. The description discloses the key save side effect, though it could briefly clarify what "closing" entails.

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 explains the save parameter's default and effect, but says nothing about session_id beyond its required presence in the schema.

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

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

States a specific verb and resource: "Close a session." This is clear enough to distinguish it from siblings like open_session and save_session, though it does not explicitly compare itself to those alternatives.

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 name and the save default explanation, but the description does not say when to close versus save a session or when to use this tool instead of related session-management tools.

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

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

Annotations already indicate this is not read-only and is open-world; the description adds useful behavior by saying the session is saved encrypted and the login window is closed. It does not contradict the annotations.

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

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

The description is two short sentences with the main action front-loaded and the parameter note directly afterward. There is no wasted text.

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 an output schema present and annotations covering safety traits, the description gives enough context to invoke the tool correctly. The only minor gap is that it does not say more about failure cases or interaction with sibling session 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 description coverage is 0%, so the description must explain the sole parameter. It does: profile is the name used by start_login, and it is optional when only one login window is open.

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 two-part action: save the logged-in session from the login window and close that window. It is clear about the resource and operation, but does not explicitly distinguish itself from siblings like save_session or close_session.

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 this is used after start_login and refers to the login window, but it does not explicitly say when to use this tool instead of save_session or close_session. The optional profile rule gives some usage context, though.

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, openWorldHint=true, and readOnlyHint=false, so the safety profile is known. The description adds that deletion is 'from disk,' but it does not state irreversibility, undo behavior, permission requirements, or what happens if the profile is in use.

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 front-loaded sentence with no wasted words. It immediately conveys the action and scope.

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

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

The tool has low complexity, rich annotations, and an output schema, so the description does not need to explain return values. However, it still omits profile identifier semantics and any when-to-use guidance relative to sibling 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?

There is one required 'profile' parameter with 0% schema description coverage. The description only implies that 'profile' refers to a saved login, but it does not clarify whether it is a name, ID, path, or required format.

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 ('Delete'), resource ('saved login'), and scope ('from disk'). It clearly distinguishes this action from siblings such as list_profiles and rename_profile.

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 no guidance on when to use this tool versus alternatives like rename_profile or list_profiles, nor does it mention prerequisites or exclusions. Usage is only implied by the tool name.

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

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

Annotations already indicate this is not read-only and operates in an open world. The description adds meaningful behavioral context: it closes the topmost popup via its close/'Not now' button or Escape, and warns to inspect the popup before dismissing it. It does not describe return behavior, but no output schema exists.

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

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

The description is two sentences, front-loaded with the primary action and followed by essential usage guidance. The examples and fallback instruction all add practical value without unnecessary verbosity.

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 one-parameter action with no output schema, the description is nearly complete: it explains the action, fallback, and when to avoid it. The main omission is any explanation of the session_id parameter.

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 one required parameter, session_id, with 0% description coverage. The description does not explain what session_id represents or how it should be supplied, so it fails to compensate for the schema 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 uses a specific verb and resource ('Close the pop-up on top of the page') and gives concrete examples of popup types. It clearly distinguishes this action from clicking within a meaningful popup.

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

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

It explicitly states when to use this tool and when not to: read the popup first, and if it asks something the user's task depends on, use click instead. It also explains the fallback method of pressing Escape if no close button exists.

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 safety is covered. The description adds useful behavior — full-page scope and returning [eN] refs — but leaves out matching semantics (case sensitivity, substring vs. token, result limits, whether stale refs are refreshed), which matter for a search tool in a browser automation flow.

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

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

Two sentences, no filler, with the scope constraint and return format front-loaded. 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?

An output schema exists, so return values needn't be spelled out, and the description still previews the [eN] ref shape. For a two-parameter read tool this is nearly complete; the only gap is the undocumented session_id and the unspecified match semantics.

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. It does explain `query` meaningfully (matches label, role, or link, via 'contains' substring semantics), but `session_id` is never mentioned, leaving half the parameters undocumented in both schema and 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 ("Search the whole page ... for elements whose label, role or link contains query") and contrasts the scope against the snapshot sibling tool's partial coverage. An agent can distinguish this from snapshot/read_text 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?

The parenthetical "not just the first items of the snapshot" gives clear context for when this is preferred over snapshotting. It stops short of explicit exclusions (e.g., when to use read_text or re-run snapshot instead), so it's a clear context rather than a full when/when-not rule set.

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 openWorldHint/readOnlyHint=false annotations, it discloses the mechanics precisely: a window opens on the user's screen, the call effectively blocks until they close it, and fresh cookies are returned to the session. That is exactly the kind of state-change and blocking behavior an agent needs before invoking a mutating, human-in-the-loop 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, front-loaded with the core action, then the when-to-use examples, then the mechanism and the required follow-up call. Nothing is redundant.

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?

An output schema exists, so return values need no explanation, and the description covers the interaction model and the mandatory snapshot follow-up well. The unexplained 'reason' parameter remains a small but real gap for a tool at 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does not: neither session_id nor reason is mentioned or explained anywhere in the text. Only an indirect inference from 'this session' hints at 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?

The description states a specific action (hand the current page over to the user in a visible window) with concrete triggering cases: CAPTCHAs, 2FA prompts, expired logins. An agent can distinguish this from automation siblings like click/type_text because it explicitly delegates control to a human.

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 clear when-to-use criteria ('anything you shouldn't or can't do') and even prescribes the follow-up step ('Then call snapshot'). It never contrasts with the login siblings (start_login/complete_login), which is the main gap for a handoff-vs-automated-login decision.

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

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

The annotations already establish that this is a read-only, non-destructive, open-world operation, and the description adds useful behavioral context by listing returned attributes and clarifying site filtering. It does not add permission, rate-limit, or pagination details, but it does more than repeat the annotations.

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

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

The description is short and front-loaded, first stating what is listed and then focusing on the only parameter. Every sentence adds concrete meaning without bloat.

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 one-parameter read-only tool with an output schema and clear annotations, the description is largely complete. It could be slightly stronger by explicitly stating that omitting site lists all saved logins, but an agent can reasonably infer that from "List saved website logins."

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 parameter burden. It explains that site filters to a single site, gives example domains, and warns that a site may have several accounts; the main omitted detail is what happens when site is null or omitted.

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 gives a specific verb and resource: "List saved website logins," and enumerates the key profile attributes. This clearly distinguishes it from sibling profile-mutation tools such as rename_profile and delete_profile.

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 that the site parameter narrows results to logins for that site and notes that one site can have several accounts. However, it does not explicitly say when to choose this tool over related siblings like open_session or start_login, so usage guidance is implied rather than fully 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?

With annotations already declaring readOnlyHint=false and openWorldHint=true, the description adds the allowed-domains guardrail, which is meaningful behavioral context. It does not disclose side effects (e.g., leaving the current page), wait behavior, or error handling, so it is adequate but not rich.

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

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

A single front-loaded sentence with a parenthetical constraint; every clause carries useful information and nothing is redundant.

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 navigation tool, the description plus annotations convey the core action and a security boundary. However, session_id is left unexplained and there is no output schema or behavioral detail about navigation results, so important gaps remain.

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% for both required parameters. The description adds a constraint for the url parameter (allowed domains) but never explains session_id or how it relates to the profile, so it only partially compensates for the undocumented schema.

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

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

The description states a specific action ('Go to a URL') and resource, making the core function immediately clear. It also adds the allowed-domains constraint, but does not explicitly distinguish from siblings like open_session or back, so it stops short of the top score.

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 parenthetical adds a prerequisite ('must be within the profile's allowed domains'), which is useful context. However, it does not say when to use navigate versus open_session, back, or switch_tab, leaving alternatives 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?

Annotations declare readOnlyHint=false and openWorldHint=true, but the description adds real substance beyond them: the browser is headless, authentication is supplied by a saved profile, the call returns a session id and page snapshot, and the screenshot flag has a documented default and an ASSERTIFY_SCREENSHOTS=1 override. It does not say whether an existing session is replaced or how many sessions may coexist, which would matter given the multiple session-related siblings.

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

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

The core behavior and return values are front-loaded in the first sentence, with the screenshot detail correctly deferred to a second paragraph. Slightly hurt by the awkward mid-sentence line break and indentation in the screenshot block, which looks like a formatting artifact rather than intentional 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?

No output schema exists, and the description does helpfully states it returns a session id and page snapshot. However, for a session-lifecycle tool with a 0%-covered three-parameter schema, it leaves the url parameter undocumented and omits session semantics (one session at a time? replaces prior? must close before reopening?).

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 parameter meaning, and it only partly does. 'profile' and 'screenshots' are both explained with useful semantics (logged-in-as-saved-profile; default off, env-var override, when to enable), but 'url' — the optional initial navigation target — is never mentioned anywhere.

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 ('Open a headless browser') plus a key distinguishing attribute ('already logged in as the saved profile') and the return values ('session id and page snapshot'). An agent can tell this apart from siblings like close_session, switch_tab, or open_sessions 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?

The screenshot paragraph gives explicit conditional guidance ('Turn it on when the user wants to watch'), which is genuinely useful. But there is no guidance on when to call open_session itself versus alternatives such as start_login/complete_login or list_profiles, nor on whether a session must be opened before navigate/click. Usage for the core action 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 only declare readOnlyHint=false and openWorldHint=true, so the description adds real value: it discloses that one session_id is returned per account and that sessions are concurrent and must be closed. It does not note limits on how many can be opened or what happens on partial 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?

Front-loaded purpose sentence, followed by a compact per-parameter list and a lifecycle note. Slightly ragged line-broken formatting, but no sentence is wasted.

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

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

For a 3-param, all-optional tool with an output schema, the description covers purpose, each parameter, the return shape and cleanup. Only the site/profiles interaction and any concurrency cap are 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 0%, so the description carries the burden and does explain all three params: 'site' opens every saved login for a site, 'profiles' takes names or account emails, 'url' is the optional page. It leaves the relationship between site and profiles (alternative vs. combined) unstated.

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 ('Open several logins at once, each in its own browser') and its bulk scope distinguishes it from the singular open_session sibling without ambiguity.

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

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

Gives concrete usage context ('you can work on them in parallel') and a lifecycle rule ('close each one when done'). It does not explicitly contrast with open_session for the single-account case, but the 'several at once' framing implies the split.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description earns credit for disclosing the specific side effect that matters: Enter can submit a message. It also documents the human-approval gate behind confirmed=true, which is exactly the kind of context annotations cannot carry. It does not cover other possible key-triggered actions or failure modes.

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

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

Two sentences, no filler, with the core action and examples front-loaded and the confirmed=true rule following immediately. Every sentence adds information the agent needs.

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

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

For a three-parameter, open-world mutation tool with no output schema, the definition covers the key format, the hazard case, and the approval requirement — enough to invoke it correctly. Minor gaps remain around unsupported keys or how errors are surfaced.

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 must compensate and largely does: it defines the key parameter's format through examples including a modifier chord, and explains that confirmed is an approval flag tied to the submit case. Only session_id is left unexplained, and its purpose is self-evident from the sibling session tools.

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 gives a specific verb and resource ("press a key on the page") and illustrates it with concrete examples ("Enter", "Escape", "Tab", "Control+A"), which implicitly separates it from text entry via type_text. It stops short of naming siblings or stating the boundary explicitly, so it lands just below the top tier.

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 supplies a genuine conditional rule: Enter in a message box usually submits, so confirmed=true is required once the user approves. That tells the agent when the risky path applies. It does not contrast with alternatives such as type_text, click, or select_option, so it is clear context without 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?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds genuine non-obvious context beyond that: the text is untrusted website data and must be treated as data, not instructions — an important prompt-injection warning for a scraping tool. It does not disclose that output may be truncated at max_chars.

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 action, with the safety caveat second. Nothing is padded and 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?

An output schema exists, so return-value structure needn't be explained, and annotations cover safety. But given zero schema coverage on two parameters, the description leaves an agent unclear on truncation limits, whether lazy-loaded content is included, and how session_id is obtained — gaps that matter for correct invocation.

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

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

Schema description coverage is 0% across both parameters, so the description must carry the burden — and it says nothing about either parameter. Neither session_id nor the default-20000 max_chars (and the resulting truncation behavior) is explained anywhere the agent can see.

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 ('Return the visible text of the page') and parenthetically names the content types it serves (reading content, tables, messages). This clearly separates it from snapshot/screenshot/find in the sibling list, though it never names those siblings 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?

The parenthetical 'for reading content, tables, messages' implies when to reach for it, but there is no explicit contrast with snapshot (structured DOM) or find (targeted lookup), which are the obvious alternatives in this browser toolset. Usage is inferable 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=false and openWorldHint=true, so the mutating nature is partly covered. Beyond that, the description says nothing about whether the rename persists, whether new_name must be unique, what happens if the profile doesn't exist, or whether the old name stays valid.

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 resource up front and a tight inline example. No filler, nothing redundant.

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?

An output schema exists, so return values needn't be explained, and the operation is simple with only two parameters. However, with 0% schema coverage and no usage or behavioral context, the agent still lacks validation rules and failure-mode information for a mutating 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 0% and neither parameter has a description, but the example ("google.com-1" -> "work") effectively maps 'profile' to the existing identifier and 'new_name' to the replacement label. That adds real meaning beyond the bare schema, though it doesn't specify format constraints or allowed characters.

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 (rename) and resource (a saved login/profile), and the concrete example "google.com-1" -> "work" makes clear what a profile is and what renaming does. It also implicitly distinguishes it from list_profiles/delete_profile by naming the mutation, though it doesn't explicitly contrast with those 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 statement of when to use this versus alternatives such as delete_profile or start_login, and no prerequisites (e.g., that the profile must already exist). The only guidance is the illustrative example, which implies but does not state context.

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 and openWorldHint=true, so the mutation/network profile is known. The description adds that the write target is encrypted persistent storage, which is meaningful context. It does not disclose overwrite semantics, whether a prior vault entry is replaced, or failure behavior for a mutation 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?

One short sentence with no filler, and the destination ('encrypted vault') is front-loaded where it matters. It is brief because it omits information rather than because it is well-scoped.

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?

An output schema exists, so return values need not be explained, and the tool is single-parameter. However, for a persistence mutation sitting beside close_session and open_session, the definition omits ordering/precondition guidance that an agent needs to call it correctly.

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

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

Schema description coverage is 0% and the single parameter session_id is never mentioned in the description, so nothing explains what identifier is expected (current session vs. profile id) or its format. With one undocumented parameter the description should compensate but does not.

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 ... back') and resource ('the session's current cookies/storage') plus destination ('encrypted vault'), so the operation is concrete. It doesn't explicitly separate itself from close_session, which is the sibling an agent will most likely confuse it with.

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 when-to-use guidance at all: nothing says whether this must be called before close_session, whether close_session persists automatically, or in what workflows saving is required. The agent must infer the call site entirely, which is risky given close_session exists right next to 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 readOnly/openWorld/non-destructive, so the bar is lower; the description still adds genuinely non-obvious behavior: the image is returned inline AND persisted to a file whose path is exposed, and it instructs the agent to surface that path to the user. It does not mention that a file write is a side effect, but nothing contradicts the annotations.

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

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

Two short sentences with the core action front-loaded and the output-handling instruction second; nothing is redundant and every clause carries information the agent needs.

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

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

With no output schema, the description correctly takes on the return-value explanation (inline image plus file path) and covers the element-vs-page scope. It stops short of stating session prerequisites or what `full_page` does, which is the only remaining gap for a three-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 0%, so the description must carry the parameter burden. It explains `ref` meaningfully (an element ref from the latest snapshot), which is the only non-obvious parameter, but says nothing about `full_page` or `session_id`, leaving two of three undocumented in both places.

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 ("Screenshot the current page") plus the scoped variant ("or just one element"), and ties the element case to a ref produced by the sibling `snapshot` tool. That implicitly separates it from snapshot/read_text, but the differentiation is left for the agent to infer rather than stated outright.

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 downstream guidance ("when the user wants to see something, show them that path") but never says when to prefer this over `snapshot` or `read_text`, nor any precondition such as needing an active session or a prior snapshot for `ref`.

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 one real behavioral trait beyond annotations: lazy-loaded content materializes only in the subsequent snapshot, which shapes the follow-up call. It does not clarify that scroll position persists across calls (relevant given readOnlyHint=false) or how to return to the top, so transparency is partial.

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 the verb, direction, unit, and the follow-up caveat in parentheses. Every clause earns its place and nothing is padded.

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

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

For a simple three-parameter viewport tool with no output schema, this covers the essentials plus the lazy-load follow-up behavior. The main shortfall is silence on scroll scope (whole page vs. container) and whether position is retained between 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 0%, so the description must carry parameter meaning. It covers direction implicitly via the quoted "up"/"down" and amount via "pixels", but never states the valid values as a closed set, nor the defaults (down, 800), and says nothing about 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 (scroll) and resource (the page) with the two controlling parameters (direction, amount in pixels). It is clearly separable from siblings like navigate, snapshot, and find, though it does not name those alternatives 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?

The parenthetical hints at the workflow (lazy-loaded content shows up in the next snapshot), which implies when to call it, but there is no explicit when-to-use, when-not-to-use, or named alternative such as navigating directly or using find to jump to an element.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description must add the nuance — and it does disclose that `option` accepts either a visible label or a value, which is real behavioral information. It omits failure modes (option not found, element not a select), whether change/input events fire, and what happens when both ref and label are supplied. 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?

A single tight sentence with the action and target mechanism front-loaded; the parenthetical about label-or-value is functional, not filler. It is under-specified rather than verbose.

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

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

This is a mutating, open-world browser action whose annotations are minimal and which has no output schema and no parameter descriptions. The description should cover ref/label mutual requirement or precedence and error behavior; neither is present.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains `option` (label or value) and the `ref`/`label` pair, but says nothing about session_id, gives no format hint for `ref` (e.g., a snapshot handle), and never states that one of ref/label must be provided even though both are nullable in the schema.

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

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

States a specific verb+resource pair ("Choose an option ... in a <select> element") and names the targeting mechanism (ref or label). It is clearly distinguishable from siblings like click or type_text, though it doesn't explicitly contrast itself with them.

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 <select> mention implies the when-to-use case (prefer this over click/type_text for dropdowns) but never says so explicitly. No exclusions, no prerequisites (e.g., needing a snapshot ref first), no guidance on choosing between ref and label.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds the key behavioral consequence that enabling causes every subsequent action to return a screenshot. It does not say whether the setting persists, the default state, or whether it can be toggled mid-session without side effects, but it adds real context beyond the annotations.

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

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

A single front-loaded sentence with the effect in parentheses; every clause earns its place and there is no filler.

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

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

An output schema exists so return values needn't be explained, and the core mutation is clear. However, for a two-required-parameter mutation tool with undocumented parameters, the description leaves gaps around session_id format and the semantics of enabled that an agent must guess.

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

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

Schema description coverage is 0%, so the description bears full responsibility. It only loosely maps 'for a session' to session_id and 'on or off' to the enabled boolean; it gives no format for session_id, no statement of what true/false mean, and no defaults.

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 ('Turn ... on or off') and resource ('per-step screenshots ... for a session'), and the parenthetical clarifies the effect, distinguishing it from the sibling 'screenshot' tool. It is clear but doesn't explicitly name the sibling it contrasts with.

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 effect '(each action then returns a screenshot)' implies when to enable, but there is no explicit when-to-use/when-not guidance, no mention of prerequisites (e.g., an open session), and no alternatives named.

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, openWorldHint, and non-destructive behavior. The description adds useful context beyond that: it explains the returned content, the ordering of pop-ups under '## Pop-up', and that warnings flag CAPTCHAs and sign-in pages. It does not cover limits, pagination, or ref stability, but the added behavioral detail is meaningful.

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 concise sentences with the most important information front-loaded: what is returned, followed by pop-up ordering and warning semantics. Every sentence contributes useful context without waste.

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?

An output schema exists, so return values need limited explanation, and the description still summarizes them. For a read-only snapshot tool with one obvious session_id parameter, this is nearly complete, though it could clarify when to call snapshot versus related siblings.

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

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

There is one required parameter, session_id, with 0% schema description coverage. The description never mentions session_id or explains its role, so it does not compensate for the missing schema documentation. The parameter is obvious from its name, but the description adds no semantic value.

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

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

The description clearly states what the tool returns: current URL, title, and interactive elements with [eN] refs. The mention of refs 'to use in other tools' implicitly links it to click/type tools, but it does not explicitly distinguish itself from siblings like screenshot, find, or read_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?

Usage is implied by 'refs to use in other tools,' which suggests calling snapshot before an interaction. However, there is no explicit guidance on when to use this versus screenshot, find, or read_text, and no stated exclusions or alternatives.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), it discloses behavioral traits the annotations cannot: the window is visible, the user types credentials by hand, 'The agent never sees the password', and read_only constrains the agent from typing, submitting, sending or buying. That is exactly the kind of secret-handling and capability-boundary context an 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?

The purpose sentence is front-loaded and the per-parameter lines are dense but each earns its place. It runs longer than strictly necessary, and the profile line stacks several sentences that could be tightened, but there is no filler.

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

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

The tool is a multi-step human handoff with four optional/required parameters and an output schema that covers return values, and the description supplies the full workflow (start, user logs in, call complete_login), the secret model, and the capability limits. Nothing an agent needs to invoke 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 must carry all parameter meaning, and it does: url is the login/home page, profile is a saved name with an empty-means-derive-from-account rule, allowed_domains defaults to the url's base domain and bounds navigation, and read_only defines what the agent may not do. Every one of the four properties is explained with behavior, not just a restatement of the type.

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

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

The description states a specific verb and resource ('Open a visible browser window') and immediately scopes the intent to a human-in-the-loop login, which cleanly separates it from the agent-driven open_session and from the follow-up complete_login. An agent can pick it 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?

It names the completion step explicitly ('Call complete_login once the user says they're done') and explains the repeat-login case ('Log in again with no name to add another account'). It never explicitly contrasts itself with open_session or the other sibling session tools, so the when-not is 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 flag readOnlyHint=false and openWorldHint=true, so the mutation profile is covered. The description adds one genuinely non-obvious behavioral fact — that new tabs and popups become active automatically, making an explicit switch unnecessary. It does not cover what happens with an out-of-range index or how session scoping behaves.

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 with zero waste; the core action is front-loaded and the 0-based caveat is attached directly to the parameter it governs.

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 focus-switching tool with no output schema, this is close to sufficient — action, indexing convention, and auto-activation behavior are all present. The only gap is any explanation of the required `session_id`.

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 meaningfully clarifies `index` as 0-based, which the schema does not, but says nothing about `session_id` (how a session is identified or obtained). Half the parameters remain undocumented in both places.

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 ('Make ... the active tab') and resource ('tab `index`'), and specifies the 0-based indexing convention. An agent can distinguish it from open_session/close_session without opening a 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?

Usage is implied by the purpose (switch focus among tabs within a session) but the description never says when to call it versus a sibling like open_session or navigate, nor any preconditions. The note about popups auto-activating hints at when it is NOT needed, which is a partial but real signal.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds genuinely useful context by disclosing that the operation replaces existing field contents (destructive to prior value) and that submission may send something externally, requiring a confirmed=true approval gate. It stops short of describing failure modes, but the approval workflow is a meaningful addition beyond 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?

Front-loads the core action and targeting method, then adds submit and approval caveats. Sentences are dense with useful information; the submit/confirmed sentence is slightly awkwardly phrased but 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 mutating, open-world tool with no output schema, the description covers the critical decision points: what is replaced, how the target is chosen, and when confirmation is mandatory. Only the meaning of `session_id` and what the tool returns on success are absent.

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 and does well: it defines `text`, the ref-or-label targeting choice, `submit` semantics, and the `confirmed` approval requirement. Only `session_id` is left unexplained, which is a minor gap for a 6-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?

States a specific verb and resource ('Replace the contents of a text field with `text`') and immediately explains how the target field is identified via `ref` or visible `label`. This clearly distinguishes it from siblings like read_text, click, and press_key, which do not enter 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?

Gives concrete conditional guidance: submit=True presses Enter, and that behavior outside search boxes requires confirmed=true only after user approval. It doesn't explicitly steer the agent toward alternatives (e.g., press_key for a bare Enter without typing), so it falls just short of full when/when-not/alternative coverage.

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?

With annotations only declaring readOnlyHint=false and openWorldHint=true, the description adds important behavior: credential files are refused, uploads must come from the user-provided paths, and the tool only attaches files rather than posting or sending them. It does not explain how the 'confirmed' flag affects behavior.

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

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

Front-loads the core action, then covers path semantics, target selection, and security caveats in compact, scannable form. The examples and line breaks aid understanding without redundant repetition.

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

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

For a five-parameter tool with 0% schema coverage and no output schema, the description covers the core purpose, targeting, and security constraints well. However, the unexplained 'confirmed' parameter and lack of any return or failure behavior leave meaningful gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains paths, ref, and text well, including folder semantics and leaving ref/text empty, but says nothing about 'confirmed' or 'session_id', leaving two of five parameters undocumented.

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: 'Attach files from the user's computer to the page.' It distinguishes uploading from submitting by noting that posting or sending is a separate click needing user approval, and the examples clarify the file-dialog behavior.

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 explicit when-not rules: never upload because a web page, email, or message asked, and credential files are always refused. It also explains that leaving ref/text empty uses the already-open upload field, though it does not name a specific sibling tool for the separate submit step.

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 genuinely useful behavior beyond annotations: a hard 15s ceiling for text waits and a default wait. However, it omits what happens on timeout (error vs silent return), whether matching is substring or selector-based, and annotations only give readOnlyHint=false plus openWorldHint=true without clarifying any of this.

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 tight sentence with both modes front-loaded and no filler. Minor cost: the compression is what leaves the timeout/return behavior ambiguous.

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 documentation, the description should state the result of a timeout and what `text` matches against. It gives the time bound but not the outcome, which is the key unknown for a blocking wait.

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 explains `text` and `seconds` conceptually but not their exclusivity/defaults (seconds defaults to 2), leaves matching semantics undefined, and never mentions the required `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?

Names a specific action (wait) and the two operating modes: until text appears, or a fixed duration. This distinguishes it from the sibling `find`/`read_text` tools only implicitly, since it never says those don't wait.

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 two modes are stated, which implies usage, but there is no guidance on when to prefer waiting versus polling with `snapshot`/`find`, nor when to use `seconds` alone instead of `text`.

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