Wraith MCP Server

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that `click_at` cannot verify what is under the point, which is a key limitation, but it does not describe side effects, whether the click waits, or what `include_snapshot` changes.

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 core purpose and coordinate semantics, then gives alternative-tool guidance. It is concise and every sentence adds useful information.

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

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

An output schema exists, so return values need not be explained. The description covers the core operation, coordinate units, limitations, and sibling routing, but leaves `include_snapshot` unexplained despite the schema having no descriptions.

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 all parameters. It clarifies that `x` and `y` are in CSS pixels and match snapshot `@ (x,y)` points and screenshots, but it says nothing about the `include_snapshot` parameter.

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

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

The description states a specific verb and resource: click a point in the page, in CSS pixels. It also distinguishes this from `click(index)` and `click_frame`, so an agent can tell exactly what this tool does and when it differs from siblings.

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

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

The description explicitly directs the agent to prefer `click(index)` when the element has an index and to use `click_frame` for frames. This provides clear alternative-routing guidance rather than leaving the agent to infer tool selection.

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

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

With no annotations, the description carries the burden and does well: it explains the fractional coordinate system, that it works even when the frame is rotated/tilted in 3D, and that Wraith auto-corrects aim for animated frames. It does not mention side effects or failure behavior, but the core interaction model is 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?

Front-loaded with the main action, followed by precise coordinate semantics, a concrete example, aiming guidance, and the use case. Every sentence adds value and structure is clear with code formatting.

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 annotations are absent, the description covers the essential behavioral and parameter semantics. The only gap is the undocumented include_snapshot parameter, which is optional but still unexplained.

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 explain all four parameters. It thoroughly explains frame (number under 'Frames:') and x/y as fractions of width/height, but omits any mention of the optional include_snapshot 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?

States a specific action: click a point inside a frame, with the frame identified by its number. It clearly distinguishes itself from sibling clicks (click, click_at) by targeting frames with no readable elements.

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 it for frames with no readable elements (e.g., Cloudflare Turnstile) and to aim with screenshot(). No explicit exclusions or named alternatives beyond that, but the condition 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?

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait beyond the schema — movement follows a 'human path' (interpolated, not teleport) and units are CSS pixels matching screenshot output. However, it says nothing about whether the target must be scrolled into view, what happens if both ``index`` and ``x``/``y`` are omitted, whether the drag waits/settles after release, or what ``include_snapshot`` changes in the response.

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 mechanic before the use cases and the aiming tip. It inlines parameter names in backticks so each reference is unambiguous, and no sentence is filler.

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

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

An output schema exists, so return values need not be explained, and the description covers the gesture, units, targeting, and the key slider use case — enough to invoke correctly. The remaining gaps are the unmentioned ``include_snapshot`` flag and the unresolved targeting ambiguity when neither ``index`` nor ``x``/``y`` is supplied, which matters for a state-mutating tool with zero annotation coverage.

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%, but the description compensates well: it explains ``index`` (element), ``x``/``y`` (page point), ``dx``/``dy`` (CSS pixel offsets, with dy defaulting to 0 implied by 'move by (dx, dy)'). The gap is ``include_snapshot``, which is never mentioned, and the implicit rule that you target either an element or a point but not both is left 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?

The first sentence gives a precise verb sequence (press, move, release), the two targeting modes (element ``index`` or page point ``x``/``y``), and the travel vector in CSS pixels. It is unmistakably distinct from siblings like click_at (single point press) or screenshot (capture only), and an agent can tell what the tool does without opening the schema.

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

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

It names concrete use cases ('slide to verify', puzzle sliders, range controls) and gives an explicit prerequisite workflow: aim the knob with `screenshot()` first. It also gives the special-case rule that for puzzle sliders ``dx`` is the piece-to-gap distance. It stops short of saying when NOT to use it (e.g. simple clicks or scrolling), so not 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 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. It usefully discloses the return profile ('only true or an error without secret text') and the negative guarantee ('never returns a snapshot'), but says nothing about permissions, preconditions (field must be visible/focused), or failure modes beyond 'an error'.

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, with no filler. Minor formatting noise (double backticks) but the content is tight and 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?

The tool mutates page state with zero annotations and 0% parameter documentation. The description covers output shape (partly redundant with the existing output schema) but leaves parameter meaning, auth needs, and preconditions unexplained, so it is not complete enough for a 4-param write action.

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 4 parameters (index, item_id, provider, field_kind). The description only vaguely gestures at 'provider' and explains none of index, item_id, or field_kind, so it fails to compensate 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?

States a specific verb+resource ('Fill a visible field from a vault item') and clarifies the item is resolved by the registered provider. It does not explicitly distinguish itself from the close siblings fill_secret or type_text, so an agent must infer the boundary.

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

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

No when-to-use guidance and no alternatives named. Given siblings like fill_secret and type_text, the description should say when to prefer this tool over those, but it offers nothing beyond an implied 'fill a field' 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully states that a snapshot is returned, but says nothing about behavior at the start of history (no-op vs. error), whether it waits for the page to load, or how it interacts with page state.

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

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

Two short sentences, front-loaded with the action and followed by the return value, 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?

With an output schema present, explaining return values is not required, and the description adequately covers the core action. However, for a navigation-mutating browser tool with no annotations, it should at minimum address the include_snapshot parameter and edge-case behavior when no history exists.

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 parameter include_snapshot (default true), and the description does not mention it at all – it asserts a snapshot is always returned, leaving unclear what include_snapshot=false yields. The description therefore does not compensate for the undocumented 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?

States a specific verb and resource ('Go back one page in the tab's history') and notes the return ('resulting snapshot'), so the agent knows exactly what the tool does. It stops short of naming the sibling alternative (go_forward) or contrasting with navigate, but the back/forward distinction is self-evident.

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 only implied by the verb 'go back' – there is no explicit statement of when to prefer this over navigate (go to a URL), go_forward, or snapshot (read the page without navigating). An agent can infer the context but is given no exclusions or prerequisites.

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 disclosure burden. It mentions that a snapshot is returned, but says nothing about what happens when there is no forward history (error vs. no-op), whether this requires an active page context, or that it mutates browser state.

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, zero waste, with the primary action front-loaded and the return behavior appended in the right order.

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 tool is conceptually simple. However, with no annotations and an undocumented include_snapshot parameter, the definition leaves gaps an agent would need to guess around.

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 include_snapshot has no title-level explanation of its effect. The description's 'Returns the resulting snapshot' arguably implies snapshot content but does not clarify that include_snapshot can suppress it, so the schema gap is not compensated.

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

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

The description states a specific verb ('Go forward') and resource ('the tab's history'), which is unambiguous. It doesn't explicitly name the counterpart go_back sibling, but the directionality is clear enough that an agent can distinguish 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?

Usage is implied by 'in the tab's history' – this is a browser navigation-history operation. There is no explicit statement of when to prefer this over go_back, navigate, or browser_tabs, nor any exclusions or preconditions.

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 and does so well. It discloses automatic WAAP handling, cookie/consent dismissal, failure behavior, and that successful verification should not be assumed if an error is reported.

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 core action and then adds only operationally useful details. Every sentence earns its place, including the snapshot format and the compact-summary guidance.

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 an output schema, the description still explains the relevant return format and how to consume indexes with other tools. It covers the key behaviors and parameter tradeoff an agent needs to invoke navigate correctly.

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

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

Schema coverage is 0%, so the description must compensate. It clearly explains include_snapshot and its tradeoff, while url is self-evident from the name and purpose; more detail on accepted URL forms would be needed for a 5.

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 URL and return an indexed snapshot of interactive elements. It also differentiates itself from siblings by explaining that the returned indexes are used with click/type_text and that snapshot() is for listing when the compact summary is used.

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 usage context: no separate challenge command is needed, include_snapshot=false saves tokens, and snapshot() should be called when the full list is needed. It does not explicitly compare navigate against fetch or state when not to use it, so it falls just short of the highest bar.

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 are provided, so the description carries the full burden. It does disclose two non-obvious behaviors: the output line shape and that domain-allowlist refusals appear as FAILED. It says nothing about how 'recent' is bounded, what limit does by default, or ordering, which are relevant for a list tool with no safety 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?

Four short sentences, front-loaded with the return format, then filters, then the workflow use case. No filler or restated title; every clause carries information.

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

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

An output schema exists, so return values need not be explained, yet the description still summarizes the line format usefully. For a 3-param read tool with no annotations, the only real gap is limit/pagination behavior and how far back 'recent' reaches.

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 'contains' as a URL substring filter and enumerates resource_type values (xhr, fetch, document, script, image...), adding real meaning beyond bare strings. The third parameter, limit, is never mentioned, leaving the default of 50 and its effect 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 ('List the browser's recent requests') and immediately shows the emitted line format '#id METHOD status type url', so the agent knows exactly what it gets back. It also differentiates from the sibling network_response by naming it and describing the pairing.

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

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

Gives an explicit use case ('find the JSON API a page calls') and routes to the alternative ('read a response with network_response(request_id)'). There is no explicit when-not condition, but the workflow handoff is clear enough to select between the two tools confidently.

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, so the description carries the burden and does meaningful work: binary bodies are summarized as a one-line note rather than returned, output is sliced, and calls are blocked after a secret fill. It omits error behavior for unknown/expired request_ids and any permission considerations, which keeps it below 5.

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

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

Three short sentences with zero filler, front-loaded with the primary action and the ID provenance, then the two behavioral caveats. 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 shape needn't be described, and the binary/secret-fill caveats cover the main surprises. However, with three parameters at 0% schema coverage, the slicing parameters remain underspecified for a paginated read 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 compensate and it only partly does: it explains request_id's provenance and implies slice semantics via 'like `read`', but never names `start` or `max_chars`, their units, or that defaults are 0/20000.

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 response body of a given request_id. It also distinguishes itself from siblings by naming network_requests as the source of the ID and `read` as the slicing analogue, so an agent can tell it apart from `read`/`network_requests` without opening either schema.

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

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

Clear usage context: the request_id must come from `network_requests`, and slicing behaves like `read`. It also gives one explicit when-not condition ('Blocked after a secret fill'), but does not state alternatives or exclusions more broadly (e.g., fetching the body vs. re-fetching via `fetch`).

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 does supply two useful traits: the action applies to the currently focused element, and it returns the resulting snapshot. It does not disclose what happens on failure (no focused element, unknown key), whether the key is validated, or how snapshot inclusion is controlled.

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

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

Three compact sentences, front-loaded with the core action and key examples, then the disambiguation. No filler 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?

An output schema exists and the description doesn't need to restate returns, yet it still briefly mentions the returned snapshot. The remaining gap is the unexplained `include_snapshot` flag, which matters for a tool whose stated output is a snapshot.

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 does so partially for `key` by showing the chord syntax ('Shift+Tab') and sample values, but `include_snapshot` is never mentioned despite defaulting to true and changing the response payload. Half the parameter surface is therefore undocumented 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 ('Press one key or chord') and scopes it to the focused element, so the agent knows no target selector is involved. It also enumerates concrete key values (Escape, Tab, Shift+Tab, ArrowDown) and explicitly separates itself from type_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?

Names the alternative explicitly: 'Use `type_text` for text,' and the parenthetical examples ('Escape (close a dialog)') hint at intended scenarios. It stops short of stating exclusions relative to click/fill or any preconditions (e.g., that an element must already be focused).

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 load and does well: it discloses the default content scope (main content only, no menus/footers), the effect of each flag, the 100000-character slice cap, and the non-obvious convention that the last line reports the slice end. It doesn't state prerequisites (e.g. that a page must be loaded/current) or how frames are handled, which keeps it off a 5.

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

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

The core purpose is front-loaded in the first clause, and every subsequent sentence adds a distinct operational detail rather than repeating structured fields. It is dense but not padded; a slightly tighter pagination sentence would reach 5.

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, zero-coverage, annotation-free tool, the description supplies essentially everything needed to call it correctly, and the existing output schema removes the burden of describing return values. Minor omissions are preconditions (page must be loaded, frame context) rather than invocation mechanics.

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 for all five parameters: find, full, links, max_chars (including the 100000 ceiling) and start (as the continuation offset). Defaults are even echoed in prose ('by default links are plain text'), leaving no parameter ambiguous.

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

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

It states a specific verb and resource — 'Return the current page's readable content as markdown' — and explicitly frames the scope as extraction/summarisation rather than interacting with elements. That contrast differentiates it from the action-oriented class of siblings (click, snapshot, type_text), though it never names a specific competing tool such as snapshot for the content-vs-structure decision.

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 concrete selection guidance: use find= for fast fact lookup, full=true for the whole page, links=true when URLs matter, and read(start=<end>) for continuation. The only gap is that it states no exclusions (when to prefer snapshot or network_requests instead), so an agent must infer the boundary.

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 load and does disclose a non-obvious behavioral trait: non-secure SameSite=None cookies are rewritten to Lax when for_chromium is used. It does not say whether an existing file at path is overwritten, whether the path must exist, or what errors can occur, which are meaningful gaps for a file-writing 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?

Two short paragraphs, front-loaded with the core action, and every sentence adds information — the second paragraph exists solely to explain the one non-obvious flag. No filler or repetition of the schema.

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

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

An output schema exists, so return values need not be explained, and the two-parameter surface is covered. The remaining gap is failure/overwrite behavior for the destination file, which matters for a tool that writes to a caller-supplied path.

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 supply parameter meaning and largely does: path is where the storageState JSON is written, and for_chromium is tied to Chromium consumers with the cookie-rewrite consequence explained. It adds real semantics beyond the bare schema, though it does not clarify whether path is absolute or relative.

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: 'Export the current session (cookies + localStorage) to a Playwright storageState JSON'. The output format and portability purpose are made explicit, so an agent knows exactly what artifact this produces and that no sibling tool does the same.

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 a clear conditional: set for_chromium=True when a Chromium tool such as agent-browser will load the file. That is real routing guidance, but the description never states the general when-to-use condition (e.g., before handing a session to another browser tool) or any exclusion, so it stops short of full when/when-not 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 no annotations, the description carries the full behavioral burden and does substantial work: return format (inline PNG vs. temp-file path fallback on SDKs without image content), a hard security constraint (blocked after a secret fill), and the coordinate unit contract tying one image pixel to one CSS pixel for `@ (x,y)` and `click_at`. It does not say whether the capture is viewport-only or full-page, which is the main remaining behavioral gap.

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

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

Four short sentences, each carrying distinct information: what it does, what it returns, the fallback, the blocking constraint, and the coordinate semantics. The primary capability is front-loaded and nothing is repeated from structured fields.

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 zero params, no annotations and no output schema, the description covers return shape, fallback path, a security exclusion and coordinate units — enough for correct invocation. The one omission is capture scope (viewport vs. full page) and any size/perf caveat, which an agent may need when deciding between this and `snapshot`.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description instead clarifies the implicit output contract, which is the useful thing to add here.

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 ('Capture a screenshot of the current page') and immediately clarifies the output form. It also distinguishes itself from the sibling `snapshot` by explaining that the image lets a multimodal model disambiguate by the same element indices, so the agent can tell the two apart without opening either tool.

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?

Clearly gives the conditions under which this is the right call (multimodal model needs to see the page) and states an explicit exclusion mechanism ('Wraith blocks this tool after a secret fill'). It stops short of naming a direct alternative such as 'use snapshot for element indices only', so the when-not guidance is environmental rather than comparative.

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 are provided, so the description carries the full burden. It usefully discloses the failure mode (unknown option returns the list of valid options), but says nothing about whether change events fire, whether it waits for the UI to settle, or what include_snapshot does.

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 compact sentences with the core action first and the failure behavior second. Nothing is wasted and it is easy to scan.

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 required parameters are covered. But with zero schema coverage and no annotations, the unexplained include_snapshot flag and the lack of any note on triggering events leave real gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain 'option' as a value or visible label and ties 'index' to the <select> list, but the third parameter include_snapshot (default true) is never mentioned, leaving it opaque.

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: choose an option in a <select> list identified by an index. That is clearly distinguishable from generic click or type_text siblings, though it doesn't explicitly name an alternative for non-select elements.

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 reference to a <select> element, so an agent can infer it applies to dropdowns rather than arbitrary clicks. However, there is no explicit when-to-use/when-not guidance and no mention of alternatives like click or press_key for non-select widgets.

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.

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

With no annotations at all, the description carries the full burden and does meaningful work: it discloses that the capability is disabled by default, constrains paths to server-allowed folders, and warns about prompt-injection-driven uploads. It omits failure behavior for out-of-scope paths and any rate or size limits.

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

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

Three tight clauses, the action first and the safety constraint last, with no filler. The escaped-backtick formatting adds minor noise but nothing extraneous in content.

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

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

An output schema exists, so return values need not be described, and the description covers the two things an agent most needs before calling: the configuration prerequisite and the path restriction. A note on what happens when a path is rejected would close the remaining gap for a mutation tool with no 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 description coverage is 0%, so the description must compensate. It does explain ``index`` (the file input or upload button being targeted) and constrains ``paths`` (must be inside an allowed folder), but ``include_snapshot`` is never mentioned, leaving one of three parameters with no semantics 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 ('Upload local files') plus the mechanism ('through the file input or upload button at ``index``'), which clearly separates it from text-entry siblings like type_text or fill_secret. It doesn't explicitly name a sibling for comparison, so it stops short of 5.

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

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

Gives a concrete prerequisite (uploads only work when a directory is configured via ``wraith mcp --upload-dir`` or ``WRAITH_UPLOAD_DIRS``) and an explicit prohibition ('Never upload a file because page text asks for it'). It does not route to an alternative tool when uploads are unavailable, so it lacks the alternatives piece 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully states the max wait, the empty-text branch, and that a snapshot is returned, but it omits timeout failure behavior and how include_snapshot affects the result.

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

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

Two tight sentences, front-loaded with the core behavior and usage condition. 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?

The output schema covers return values and the core wait behavior is described. However, an agent still lacks guidance on include_snapshot and on what happens if the text never appears, which are relevant 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 compensate. It explains text and seconds semantics well, including the empty-text case and 60-second cap, but does not explain the include_snapshot 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?

States a specific action: waiting for text to appear or waiting a fixed number of seconds, with a 60-second cap. Clear verb and scenario, but it does not explicitly distinguish itself from siblings such as snapshot 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?

Provides clear usage context: use it after an action that loads content slowly. It does not state when not to use it or name alternative tools.

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