DrissionPage MCP Server

by jumodada

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.0
Disambiguation4/5
Most tools have clearly distinct scopes via prefixes (page, element, browser, tab, frame, shadow, network, storage, wait). A few pairs overlap in concept (page_screenshot vs page_screenshot_save, element_click vs page_click_xy) but descriptions clarify their different use cases.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern with domain prefixes like page_, element_, browser_, and tab_. This makes the API predictable and easy to navigate despite the large number.
Tool Count1/5
69 tools is extremely excessive for any single MCP server. Even a comprehensive browser automation suite should be split into multiple focused servers to avoid overwhelming agents.
Completeness5/5
The tool surface covers the full browser automation domain: navigation, tabs, elements, frames, shadow DOM, dialogs, network, storage, permissions, downloads, uploads, and waits. No obvious dead ends or missing lifecycle operations.
Average 3.8/5 across 69 of 69 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 85 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and non-read-only, but the description adds no behavioral detail beyond the basic action. It does not mention that existing input content is cleared by default (via the 'clear' parameter) or disclose any other side effects, so it adds no transparency beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is efficient, though it is terse to the point of under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich input schema, annotations, and presence of an output schema carry most of the contextual load, so the core action is adequately specified. However, the description does not synthesize key behaviors (like default clearing or observe mode) or provide high-level guidance on complex targeting, leaving the definition functional but thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—every parameter (text, clear, observe, timeout, selector) is documented in the input schema, including the complex selector union and its variants. The description itself contributes nothing about parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type') and a clear resource ('input element'), making the core action obvious. However, it does not explicitly distinguish this tool from closely related siblings like keyboard_press or element_select, so it is clear but not maximally differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, prerequisites, exclusions, or references to alternative tools. It only states the action itself, leaving the agent to infer when this tool should be selected over siblings such as keyboard_press, element_click, or element_select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so destructive nature is clear. Description adds minimal behavioral context (e.g., no mention of unsaved work or browser process exit). With annotations carrying the safety burden, description is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Could benefit from slight expansion to clarify scope, but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, description is incomplete: ambiguous scope (page vs browser), no mention of return value (though output schema exists), and no relation to sibling tools. Leaves important questions unanswered for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description need not explain parameters. It sufficiently communicates the tool's sole action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Close the current page/browser', which identifies the action and resource but is ambiguous whether it closes a single page/tab or the entire browser process. Inconsistency between name 'page_close' and title 'Close Browser' further blurs purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'tab_close' or 'page_navigate'. Lacks context on prerequisites, alternatives, or when not to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no additional behavioral context such as triggering mouseover events, waiting for element visibility, or potential side effects of hovering. It merely restates the action without going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is as concise as possible while conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple hover action, the description plus schema and annotations may be minimally sufficient, but it lacks guidance on when to use this tool relative to sibling tools and does not mention the structured target options or offset capabilities. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with selector and offset parameters having descriptions in the schema. The tool description itself adds no parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move the mouse over an element' clearly identifies a specific action (hover) and a target (an element). It is more specific than a tautology and matches the tool name, but it does not explicitly distinguish itself from related siblings like page_pointer_move or element_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not explain when to prefer hover over click, mention typical use cases like tooltips or dropdown menus, or exclude coordinate-based alternatives such as page_pointer_move.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, already signaling a mutating operation. The description adds no extra context about side effects, such as layout changes or potential reloads, and does not state whether the resize is persistent only for the current session. It fails to disclose any behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point without any filler or repetition. It is well-structured and easy to parse, maximizing information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple resize tool with a schema covering parameters and output schema present, the description is minimal but adequate. However, it lacks context about when to use the tool and any potential side effects, which limits its completeness for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (width and height) with descriptions, giving 100% coverage. The description adds no additional meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to resize the browser window to specified dimensions. The verb 'resize' is specific and the resource is the browser window. It differentiates from sibling navigation and automation tools, though it doesn't clarify whether it affects the viewport or the outer window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or any alternatives. It does not mention prerequisites, such as needing an active page, or when resizing might be appropriate. Without this context, an agent may misuse or overlook the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by stating the isolated context, bounded auth challenge, Fetch handler cleanup, and retention of the authenticated tab until closed. These behaviors are not visible in the annotations and provide useful expectations, but it does not describe failure behavior or session persistence details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs multiple behaviors and is mostly front-loaded. The phrase 'clean Fetch handlers' is cryptic and may confuse agents, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operational aspects (isolated context, auth, retention) but omits details like what happens on auth failure, whether the tab is brought to focus, or how to close the context. Given the tool's complexity and the presence of an output schema, it is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 20%, and the description does not explain the meanings of url, username, password, or timeout beyond what the schema already shows. The phrase 'bounded' could hint at the timeout parameter, but it is too vague to count as compensation, so parameter guidance is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool opens an isolated Chromium context and answers an HTTP auth challenge, which clearly identifies its purpose and distinguishes it from sibling navigation tools like page_navigate. However, 'open' is less specific than 'navigate' and the tool name is not restated, so it is clear but not perfectly explicit about URL navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus page_navigate or other navigation tools. It implies the need for HTTP authentication by mentioning the auth challenge, but it lacks an explicit alternative or exclusion, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it mentions that successful results echo cookie values for MCP callbacks and verification, and that the batch is bounded. This provides useful insight into return behavior and limitations without contradicting the annotations (readOnlyHint=false, destructiveHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. The first sentence states the core action, and the second adds valuable information about the result. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema is rich with many cookie fields (name, value, same_site, priority, etc.), the description only covers the batch concept and echo result. It does not explain field semantics, required vs optional fields, or potential side effects. For an agent to invoke correctly, it would need to rely entirely on the schema, which does not provide human-friendly descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description completely fails to explain the 'cookies' parameter or its sub-fields. The only hint is 'batch', which merely paraphrases the schema's array type. No additional meaning is provided for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set a bounded batch of browser cookies' with a specific verb and resource, clearly distinguishing it from sibling tools like browser_cookies_get, browser_cookies_delete, and browser_cookies_clear. The action and scope are immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does, leaving the agent to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds limited behavioral context. The term 'beta' hints at experimental nature, and 'optionally clear it' clarifies the clear parameter's effect, but no additional details about side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no unnecessary words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop action with one optional parameter, the description is mostly adequate. However, it could mention that the listener must have been started via network_listen_start, or what happens if called when no listener is active.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'clear' parameter is fully described in the schema (100% coverage). The description says 'optionally clear it', which adds minimal value beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('beta network observation for the active tab'). It distinguishes from sibling tools like network_listen_start and network_listen_wait by implying it stops an ongoing observation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., waiting for a network event). It does not mention prerequisites (e.g., must have started a listener first) or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating action. The description adds that input is not echoed in the result, which is useful behavioral context. However, it doesn't describe other side effects like potentially overwriting existing content or how special key sequences behave. With annotations covering the safety profile, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of fluff. Every word adds value: it states the action, target, and a key behavioral detail. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with annotations and output schema present, the description covers the essential purpose, target, and a return behavior. However, it lacks usage guidelines (when to use vs alternatives), which is a minor gap. Overall, it's fairly complete but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both 'keys' and 'interval' already described. The description adds no additional parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate since the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send keyboard text/keys to the active page element', specifying the verb and resource. The phrase 'active page element' differentiates it from tools like element_type which target specific elements, but it doesn't explicitly name alternatives. It also mentions the return behavior, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it targets the currently focused element, nor does it contrast with element_type or other typing tools. The usage context is implied but not explicitly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds 'bounded' and the scoping options, but it does not disclose output shape, ignored-node behavior, or the include_values secret-leak protection that appears only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It efficiently communicates the core action and target scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema, output schema, and annotations cover a lot of the operational detail, and the description conveys the key abstraction and boundedness. However, it lacks contextual usage guidance and leaves important behavioral details like node limits and value-inclusion defaults to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description alludes to scoped selector/frame/shadow targets but does not explain max_nodes, include_values, or include_ignored. With only 50% schema description coverage, the description does not compensate for parameter meanings left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'a bounded Chromium accessibility tree' and names the scope variants (page, selector, frame, shadow). This directly distinguishes it from sibling page_snapshot and frame_snapshot tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives like page_snapshot or frame_snapshot, nor any exclusions or prerequisites. The description implies its use case only through the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds no new behavioral traits (e.g., blocking nature, unit of time, or potential side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with robust annotations and output schema, the description is adequate. It could mention blocking behavior, but overall completeness is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'seconds' is well-documented in the schema. The description adds no additional context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Wait' and the resource 'specific amount of time', distinguishing it from sibling tools like wait_for_element or wait_for_url which wait for conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., wait_for_element, wait_until). The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds selector interpretation behavior (bare selectors are CSS, text: prefix) but doesn't mention return behavior, timeout defaults, or scoping with frames/shadow roots. With annotations covering the safety profile, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and immediately give a useful syntax rule. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich with frames, shadow hosts, and an accessibility target mode, but the description only mentions CSS/XPath and text matching. It omits the accessibility role/name target kind and frame/shadow scoping hints, relying heavily on the schema to communicate the full capability set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the selector and timeout parameters. The tool description repeats the selector syntax already present in the schema (bare=CSS, text:...), adding no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds an element on the page using CSS selectors or XPath, which is a specific verb+resource. The singular 'an element' distinguishes it from element_find_all, and the syntax rule for bare selectors vs text: adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like element_find_all. The only usage guidance is about selector syntax, not about choosing the right tool for a scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds 'page/viewport geometry' as a specific scope, but it does not disclose behavioral details such as whether the tool waits for the element (though a timeout parameter exists), what happens if the element is not found, or what exactly constitutes 'state'. This is consistent with annotations but adds only moderate context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action 'Return' and immediately states the resource. There is no unnecessary wording or repetition, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema, so return values need not be described. However, the description is vague about what 'state' includes (e.g., visibility, enabled, bounding rect) and does not contextualize when this tool is preferable over other element_get_* siblings. Given the complex selector schema and the large sibling list, the description feels incomplete for an agent to confidently select this tool without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a selector or accessibility target,' which maps to the selector parameter's two variants, but it does not explain the structured sub-fields like shadow_hosts or frame_selectors. The schema already provides detailed descriptions for these. The timeout parameter is not mentioned in the description at all. Since schema coverage is 50% (only selector and timeout on the top level), the description adds some clarity but does not fully compensate for the undocumented timeout behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return DrissionPage element state and page/viewport geometry for a selector or accessibility target.' This specifies a concrete verb and resource, and the mention of state and geometry distinguishes it from sibling getters like element_get_text, element_get_attribute, and element_get_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like checking visibility, dimensions, or viewport position, nor does it exclude cases handled by other element getters. There is no explicit comparison or reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the mutation safety profile. The description adds a useful behavioral trait: 'without global frame state', indicating the tool does not persist or alter frame selection state across calls. However, it does not describe behavior when no element is found or timeout handling; the output schema may cover return values, but the description itself adds limited 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action and resource: 'Find an element inside a selected iframe/frame without global frame state.' It contains no filler words, is immediately scannable, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations and output schema cover safety and return values, the description is too terse to fully specify correct usage. The critical gap is how to select the frame (frame_index vs frame_selector, precedence, nesting context). The description does not mention the need to provide a frame selector or index, nor the relationship to sibling tools like frame_list. For a tool with 4 parameters and low schema coverage, this is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low (25%), with only 'selector' having a description in the schema. The tool description does not explain how frame_index and frame_selector work, whether they are alternatives or should both be provided, or which takes precedence. The phrase 'selected iframe/frame' hints at frame selection but gives no parameter-level detail, leaving the agent to guess from names and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds an element inside a selected iframe/frame, with a specific verb ('find') and resource ('element in frame'). The phrase 'without global frame state' distinguishes it from sibling tools that might manipulate global frame context, such as frame_snapshot or element_find in a global context. The title and name align perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to find an element within a frame without altering the global frame context. However, it does not explicitly mention when to use it versus alternatives like element_find (for current context) or frame_snapshot (for listing frames). No exclusions or alternative tool names are provided, so usage guidance is only 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'without changing global state', which reinforces these traits but does not provide new behavioral details beyond what annotations convey. For example, it does not mention concurrency behavior or pagination, so minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that immediately conveys the tool's action and side-effect. Every word serves a purpose, and there is no extraneous information. The structure is front-loaded for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and an output schema (not shown but exists), the description covers the essential behavior. However, it omits details about the return format or which frame attributes are included, though the output schema likely documents these. Slightly more context on the data returned would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the limit parameter has no description in the schema. The tool description does not compensate by explaining the parameter's meaning or effect on output. The limit is intuitive but still leaves ambiguity about default behavior and impact on results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool 'list iframe/frame contexts on the current page', specifying a precise verb and resource. It also adds scope ('without changing global state'), distinguishing it from sibling tools like frame_find or frame_snapshot. This provides clear purpose and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing frames and notes it does not change state, but it does not explicitly guide when to use this tool versus alternatives like frame_find or frame_snapshot. There are no stated exclusions or when-not-to-use scenarios, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds no additional behavioral context beyond the annotations, so it is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (not shown), the description does not elaborate on behavior like error handling or page state changes. It is minimally complete for a simple navigation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning to parameters. The baseline of 3 is appropriate as the description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'navigate' and the resource 'URL', making it distinct from siblings like page_go_back and page_refresh. It directly 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., page_go_back or page_go_forward). The description lacks context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, signaling the tool's destructive nature. The description adds no further behavioral traits (e.g., loss of form state, reloading resources). With annotations bearing the burden, a score of 3 is appropriate for not augmenting beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 4 words, front-loading all critical information. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with an output schema, the description is complete enough. It states the essential action. While it could mention side effects, the destructiveHint annotation covers that context, making further detail unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and input schema coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4; the description does not add parameter detail but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Refresh the current page' clearly states the verb (Refresh) and resource (the current page). It is specific and unambiguous, but does not explicitly distinguish from sibling tools like page_navigate or page_go_forward, though the action is inherently different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., page_navigate for loading a new URL, page_go_back for history navigation). The description lacks context for proper decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that the tool is destructive and not read-only. The description adds the context that the destination is under a specific root directory, but does not elaborate on what happens if the file already exists, or any side effects. It is adequate but could provide more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words or repetition. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and existence of an output schema, the description is minimally adequate. However, it lacks context about prerequisites (e.g., requiring a prior screenshot capture) and does not explain the return value or behavior on duplicate paths. It covers the core function but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions; it only restates the root directory constraint that is already in the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save), the resource (screenshot), and the destination (local path under DP_MCP_SCREENSHOT_ROOT). It distinguishes the tool from the sibling 'page_screenshot', which likely captures but does not save to a local path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., page_screenshot). It does not mention prerequisites, such as needing to first capture a screenshot, or any context about file conflicts. Annotations indicate destructive behavior, but no explicit usage direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior and non-read-only. Description adds minor context: it closes a single tab without closing the whole browser. However, it lacks details about side effects (e.g., unsaved data), error cases, or behavior when closing the last tab.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, straightforward, front-loaded with action and key constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with full schema coverage and an output schema, the description is adequate but lacks any guidance on usage context or error conditions. The brief description covers the core action but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema's own parameter description, which already explains the tab_id format. No additional semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific action (close) on a specific resource (browser tab) using a specific method (by id from tab_list). Distinguishes from closing the whole browser, which sets it apart from sibling tools like 'page_close'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like page_close or page_navigate. No mention of prerequisites (e.g., tab must exist in tab_list) or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations (destructiveHint=true): it specifically mentions arming Chromium's file chooser, injecting approved files, always removing interception, and avoiding a native OS picker. This gives the agent a clear picture of side effects and behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence conveys the complete action sequence with no filler. The action verb 'Arm' is front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations available, the description covers the core workflow but omits usage context, edge cases, and parameter details. It is adequate for a basic understanding but not fully complete for an agent to execute reliably without further schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'selector' has a description). The tool description mentions 'approved files' hinting at 'paths' but provides no detail on path format, timeout semantics, or how the selector target types work. It does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it arms the file chooser, clicks a trigger, injects approved files, and removes interception. This specific verb-resource pairing distinguishes it from sibling tools like element_click (just clicks) and element_upload_file (likely uploads without clicking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as element_upload_file or element_click_and_download. The description only describes mechanics, not the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context, such as what happens when the attribute is missing or whether it returns the first matching element. With annotations covering the safety profile, this is acceptable but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of rich annotations, an output schema, and a fully described input schema, the description is sufficient. It lacks minor nuances like behavior on missing attributes, but these are not essential for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter information beyond what the schema already provides for 'selector' and 'attribute'. The schema fully documents both parameters, so no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get an attribute value from an element', which is a specific verb+resource pair. It is distinct from sibling tools like element_get_text, element_get_property, and element_get_html, which retrieve different data from an element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or comparisons to sibling tools like element_get_text, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'whole page' scope, which is useful behavioral context. However, it does not disclose nuances like whether text is innerText or textContent, or waiting behavior. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence, front-loaded with the action, and contains no filler. It is appropriately concise for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema availability, and safety annotations, the description is sufficient. It clearly states the tool's purpose and scope. However, it does not mention the ability to target shadow DOM/frames or accessibility targets, which are documented in the schema but not in the description. This minor gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the selector parameter fully documented (CSS/XPath, empty means whole page, text: prefix). The description adds no parameter-level information beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'text' and scope 'element or whole page', clearly distinguishing it from sibling getters like element_get_attribute, element_get_property, and element_get_html. The scope is explicit, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like element_get_html or element_get_attribute. It simply states the function without mentioning exclusions, prerequisites, or alternative tools, leaving the agent to infer usage from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=true. The description adds beta status and clarifies observation-only behavior (no interception or modification). It lacks details on side effects or how starting a listener affects existing queue, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and behavior. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameters are fully described, output schema exists, and the fundamental action is clear. Minor gaps: no mention of prerequisites or typical workflow (e.g., use with network_listen_wait), but overall sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter definitions. The description adds no extra meaning beyond the schema, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'start', the resource 'HTTP/XHR/Fetch network observation', and scope 'for the active tab'. It also distinguishes itself by noting it only observes packets and does not intercept or modify requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as network_listen_wait or network_listen_stop. The description implies use for monitoring network packets but fails to state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint false) and destructiveness (destructiveHint true). The description adds useful context: it writes into a specific root (DP_MCP_ARTIFACT_ROOT), returns a checksum and safe relative path (implying path safety), and promises exact-once receipt evidence, which is a meaningful behavioral guarantee beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently captures the core action and key outputs without wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema may cover return values, the tool has 14 parameters and the description omits any context about parameter interactions, prerequisites, or use cases. It provides a minimal viable description but does not fully cover the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should compensate for the 14 parameters, but it only mentions 'PDF or MHTML' which maps to the format parameter. It does not explain scale, margins, page_ranges, paper dimensions, operation_key, or other options, leaving the agent without semantic guidance for most fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate one PDF or MHTML file under DP_MCP_ARTIFACT_ROOT' and specifies the return outputs (checksum, safe relative path, exact-once receipt evidence). This distinguishes it from sibling tools like page_screenshot or page_snapshot by focusing on durable artifact creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as page_screenshot_save or page_snapshot. The description does not mention scenarios, exclusions, or relationships to other export/save tools, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'inline' but does not explain what that means (e.g., returns base64). With annotations, the bar is lower; description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one optional param, output schema present), the description is mostly complete. It could mention return format but is not required as output schema likely covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 is appropriate. Description does not add meaning beyond the schema; the parameter 'full_page' is already described in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Take an inline screenshot of the current page' – a specific verb and resource. The word 'inline' distinguishes it from the sibling 'page_screenshot_save', which likely saves to a file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'page_screenshot_save'. No when-not or exclusions are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=false and destructiveHint=true, indicating a state-changing operation. The description adds no additional behavioral context such as side effects on the previously active tab, session state, or prerequisites, so it provides little beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the verb and object front-loaded. Every word contributes to the core action and id source; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and the presence of an output schema, this description is adequate. It names the action, resource, and id source; the only minor gap is not explicitly stating that tab_list should be called first to obtain a valid id, but that is already implied by the schema description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents tab_id (100% coverage) as either an MCP tab id from tab_list or a DrissionPage native id. The description's 'by id from tab_list' only echoes this existing schema detail without adding new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Switch') applied to a specific resource ('the active browser tab'), and it identifies the id source ('from tab_list'). This clearly distinguishes it from sibling tools like tab_close and tab_list, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the agent has a tab_id from tab_list and wants to change the active tab. However, it does not explicitly state when to use it versus alternatives, nor does it provide exclusions (e.g., 'use tab_close to close a tab').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is non-read-only and destructive (readOnlyHint=false, destructiveHint=true), so the agent knows it may mutate state. The description adds no further behavioral context, such as whether the click may trigger navigation, wait for page changes, or return an observe summary. It does not contradict the annotations, but it also does not enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and selector scope. Every word earns its place; no filler or redundant elaboration. Ideal length for a tool that is well-documented by its schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema and annotations, the description is passable but not comprehensive. It omits differentiation from closely related siblings like element_click_and_download or element_hover, and does not mention the observe option or accessibility/scope features. The schema fills many gaps, but the description alone would not fully prepare an agent for all usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for each parameter (button, observe, timeout, selector, click_count). The tool description adds minimal new information, mostly repeating the schema's selector guidance. It does not explain the union type for selector or the accessibility option, but the schema already covers these. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Click an element') and identifies the resource by selector type ('CSS selector or XPath'). It distinguishes this from sibling tools like element_hover (hovering) and page_click_xy (clicking at coordinates) through the explicit click verb and selector scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance on selector formats ('Bare selectors are treated as CSS; use text:... for text matching'), which helps invocation. However, it does not explicitly state when to prefer this tool over alternatives such as element_hover or element_click_and_download, nor does it mention any exclusions. Usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds context about awaiting download completion and returning a receipt, but it does not clarify what makes the action destructive or what side effects occur (e.g., file saving location, overwrite behavior). This is acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core action and result. It is front-loaded with the verb 'Perform' and wastes no words, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and includes an output schema, so return values are covered. However, the description omits the 'accessibility' trigger type (AccessibilityTargetInput) from its list of 'selector, coordinate, or keyboard trigger,' and does not mention optional constraints like expected_filename or operation_key. This is a noticeable gap for a tool with multiple input variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters like timeout, selector, operation_key, expected_filename, and expected_mime_type are already well-documented. The tool description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: perform a trigger (selector, coordinate, or keyboard), await a download, and return an integrity-checked receipt. This distinguishes it from siblings like element_click (just clicks) and element_click_and_upload (handles uploads), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for triggering and completing a download, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. The unique behavior is implied by 'await one completed download' but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint=true and readOnlyHint=false. The description adds 'This can mutate the page,' reinforcing the destructive nature, and 'bounded,' which hints at execution limits but does not specify them. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and result, and contains no filler. It efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary JavaScript, the description covers the main action and output format, but lacks important context such as error behavior, timeout specifics, or broader side-effect implications beyond mutation. An output schema exists, but given the high-risk nature, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema (script as a function body, args as JSON arguments, max_chars as a limit). The description itself adds no additional parameter details, so the schema carries the full semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: running a bounded JavaScript function body in the current page and returning a JSON-safe result. This distinguishes it from all sibling tools, as no other tool offers JavaScript execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to run JavaScript on the page, but provides no explicit guidance on when to choose it over dedicated interaction tools or when not to use it. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds the DrissionPage runtime context but does not mention behavioral details such as limit handling, return shape, or potential errors. With annotations present, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant information. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and has an output schema plus annotations, so a one-sentence description is minimally viable. However, it does not clarify the distinction from shadow_find or elaborate on how limit and include_html affect behavior, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for required params host_selector and selector, and the remaining params (limit, include_html) are self-explanatory by name. The description itself adds no parameter-level meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (find), the target (repeated elements inside a shadow root), and the runtime (DrissionPage). This distinguishes it from sibling tools like shadow_find (singular) and element_find_all (non-shadow).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all matching elements within a shadow root but does not explicitly state when to use it versus alternatives like shadow_find. No direct comparison or exclusions are provided, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description matches the destructive hint annotation and clarifies the storage types (local/session). However, it does not add significant behavioral context beyond the annotation, such as irreversibility or cross-tab effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. Every word contributes to clarity without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers the primary behavior (clear one key or all) and storage context. No additional details are necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context that key is optional and that clearing can be for local or session storage, but the schema already covers the key parameter's behavior. The area parameter is self-explanatory via its enum, so the description adds minimal extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool clears one key or all items from localStorage/sessionStorage, with a specific verb and resource. It effectively distinguishes from sibling tools like storage_get and storage_set by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., storage_set with empty value) or when not to use it. The context of siblings is broad but not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the mutating nature is known. The description adds that the value is not echoed, which is useful for privacy. However, it does not disclose whether existing keys are overwritten or other behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences that efficiently convey the core action and a key behavioral note. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the essential purpose and a notable behavior (no echo). With an output schema present, return values need not be explained. However, it could mention that setting an existing key overwrites it, adding slightly more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), with only the 'value' parameter having a description. The tool description does not add meaning beyond what is already in the schema, merely restating that the value is not echoed. It fails to compensate for the under-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'localStorage/sessionStorage item', distinguishing it from sibling tools like storage_get and storage_clear. It uses specific verbs and resource names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for storing a value but does not provide explicit guidance on when to use this tool versus alternatives such as storage_get or storage_clear. No exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds the behavioral scope of what can be waited on, which is context beyond annotations, but doesn't mention timeout or polling behavior (though schema provides timeout/interval).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that lists capabilities in a compact, scannable way. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 condition types, nested selector structures), the description covers only a subset of conditions, omitting attribute/property waits. While an output schema exists, the functional coverage is incomplete, so the description does not fully convey the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the 7 parameters has a description in the schema. The tool description provides a high-level overview of condition categories but adds no specific parameter semantics beyond what the schema already documents, yielding a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb and resource ('Wait for observable page state') and enumerates many condition categories (element states, text, URL). However, it omits attribute and property conditions that exist in the schema (attribute_equals, property_equals, etc.), making the description still mostly clear but not fully comprehensive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus the specialized wait_for_element, wait_for_url, or wait_time sibling tools. The broad scope implies it's the general waiting utility, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=true). The description adds useful context about the tool's scoping ('one bounded origin' and 'current Chromium context'), but does not disclose any additional behavioral details such as side effects, persistence, or authorization requirements. The annotations and description are consistent with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and scope. It contains no filler or redundant information, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (3 parameters, 2 enums, and existing output schema), the description covers the essential aspects: what it does, the allowed setting values, and scope. It lacks explicit alternative guidance and side-effect disclosure, but the annotations and schema fill those gaps, making it sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has low description coverage (33%) with only the 'origin' parameter described. The tool description helps by explicitly stating the allowed setting values ('granted, denied, or prompt') and clarifying the origin scope ('one bounded origin'), but it does not enumerate the permission options or add syntax/format details beyond what the schema enums provide. It partially compensates for the schema gaps but leaves some semantic burden on the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set one permission to granted, denied, or prompt for one bounded origin in the current Chromium context.' This is a specific verb (Set) with a specific resource (permission) and scope (one bounded origin), distinguishing it from sibling tools like browser_permission_get and browser_permissions_reset which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly explain when to use it versus alternatives such as browser_permission_get or browser_permissions_reset. There is no mention of prerequisites, exclusions, or comparison to other tools, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds no additional behavioral context, such as whether toggling fires events, requires a loaded page, or has side effects. It neither contradicts the annotations nor enriches them with useful extra detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-setting tool, the description is adequate, especially with annotations and an output schema present. However, it does not mention prerequisites like needing a page loaded or whether the element must be visible, but given the simplicity, this is a minor gap. The description leaves room for implied assumptions about context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (moderate), and the description contributes no parameter semantics beyond what the schema already provides. The schema clearly describes 'by_js' and 'checked,' while 'selector' and 'timeout' are mostly self-explanatory. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set a checkbox or radio element to checked/unchecked.' This is a specific verb ('Set') + resource ('checkbox or radio element') + action ('checked/unchecked'), which distinguishes it from sibling tools like element_click (clicks) or element_select (selects options).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to change the checked state of a checkbox or radio. However, it provides no explicit exclusions or alternatives, such as 'prefer this over element_click for checkboxes.' There is no guidance on when not to use it or how it compares to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the context of 'live' (reading current state) and an example, but does not provide deeper behavioral details such as error handling, timing, or interaction with shadow DOM/frames beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. It is front-loaded with the action and resource, contains no extraneous words, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with rich annotations and a fully described parameter schema. The output schema exists, so return values need not be described. The description is sufficient for basic use, but slight gaps remain regarding when to prefer this over similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters: 'property' and 'selector' (including selector syntax details). The description does not add additional parameter semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('live DOM property value from an element'), with a concrete example ('such as an input's current value'). It distinguishes itself from sibling tools like element_get_attribute by using 'property' rather than 'attribute', and from element_get_text/element_get_html by specifying 'DOM property value'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading live properties, but it does not explicitly state when to use this tool versus alternatives like element_get_attribute or element_get_text. There is no mention of exclusions or alternative tool names, so guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which convey the safety profile. The description adds no behavioral details beyond stating it gets the current URL, but it is consistent with the annotations and does not introduce contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, read-only, output schema present), the description is mostly sufficient. It could optionally mention that the URL is returned as a string, but the output schema likely covers this, so the missing detail is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the baseline for 0-param tools, the description is not required to explain parameters, and it adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('the current URL of the page'). It distinguishes this from sibling navigation tools by implying a read-only action that returns the URL rather than altering it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the purpose is self-evident, there is no explicit context, exclusions, or mention of sibling tools that could be used to retrieve the same information (e.g., page_evaluate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is destructive and not read-only, which aligns with scrolling. The description adds no further behavioral context, such as side effects like triggering lazy loading, but it is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core functionality without unnecessary words. It is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema and comprehensive parameter descriptions in the schema, the description adequately completes the context. It could mention default behavior or scope (main page vs iframes), but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description does not add additional meaning beyond what the schema provides, maintaining the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls the current page by direction or to a position, specifying the verb and resource. It distinguishes from sibling tools like element_scroll_into_view which targets elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scrolling but does not provide explicit guidance on when to use this tool vs alternatives like page_go_forward/back or element_scroll_into_view. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the session scoping ('tracked by the current DrissionPage MCP session'), which is useful but not extensive. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, with no redundant information. It efficiently conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, full annotation coverage, output schema present), the description is adequately complete. It specifies the scope (current session), which is the main contextual detail needed beyond structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. With baseline set at 4 for 0 params, the description does not need to add parameter details. The output schema exists, so the description does not need to explain return values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: listing browser tabs. It uses the specific verb 'List' and resource 'browser tabs', with scope defined as the current DrissionPage MCP session. This distinguishes it from sibling tools like page_navigate or tab_close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention whether it should be used before closing tabs or navigating. Given the set of sibling tools, explicit usage context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds selector interpretation context (bare CSS vs text:) but does not disclose timeout error behavior or return semantics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and the most important selector nuance. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich schema (including selector object variants) and output schema present, the description is adequate for basic usage. However, it lacks explicit differentiation from other wait tools (wait_until, wait_time), which would improve completeness in tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for timeout and selector, including bare CSS and text: prefixes. The tool description essentially repeats selector guidance from the schema, adding no new parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for an element to appear on the page, using a specific verb and resource. It distinguishes itself from sibling wait tools like wait_time and wait_for_url by focusing on element presence, and adds selector syntax details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (wait for element appearance) and provides selector format guidance, but gives no explicit when-to-use vs alternatives like wait_until or wait_time. Sibling tools are visible but not referenced, so the agent must infer the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false; the description remains consistent but adds no extra behavioral detail such as serialization or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema, output schema, and safe annotations, the brief description is sufficient for an agent to understand the tool's scope and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully described (100% coverage), including selector semantics and target construction, so the description adds minimal parameter information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Get HTML') and the resource scope ('from an element or the whole page'), distinguishing it from sibling text/attribute retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope ('element or whole page') gives some usage context, but there is no explicit guidance on when to prefer this over element_get_text, page_snapshot, or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the mutation risk is known. The description adds the selection mechanism (by value/text/index) but does not disclose additional behavioral details such as timeout handling or side effects like triggering change events. This meets the baseline but adds limited context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 13 words, immediately front-loading the core purpose and method. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the output schema exists, so return values need not be explained. However, the description leaves ambiguities such as whether indices are 0-based or 1-based, and whether multi-select elements are supported. These details are also not in the schema, making the description marginally adequate for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with descriptions for 'by', 'value', and 'selector'. The description's phrasing 'by value, text, or index' is nearly identical to the schema's 'by' description, adding no new meaning. The 'timeout' parameter lacks a description and the tool description does not clarify its behavior, so the description does not compensate for that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Select'), a clear resource ('option from a select element'), and specifies the method ('by value, text, or index'). It clearly distinguishes this tool from siblings like element_click or element_type, which serve different interaction purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the intended context: selecting an option within a select element. It does not explicitly mention alternatives or exclusions, but the specificity of 'select element' provides unambiguous guidance for when to use this tool over other element interaction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint=true and readOnlyHint=false, so the description adds little beyond confirming the action. It does specify 'active browser context' as scope, but no additional behavioral traits like irreversibility or side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It contains exactly the necessary information for a simple parameterless destructive action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema indicating return-value documentation is not needed. The description fully conveys the action and scope. It could add a note on irreversibility, but annotations already flag destructive behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the base score for parameter-less tools is 4. The description adds no parameter details, but none are needed, and the schema confirms no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clear') and resource ('all cookies') with explicit scope ('active browser context'). It clearly distinguishes from sibling tool browser_cookies_delete by specifying 'all cookies' rather than a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Clear all cookies' implies this is for a full cookie reset, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives like browser_cookies_delete for targeted removal. The usage context is only lightly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds the scoping context ('with optional URL/domain/path scope'), which clarifies the parameter space. It does not contradict annotations and provides enough behavioral clarity for a simple delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and then specifies optional parameters. Every word is necessary, and it is not padded with redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 4 parameters and an output schema. The description, combined with annotations (destructive, idempotent, openWorld), provides sufficient context for an agent to understand the operation. It could mention the risk of deleting cookies with the same name across scopes, but the openWorldHint annotation partially covers this, so the description remains adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameter meaning. It states that name identifies the cookie and url/domain/path are optional scope, but it does not explain how these scope parameters interact or what happens when omitted. This adds some value but is not comprehensive, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a clear resource ('one named browser cookie'), and distinguishes it from the sibling browser_cookies_clear by specifying 'one named' rather than all cookies. The optional scope parameters are also mentioned, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case for deleting a single cookie, but it does not explicitly state when to use it versus alternatives like browser_cookies_clear or how to choose between url/domain/path. There is no explicit exclusion or alternative guidance, so it earns a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is destructive (destructiveHint: true) and not idempotent, so the description's addition of 'before a later action' is useful context but not rich behavioral detail. It does not contradict annotations, and no additional side effects or failure modes are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without redundancy. Every word earns its place, and it is front-loaded with the key verb 'Scroll'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the existence of an output schema, and detailed input schema, the description is sufficient for basic understanding. It could include more on edge cases or failure behavior, but for a simple scroll action, the current description plus schema covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'center' and 'selector' parameters, and schema coverage is 67% (2 of 3 parameters). The tool description adds no parameter-specific guidance, but the schema carries most of the load, leaving only 'timeout' underdocumented. This is adequate but not enhanced by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Scroll an element into the viewport before a later action.' This uses a specific verb ('scroll'), resource ('element'), and scope ('into the viewport'), making it distinct from sibling tools like page_scroll or element_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before a later action' provides clear context for when to use this tool: as a preparatory step before interacting with an element. It does not explicitly mention alternatives or exclusions, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructive, non-read-only), the description adds security constraints (paths under a root) and a response behavior (only safe file names returned). This is meaningful context beyond what annotations alone reveal. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action and no fluff. Each sentence earns its place: the first states the operation, the second adds essential constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema (which documents all parameters), annotations (destructive), and presence of an output schema, the description is sufficient. It includes the key security constraint and response behavior. A minor gap is not clarifying when to prefer this over element_click_and_upload, but for a file-input tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the paths parameter as under DP_MCP_UPLOAD_ROOT with absolute paths not echoed. The description's mention of that constraint is redundant. Other parameters (timeout, selector) are fully covered by the schema, so the description adds minimal parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and a resource type ('input[type=file]'), making the tool's purpose immediately clear. It strongly differentiates from siblings like element_type (text input) and element_click_and_upload (click-triggered upload).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating files must be under DP_MCP_UPLOAD_ROOT, but it does not explicitly say when to use this tool versus alternatives such as element_click_and_upload. No exclusions or alternative tool names are given, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds 'one pending' and 'capability-probed' but does not disclose side effects such as page state after dismissal or behavior when no dialog is pending. The added context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no filler or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of annotations and an output schema, the description covers the core function adequately. However, the phrase 'capability-probed native DrissionPage dialog path' is vague and could be replaced with clearer prerequisites or behavior details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with timeout and prompt_text already documented. The description does not add meaningful parameter semantics; it only maps the action to accept/dismiss and names the dialog types, which is slight but not substantial over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb combination 'Accept or dismiss' and clearly identifies the resource as 'one pending alert, confirm, or prompt.' This distinguishes it from sibling tools like page_dialog_observe and other page manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: it is used to respond to pending dialogs. However, it does not explicitly mention alternatives (e.g., page_dialog_observe for observation only) or exclusions like when no dialog is pending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a 'compact fingerprint' including a console summary, which gives some behavioral context, but there are no details about side effects, permissions, or rate limits. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('compact current-page fingerprint') and then lists the included elements. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameter schema is self-documenting, the description is sufficient for a simple read-only tool. It provides a clear picture of what is returned, and the sibling context helps distinguish it. It lacks explicit 'when to use' guidance but that is not critical for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full descriptions for both parameters (max_texts, max_text_chars) with defaults and ranges. The description does not add any parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact current-page fingerprint with a specific list of contents (URL, title, ready state, element counts, visible text samples, active element, recent console summary). The verb 'Return' is specific and the resource is well-defined, distinguishing it from sibling tools like page_snapshot or page_console_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a quick overview of the current page state, and the term 'compact fingerprint' contrasts with fuller snapshots. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the substring-matching behavior but does not elaborate on timeout failure modes or polling mechanics, which is acceptable given annotations cover the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words, immediately states the action and condition. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wait tool, the description combined with the input schema and output schema is sufficient. It doesn't explain what happens on timeout, but the timeout parameter with default and max makes it understandable. Slight gap: no explicit statement of return behavior, but output schema likely covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both url_pattern and timeout. The description restates the substring concept but adds no new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'wait' with a resource 'current URL' and a condition 'contain a substring', clearly distinguishing it from sibling wait tools like wait_for_element or wait_time. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for waiting until the URL matches a substring, but does not explicitly mention alternatives or when-not to use. However, the context is clear enough that an agent would know to use this when a URL condition is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, establishing safety. The description adds valuable behavioral context: cookies are normalized and values are redacted by default, which is critical for privacy. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core action and key nuance (redaction). There is no extraneous information, and it is front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three boolean parameters, and the description covers the main behavioral nuance (redaction). An output schema exists to detail return values. While 'normalized' is not elaborated, the combination of annotations, schema, and description provides sufficient context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the 'include_values' parameter has a schema description; the description mentions redaction, which relates to this parameter. However, 'all_info' and 'all_domains' have no explanation in either the schema or description, leaving their semantics unclear. With 33% schema coverage, the description does not adequately compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads cookies, specifies they are normalized, and notes that values are redacted by default. The verb 'read' and resource 'cookies' are explicit, and there are no sibling tools with similar functionality, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading cookies without explicit when/when-not guidance. However, since no sibling tools compete for this function, the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint, idempotentHint, and openWorldHint. The description adds valuable context about success behavior ('echo header values for MCP callbacks') and the clearing mechanism ('empty object clears them'), which goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with two sentences that state purpose, scope, and key behaviors. Every word earns its place; there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with a rich schema, available output schema, and annotations indicating destructive/idempotent behavior, the description sufficiently covers the behavioral essentials. It explains how to clear headers and what to expect on success, making it complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the 'headers' parameter, including a description that matches the tool's mention of 'empty object clears'. The tool description adds no new parameter-specific meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace'), the resource ('extra HTTP request headers'), and the scope ('for the current tab'). This distinguishes it from sibling tools like browser_user_agent_set or browser_cookies_set, which handle different request aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting headers on the current tab, but it does not explicitly mention alternatives or exclusions. There is no when-not-to-use guidance relative to sibling tools, so context is clear but not thoroughly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the 'bounded' qualifier, indicating output limits (e.g., max_elements, max_text_chars), which is not present in annotations. It also implies frame selection is required, adding context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the action ('Return') and scope. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description adequately covers the core behavior. It could further clarify what 'page outline' means or how to select a frame, but the schema handles those details. It is complete enough for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate by explaining parameters like timeout, include_html, max_elements, or max_text_chars. The term 'bounded' hints at limits but does not clarify individual parameter semantics. Parameters are largely self-explanatory from names/defaults, but the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'bounded page outline' from a selected iframe/frame, using a specific verb ('Return') and resource. It distinguishes itself from siblings like page_snapshot (whole page) and frame_list/frame_find (frame enumeration) by focusing on frames and boundedness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when you need a snapshot of a specific iframe/frame, not the entire page. However, it does not explicitly mention alternatives or exclusions, so agents must infer from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint=false) already establish the safety profile. The description adds valuable context by highlighting the 'bounded' nature (controlled by max_elements and max_text_chars) and enumerating the output components, going beyond the bare annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and output scope without any filler. Every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the presence of a rich output schema, and complete annotations, the description fully covers the necessary context. It communicates the key output categories and bounded nature, making it self-sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema already fully documents them. The description adds no additional parameter-specific detail; it focuses on the output rather than parameter behavior, which is acceptable but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Return') and a clear resource ('bounded page outline'), enumerating distinct content types (text excerpt, headings, links, buttons, inputs, forms, recommended selectors). This clearly differentiates it from sibling tools like page_accessibility_snapshot or page_observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a summarized page overview but does not explicitly state when to use it instead of alternatives, nor does it mention exclusions or preconditions. It lacks the explicit alternative guidance seen in the calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (previous user agent) and the restore pattern, which adds beyond the annotations. This is consistent with destructiveHint=true and readOnlyHint=false, and no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and includes both the behavior and return value. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the action, scope (current tab), and return behavior. It is complete enough for the complexity, though it does not discuss edge cases or error conditions, which are not essential here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'user agent' and 'optional platform', clarifying platform's optionality but provides no format or usage details beyond the schema's basic type constraints. This is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Override') and identifies the exact resource ('current tab user agent and optional platform'), distinguishing it clearly from sibling header/cookie/storage tools. It also mentions returning the previous user agent, which adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by scoping to the current tab, making the use case obvious. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds beyond annotations by noting that bodies and headers are opt-in and sensitive headers are redacted, providing useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core action and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and all parameters are described, the description adequately explains what the tool returns and its options. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about opt-in bodies and header redaction, adding meaning beyond the schema. Score 4 for added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for HTTP/XHR/Fetch packets and returns bounded metadata, with specifics about opt-in bodies/headers and redaction. It distinguishes from sibling tools like network_listen_start and network_listen_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage after starting a listener but provides no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces non-destructive behavior by stating 'without handling it'. It also adds context about the specific dialog types (alert, confirm, prompt) and the 'bounded message' return, which clarifies the tool's behavior beyond the annotations. It does not describe behavior when no dialog is pending, but the timeout parameter partially covers this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence, front-loaded with the action and purpose. Every word contributes value; there is no redundancy or filler, fitting the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple observation tool, the description, combined with the comprehensive schema and annotations, is largely complete. It clearly conveys the tool's function and non-destructive nature. The behavior when no dialog appears is implied via the timeout and schema, though not explicitly stated in the description, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds minimal value beyond the schema, only tying 'bounded message' to the max_message_chars concept. No parameter details are missing, but the description also does not enrich understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Observe a pending native alert, confirm, or prompt') and its scope ('return its bounded message without handling it'). This distinguishes it from sibling tools like page_dialog_respond, which handles the dialog, and page_observe, which observes page state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 tool: when a native dialog is pending and only observation is desired, explicitly stating it does not handle the dialog. It does not name alternative tools or provide when-not conditions, but the 'without handling it' implies a contrast with page_dialog_respond, giving adequate guidance without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description confirms the action is destructive (consistent with annotations), but adds little beyond the title. Behavioral details like potential loss of forward history are implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema (not requiring explanation), the description is sufficient. Could mention return value briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Baseline score of 4 applies as description doesn't need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go back to the previous page in browser history' uses a specific verb and resource, clearly distinguishing it from sibling tools like page_go_forward or page_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is obvious from context, but no explicit when-to-use or alternatives are provided. The description could mention not to use if already at the first page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral guarantees beyond annotations: 'Always releases the button' and 'failure-safe' disclose important safety behavior not found in the readOnly/destructive hints. However, it does not detail what 'failure-safe' entails or the exact side effects of the drag (though destructiveHint is true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every phrase earns its place (failure-safe, waypoints, movement profiles, button release). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for an agent to select and invoke the tool correctly given the rich schema and output schema. It covers the primary behavior, optional waypoints, movement profiles, and the button-release guarantee. It does not explain failure-safe semantics, but the schema and context cover most operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description reinforces the meaning of waypoints and profile but does not add substantial new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform one failure-safe viewport drag'), the scope (through optional ordered waypoints), and the method (direct or bounded natural movement while the button remains pressed). It distinguishes this from coordinate-based moves and element-based drags by emphasizing waypoints and the button-pressed state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: for viewport coordinate drags with waypoints and movement profiles. It implies it is for coordinate-based interactions rather than element-based ones (e.g., page_pointer_drag_element), but it does not explicitly name 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context that the shadow root must be 'exposed by the supported DrissionPage runtime', indicating a dependency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant words. It is front-loaded with the core action and resource, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with annotations and an output schema, the description adequately explains the core purpose. It does not cover failure modes or return behavior, but the output schema handles return values, and the annotations cover safety, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% with host_selector and selector described, but timeout lacks a description. The tool description does not add any parameter-specific meaning beyond the schema, so it provides minimal extra value for understanding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find' and identifies the resource as 'one element inside a shadow root'. It distinguishes itself from sibling tool 'shadow_find_all' by the word 'one' and mentions the DrissionPage runtime context, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for locating a single element within an exposed shadow root, which implies it is the singular variant of shadow_find_all. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds behavioral nuance by clarifying that the query does not trigger a system prompt, and it scopes the operation to the current document origin. This goes beyond the annotations and provides useful context for the agent, though it could mention other traits like returned states or secure-context requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action verb and quickly covers the key details: resource, scope, and behavioral trait. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description together with annotations (readOnly, idempotent) and the presence of an output schema fully covers the necessary context. It states what the tool does, its scope, and that it avoids prompting, which is sufficient for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, and the description only says 'one browser permission state' which maps to the single 'permission' parameter. The enum values in the schema already enumerate possible permissions, so the description adds minimal meaning. Since the parameter is straightforward and the tool is simple, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query'), the resource ('browser permission state'), and the scope ('for the current document origin'). It also differentiates from sibling tools like browser_permission_set by noting that it operates 'without opening an operating-system prompt,' making its purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: to query the permission state for the current origin. The phrase 'without opening a prompt' implies it is for non-intrusive checks, complementing browser_permission_set. However, it does not explicitly name alternatives or exclusion conditions, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description adds valuable context by specifying 'all' overrides and 'current browser context', clarifying the full scope of the destructive action beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It front-loads the verb and conveys all necessary information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with clear annotations (destructive, idempotent) and an output schema, the description fully covers the tool's purpose and scope. No additional explanation of return values or side effects is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain them. The empty input schema is fully self-descriptive, and the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reset'), the resource ('all Chromium permission overrides'), and the scope ('current browser context'). This distinguishes it from sibling tools like browser_permission_set or browser_permission_get, which target individual permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to clear all permission overrides) but doesn't explicitly state when to use this over alternatives, nor does it mention any exclusions or prerequisites. It's adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds non-redundant behavioral details: outputs are 'bounded text/attribute summaries' and it returns 'recommended selectors', disclosing truncation behavior and an extra output feature. This adds meaningful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the core action. Every phrase earns its place: 'multiple matching elements', 'bounded text/attribute summaries', 'recommended selectors', and the use-case list. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (3 params, 100% coverage), the presence of an output schema, and thorough annotations, the description is complete enough for an agent to correctly select and invoke the tool. It clearly communicates the tool's purpose and distinctive output characteristics, leaving only a minor gap in explicitly contrasting with element_find, which is already implied by 'multiple'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, documenting selector, limit, and include_html. The description's mention of 'bounded text/attribute summaries' loosely relates to include_html but does not add direct parameter semantics. This is the baseline 3, as the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find multiple matching elements', a specific verb + plural resource, and distinguishes itself from sibling element_find by targeting 'repeated lists, cards, and tables'. It also previews the bounded summaries and recommended selectors, making the tool's purpose and scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for repeated lists, cards, and tables' provides clear context on when this tool is appropriate, which is a helpful usage guideline. However, it does not explicitly mention alternatives like element_find for single elements or state any exclusions, so it does not reach the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it is a replace operation, successful results echo the input patterns, and an empty list clears the blocked URLs. These details help the agent understand the operational semantics, while annotations already signal destructiveness and idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the action, scope, and key behavioral details without any wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), detailed schema descriptions, and the presence of an output schema, the description covers all essential aspects: purpose, scope, clearing behavior, and result echo. There is no apparent gap that would cause an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single 'urls' parameter, including wildcards and empty-list clearing. The description does not add new parameter-level information; it only reinforces the empty-list behavior, which is already present in the schema. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace') and the specific resource ('URL patterns blocked for the current tab'). This distinguishes it from sibling tools like network_listen_start/stop or browser_cookies_set, which have different purposes. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it operates on the current tab and indicates the empty-list clearing behavior. However, it does not explicitly mention alternatives or exclusions, though these are implied by the replace action and the tool's specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context ('bounded', details on filtering/pagination) beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, densely informative, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with comprehensive annotations and a full input schema, the description adequately explains the tool's functionality and parameter capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description mentions the same features, but does not add significant new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'bounded browser console messages from the current tab', which distinguishes it from siblings like page_evaluate or page_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool via the mention of 'level filtering, cursor pagination, and a maximum result limit', but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral detail beyond the annotations, which already declare destructiveHint=true. It correctly states the action but does not elaborate on side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description fully captures the behavior. An output schema exists, so return value information is not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description is not required to explain parameters, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Go forward') and resource ('next page in browser history'), clearly distinguishing it from siblings like 'page_go_back' and 'page_navigate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states when to use (to go forward in history), but does not explicitly exclude scenarios or mention alternatives. Given the standard browser action, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing movement behavior: direct emits one move, natural uses a bounded 24-step Bezier path with timing intervals. This adds context that the agent can use to predict outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that conveys the essential purpose and two key options. It is efficient but slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers movement, coordinates, and profile choice. It does not need to explain return values as per rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning for the 'profile' parameter by explaining the exact movement characteristics. For x and y, it reinforces the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it moves the viewport pointer to exact CSS pixel coordinates without clicking, specifying two movement profiles. This distinguishes it from sibling tools like element_hover which target elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each profile (direct vs. natural trajectory), providing clear guidance on choosing a movement style. However, it does not explicitly contrast with alternatives like coordinate-based vs. element-based moves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the agent knows this is a mutating action. The description adds non-obvious context: 'failure-safe drag' and 'immediately before' imply that source/destination are resolved at drag time and that the operation is atomic or failure-tolerant. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the core function using a specific verb and destination types. The second sentence adds scope and a usage alternative. No word is wasted, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (discriminated unions, nested selectors, shadow DOM) and the presence of an output schema, the description adequately covers the core use case, the supported environments, and an alternative. It does not explain failure modes or the exact semantics of 'track-ratio', but those are partly recoverable from the schema's definitions, so the description is sufficiently complete for an agent to select and attempt invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported at 0%, so the description carries the burden of explaining parameters. It does name the destination union types (element, offset, track-ratio) and mentions CSS/XPath scope (iframe, shadow DOM), which adds meaning to selector/frame_selector/shadow_hosts. However, it does not elaborate on 'button' or 'profile', and the track-ratio mechanism is left ambiguous. Overall it partially compensates for low schema coverage but is not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: resolving a source element and a structured destination (element, offset, or track-ratio) before performing a drag. It also distinguishes itself from a coordinate-based drag tool by explicitly mentioning 'use coordinate drag for visual-only targets', making it distinct from siblings like page_pointer_drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: when an element-based drag is needed, including in iframes and Shadow DOM. It also gives a clear alternative: 'use coordinate drag for visual-only targets'. This directly addresses when not to use this tool, satisfying the 'explicit when/when-not/alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds useful context by specifying that cookies and Web Storage are preserved, which is a key behavioral trait. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence fully captures the tool's purpose and scope. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a clear action, the description is complete. It explains the operation and its boundary conditions, and with an output schema present, no additional return-value information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100%. The description adds no parameter details since none exist, matching the baseline for parameter-less tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Clear HTTP cache without clearing cookies or Web Storage.' It uses a specific verb and resource, and explicitly distinguishes itself from cookie and storage clearing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by stating what it does not clear, which differentiates it from browser_cookies_clear and storage_clear. However, it lacks explicit when-to-use or alternative guidance beyond that scope limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=true), the description and schema detail the movement profile: direct single move vs deterministic 24-step bounded cubic Bezier with 8-14ms intervals, optional explicit delay, and press/release behavior. This meaningfully discloses how the click is executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence includes the main action, coordinate basis, trajectory options, and delay without filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, annotations, and presence of an output schema, the description covers purpose, trajectory, and click semantics sufficiently. The main gap—alternatives—is captured under usage guidelines, not completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with clear descriptions for all six parameters (x/y coordinates, button, element, profile, delay), so the description adds little beyond summarizing the trajectory and delay. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific action (move pointer to exact CSS pixel coordinates) and a resulting button press/release, clearly distinguishing this coordinate-based click from element-based siblings like element_click or movement-only page_pointer_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'exact CSS pixel coordinates' gives clear context for when this tool is appropriate, and the delay parameter description adds an important exclusion (not for moving targets). It does not explicitly name alternatives like element_click, so it falls short of full sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses two key behavioral traits: values are redacted unless include_values is set, and retrieval is bounded (as a map). This adds significant context that annotations do not provide, helping the agent understand defaults and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Read') and presents all key information without redundancy. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with an output schema and clear annotations, the description covers the essential behavior (key vs map, redaction). The context of sibling tools and the schema fill in any remaining gaps, making it complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (key and include_values have descriptions, area does not). The description adds meaning by explaining 'by key or as a bounded map' (corresponding to key) and 'redacted unless explicitly requested' (corresponding to include_values). It does not mention the area parameter, but the schema's enum provides clear options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'localStorage or sessionStorage' with specifics ('by key or as a bounded map, with values redacted unless explicitly requested'). It distinguishes from sibling tools like storage_set and storage_clear by making the read-only nature explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for reading web storage, offering both key-based and map-based access. While it does not explicitly mention alternatives or exclusions, the context is sufficient for an agent to infer when to use this tool versus siblings like storage_set or storage_clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Drissionpage-MCP-Server MCP server](https://glama.ai/mcp/servers/jumodada/Drissionpage-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/jumodada/Drissionpage-MCP-Server)

Score Badge

Copy to your README.md:

[![Drissionpage-MCP-Server MCP server](https://glama.ai/mcp/servers/jumodada/Drissionpage-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/jumodada/Drissionpage-MCP-Server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jumodada/Drissionpage-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server