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

No annotations are provided, so the description carries full burden. It discloses that the tool injects cookies and modifies browser state for subsequent navigate calls, but does not mention side effects, required permissions, or what happens to existing state. The behavioral impact is partially described but lacks completeness.

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

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

The description is concise with two focused paragraphs. The first paragraph front-loads the core purpose and effect, and the second efficiently covers the optional parameter. Every sentence adds useful information without 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?

Given the tool has only two parameters, no annotations, and an output schema (whose details are not needed), the description fully covers the tool's effect, parameter meaning, and usage context. It explains the prerequisite for navigate and the fallback logic for profiles, making it complete for the tool's 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?

The description provides clear semantic meaning for both parameters: 'domain' is the target for which to borrow an identity, and 'profile' is an optional path substring with documented fallback behavior (first Zen, then Firefox). This adds significant value beyond the bare input schema, which only gives names and types.

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

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

The description clearly states the verb 'borrow' and the specific resource: a warmed, already-authenticated identity from a real Firefox/Zen profile. It distinguishes itself from sibling tools by explaining its role in injecting cookies for authenticated navigation, which is unique among the listed tools.

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

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

The description implies usage context ('core Wraith move for sidestepping reputation-based defenses') but does not explicitly state when to use versus alternatives or when not to use. There is no direct comparison to other tools, so guidance is implied rather than explicit.

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

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

It discloses the core behaviors: the default action, parameter roles, and return value for select/new actions. However, there are no annotations, and the description does not state what close returns, how side effects like opening a new tab affect the active tab, or error behavior.

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

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

The description is compact and front-loaded with 'Manage tabs,' then immediately enumerates actions and return behavior. Every sentence carries necessary information, with 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?

The description covers actions, parameters, and returns for most cases, but leaves gaps: the close action's return value is not specified, and there is no mention of error handling or prerequisites. An output schema exists, which may cover returns, but the missing close behavior still leaves the description slightly incomplete.

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%, but the description fully compensates by explaining all three parameters: action values (list/select/new/close), index (used by select/close), and url (optional for new). It also clarifies the default action, giving agents complete semantic grounding beyond raw schema.

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

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

The description clearly identifies the tool as managing browser tabs and enumerates specific actions (list, select, new, close), making its function concrete. It is distinct from sibling tools like navigate or snapshot, though it does not explicitly name 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?

The description explains how each action works and what parameters apply, but gives no guidance on when to use this tool versus sibling tools such as navigate or read. There are no exclusions, preconditions, or routing cues to help an agent choose it over 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?

With no annotations, the description carries the full burden and explains what the tool returns and how to interpret the Changed line (url change / new elements / nothing). It does not discuss error handling or waiting behavior, but the disclosed effect-reporting is meaningful behavioral transparency.

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 focused sentences front-load the core action and then explain the return behavior without any filler. 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 two-parameter interaction tool with an output schema, the description covers input source, parameter behavior, and result semantics. Minor gaps remain around invalid-index behavior and page-loading side effects, but nothing critical for basic invocation is missing.

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

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

Schema coverage is 0%, so the description compensates by clarifying that index refers to an element from the latest snapshot and that include_snapshot=false produces a compact change summary. It stops short of specifying indexing details such as zero-based vs one-based, but adds clear meaning to both parameters.

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

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

The first sentence uses a specific verb ('Click') and resource ('element with the given index from the latest snapshot'), making the action unambiguous. This distinguishes it from sibling tools like snapshot, navigate, and type_text without needing to name 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 description establishes the prerequisite of using an index from the latest snapshot, so an agent knows it must have a fresh snapshot before calling. It does not explicitly name alternatives or exclusion conditions, but the operational context is clear.

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

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

With no annotations, the description carries full burden. It declares the tool is passive and returns a list of vendor names (empty if none), implying no side effects. Could be more explicit about no modifications, but sufficient.

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

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

Two sentences with front-loaded purpose and examples. No unnecessary words; every sentence adds value.

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

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

Tool is simple (one param, no nested objects), and description clearly states input, behavior, and output (list of vendor names or empty). Output schema exists but description already covers return value.

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?

Single parameter 'url' with 0% schema description coverage. The description clarifies it's the target URL for fingerprinting, which is adequate. Could add format expectations but not critical.

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?

Clearly states the tool fingerprints a URL's WAAP/anti-bot defenses with specific vendor examples. Distinguishes from sibling browser interaction tools (click, navigate, etc.).

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 notes 'Passive; no browser needed', guiding agents to use it when they want to identify defenses without browser overhead. Lacks explicit when-not-to-use 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?

With no annotations, the description carries the full behavioral burden and meets it: it discloses browser relaunch, un-partitioned Firefox prefs, cookie injection, navigation, consent dismissal, anomalous-session/2FA risk, and run-variable score behavior. It also tells the agent what the tool returns regarding reCAPTCHA params and the cookie-bearing reload request. This is thorough and far beyond a generic statement.

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 detailed but every sentence carries load: core action, mechanism, generality, profile selection, risk warning, and verification directive. It is front-loaded with the core action before diving into mechanics and caveats. Nothing feels redundant or 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?

The tool is complex, involving browser launch, cookie injection, identity risk, and POST-session verification, and the description covers all of it. An output schema exists, so detailed return-shape explanation is not required, but the description still summarizes what comes back. An agent has enough information to call it correctly and to anticipate failure behavior.

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

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

Even though schema coverage is 0%, the description supplies complete meaning for both parameters: `url` is the target to be opened, and `profile` is a path-substring selector that defaults to the first Zen profile then falls back to Firefox. It explicitly explains the `null` default behavior. This fully compensates for the empty schema descriptions.

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

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

The description opens with an explicit verb and object: it borrows a logged-in Google identity's reputation and opens a URL to mint a high reCAPTCHA-v3 score. It clearly distinguishes itself as the GENERAL v3 pass, separating it from the sibling navigation and borrow tools. The scope is unambiguous and tells the agent what the tool does.

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

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

It tells the agent when to use this tool (general reCAPTCHA-v3 pass) and gives operational context such as launching the browser with un-partitioned prefs and injecting cookies. It adds a WARNING about primary-identity risk and instructs verifying against the real protected endpoint rather than trusting a score readout. It falls just short of a 5 because it does not explicitly name sibling alternatives or state 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?

With no annotations present, the description carries the full burden and mostly succeeds: it discloses no-browser execution, TLS fingerprinting, session replay semantics, and the returned status/classification/body preview. It does not mention error behavior for a missing session_file, but the core behavioral traits are clear.

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, front-loaded with the most important distinction and no filler. Every sentence contributes either usage guidance, the session-file format, or the routing rule.

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

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

The description covers the tool's niche, how to obtain a session file, what to do on challenge classification, and what the response contains. Given the output schema exists, return-value detail is appropriately minimal.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain url and session_file, including the JSON shape, but method and impersonate are left undocumented beyond their names and defaults. This leaves a clear gap for two optional parameters.

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

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

The description opens with a specific verb and resource: 'No-browser TLS-impersonation request' targeting a URL. It clearly distinguishes this tool from siblings like navigate by emphasizing 'NO browser launch' and 'cheap fast path'.

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?

Explicit guidance is provided: 'Use this to replay an already-authenticated/cleared session cheaply; escalate to navigate only when the returned classification is challenge.' This tells the agent exactly when to use this tool and when to switch to an alternative.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool never accepts or returns the secret value and that fills are constrained by provider, origin, field kind, expiry, and use limit. However, it does not disclose side effects, behavior on expired/mismatched capabilities, or any other runtime effects beyond the act of filling.

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 three sentences with no filler. The first sentence delivers the core function, and the following sentences provide meaningful constraint and secrecy information. 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?

Given the tool has three parameters, 0% schema coverage, and no annotations, the description is not complete enough for an agent to invoke it reliably. The output schema exists, so return values need not be explained, but the missing definitions of 'index' and 'include_snapshot', plus the lack of failure/edge-case behavior, leave significant 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 compensate for the bare parameter schema. It adds meaning for the capability object by explaining that it names a provider and an opaque handle, but it says nothing about 'index' or 'include_snapshot'. Since two of three parameters remain effectively undocumented, the description only partially compensates.

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

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

The description clearly states a specific action and object: 'Fill a field from an opaque secret capability.' It also communicates the key distinguishing trait — the secret value is never accepted or returned — which differentiates it from sibling tools like type_text. This is not a tautology; it tells an agent what the tool actually does.

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

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

The description implies when to use the tool by explaining that the capability is bound to exact origins, a field kind, an expiry, and a use limit. However, it never explicitly says when to prefer fill_secret over alternatives such as type_text or click, and it gives no exclusions. Usage context is present but left largely 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that the tool automatically passes WAAP/anti-bot challenges, dismisses common cookie/consent banners, and returns a specific indexed line format. This goes well beyond a generic 'open URL' statement and gives the agent useful expectations about side effects and output.

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

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

The description is compact and front-loaded: purpose, behavioral traits, output format, and optimization tip appear in a logical order. Every sentence earns its place, with no filler or redundant restating of the tool name.

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

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

Given the output schema exists and the description already covers output format, automation behaviors, and the include_snapshot option, an agent has enough context to invoke navigate correctly and decide whether to call snapshot later. Combined with sibling names, this is a complete and self-sufficient definition.

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

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

Schema description coverage is 0%, so the description must compensate. It explains include_snapshot meaningfully ('compact summary', 'saves tokens', 'call snapshot() when you need the list'), while url is self-explanatory. This adds semantic value beyond the schema, though the description does not dive into URL formatting or error cases.

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

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

The description opens with a specific verb and resource: 'Open a URL and return an indexed snapshot of the page's interactive elements.' It clearly distinguishes this tool from siblings like fetch, read, and screenshot by emphasizing the indexed snapshot and the automatic handling of WAAP/anti-bot challenges and banners.

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

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

The description provides clear context for when to use the snapshot output ('use the index with click / type_text') and how to choose between a full snapshot and a compact summary ('Pass include_snapshot=false... call snapshot()'). It does not explicitly contrast navigate with siblings like fetch or read, but the usage context is well implied and actionable.

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?

No annotations provided, so description must cover behavior. It states output is readable content as markdown but doesn't disclose if page loading is required, failure conditions, or that it's a read-only operation. Adequate but could add more behavioral context.

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 concise sentence with clear structure, front-loading the purpose and adding contextual use-case. No wasted words.

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

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

With zero parameters and an existing output schema, the description fully covers the tool's functionality, format, and intended use. Complete for a simple 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?

No parameters exist, so schema coverage is 100%. Description correctly adds no param info, as none needed.

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?

Description clearly states the tool returns readable content as markdown, specifying the format and use case (extraction/summarisation). It distinguishes from acting on elements, providing clear purpose.

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

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

Explicitly contrasts with acting on elements, giving context when to use this tool vs interaction tools (click, type_text). Could be more explicit about exclusions (e.g., not for navigation or screenshots), but provides sufficient 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the end-to-end encryption of the cookie jar, that it 'opens it in memory' rather than persisting it, injects cookies into the live browser context, that no password ever reaches the agent, and that the drop is 'single-use and self-destructs after pickup.' These details clearly set expectations about security, side effects, and session lifecycle.

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

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

The description is front-loaded with the primary action in the first sentence, then each subsequent sentence adds meaningful context: the workflow, security model, and the single-use nature. There is no repetitive filler or irrelevant detail, making it appropriately sized for the technical complexity it conveys.

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 single-parameter tool with no annotations but with an output schema present. The description covers the input semantics, the operational process, the security guarantees, and the lifecycle of the drop. Combined with the output schema, the definition is complete enough for an agent to correctly invoke and understand the tool's behavior.

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

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

The input schema only defines 'code' with a title and no description, giving 0% schema coverage. The description fully compensates by explaining that the code is a one-shot pairing code provided out of band, and elaborates on the workflow around it. This gives the agent complete semantic understanding of the sole parameter.

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

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

The description opens with a specific action: 'Pull a synced login from a one-shot pairing ``code`` and inject it.' This clearly identifies the tool's resource (a synced login/pairing code) and the verb (pull/inject), and context about subsequent navigate calls distinguishes it from navigation or browsing tools. It is unambiguous about what the tool accomplishes.

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

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

The description gives a concrete usage scenario: 'A laptop runs ``wraith profile sync`` and hands you the pairing code out of band.' It explains when to use the tool (after receiving a pairing code) and its effect on later navigate calls. It does not explicitly name alternatives or when-not-to-use conditions, but it provides clear situational guidance sufficient for an agent to apply it appropriately.

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 no annotations, the description carries the full behavioral burden. It discloses the main side effect (writing cookies + localStorage to a storageState JSON at path), but it does not mention whether the file is overwritten, whether an active authenticated session is required, or what happens if the session has no cookies/localStorage.

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, well-paced sentence with no filler. The core action and destination are front-loaded, and the 'portable, reusable authenticated session' addition earns its place by explaining why this export is valuable.

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

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

For a one-parameter tool with an output schema present, the description covers the essential what and where. However, it is incomplete on edge-case behavior such as overwrites, failure modes, and prerequisites, which an agent might need to invoke it confidently without annotations.

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. It clarifies that 'path' is the destination for the exported JSON, which is useful, but it does not provide details like file naming conventions, relative vs. absolute paths, or extension expectations beyond the implied JSON.

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 (export), a specific resource (current session cookies + localStorage), a concrete output format (Playwright storageState JSON), and a destination (path). It is clearly distinguishable from sibling tools like navigate, click, or read.

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

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

The phrase 'a portable, reusable authenticated session' gives clear context for when to use this tool: persist auth state for later reuse. It does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden and handles it well. It discloses the primary return format (inline PNG), the fallback behavior when image content is unsupported (temp PNG path), and the important restriction about Wraith blocking the tool after a secret fill.

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

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

The description is compact and front-loaded. The main action appears first, followed by three specific, non-redundant behavioral details. Every sentence contributes useful information without filler.

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

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

Despite having no output schema and no annotations, the description explains what the call returns in both supported SDK modes and notes a critical limitation. For a zero-parameter tool, this is complete enough for an agent to know what will happen and how to interpret the result.

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

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

The tool has zero parameters and the schema already reflects that completely. Since there are no parameters to describe, the baseline of 4 is appropriate, and the description does not need to add parameter-level detail.

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

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

The description opens with a clear verb and resource: 'Capture a screenshot of the current page.' This is unambiguous, but it does not explicitly differentiate from sibling tools like snapshot, so it falls at 'clear but no sibling differentiation.'

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

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

The description provides a concrete use context: returning an inline PNG so a multimodal model can see the page and disambiguate by element indices. It also states a clear exclusion by noting that Wraith blocks the tool after a secret fill, though it does not name alternative tools or when to prefer them.

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 no annotations, the description carries the full burden. It does disclose meaningful behavior: scrolling the page and returning either a fresh snapshot or a compact summary when include_snapshot=false. However, it does not explain side effects, failure cases, or what 'compact summary' entails, so coverage 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?

The description is a single, front-loaded sentence with no filler. Every clause adds useful information: the action, the direction options, and the effect of the include_snapshot parameter.

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 browser action with an output schema present, the description covers the action and both parameter behaviors. It is slightly incomplete only because it does not explicitly route the agent away from sibling tools like snapshot or read, but nothing required to invoke the tool 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 compensate, and it does. It explains the meaningful values of direction ("down" or "up") and clarifies that include_snapshot=false yields a compact summary instead of a snapshot. Both parameters are given semantics beyond their bare schema types.

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 action and resource: scroll the page, with direction values "down" or "up". The core verb 'scroll' clearly distinguishes this tool from siblings like navigate, click, snapshot, and read, even without naming 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 description implies the tool is used when the page needs to be scrolled, but it never explicitly states when to use this versus snapshot, read, or navigate. There are no alternative tool names, exclusions, or prerequisite conditions such as requiring a page to be loaded.

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?

No annotations provided; description clarifies it produces an indexed snapshot of interactive elements. Could mention performance implications but generally transparent.

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

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

Single sentence, concise, front-loaded with purpose. No unnecessary words.

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

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

Given no parameters and an output schema, the description fully covers when and what the tool does. No 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?

No parameters; baseline 4. No additional info needed.

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?

Clearly states the tool re-perceives the page and produces a fresh indexed snapshot of interactive elements, distinguishing it from siblings like screenshot or read.

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

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

Explicitly says to use after DOM changes, providing clear context. Could be improved by contrasting with alternatives but sufficient.

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 no annotations, the description carries the full behavioral burden and discloses that the input is cleared before typing and that Enter is pressed when enter=true. It also states return behavior (snapshot vs compact summary), though it does not mention possible page navigation side effects 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?

A single dense sentence front-loads the primary action, then adds clearing, Enter submission, and return behavior in order of importance. There is no filler or duplication of schema details.

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

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

The description covers all functional aspects needed to invoke the tool: preconditions within the action, conditional behavior, and return variants. The output schema exists, so return specifics are not necessary; the only real gap is where the input index comes from, but this is reasonably inferable in a browser-automation context.

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 parameter coverage is 0%, but the prose maps every parameter to its effect: text is typed, index selects the input, enter triggers submit, and include_snapshot=false returns a compact summary. It adds meaning that the schema titles lack, though it does not elaborate on what index refers to or the summary's structure.

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

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

The description opens with a specific action ('Type text into the input') and identifies the resource by index. It adds concrete behavioral details (clears first, Enter submission) that make the tool's job unmistakable and distinguish it from siblings like fill_secret.

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 is given about when to choose this tool over fill_secret, click, or read. The description explains mechanics but not the context or exclusions that would help an agent select it correctly.

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