browser-firefox-mcp

by ironessi

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.1.0
Disambiguation3/5
Several tools overlap in purpose, such as inject_xss_payload vs inject_payload and find_reflection vs find_sensitive_data, though descriptions help distinguish them. Most tools are distinct, but the boundaries are not always crystal clear.
Naming Consistency3/5
Naming is mostly verb_noun with underscores, but there are deviations like 'dom_analysis' and 'security_headers_check' that reverse the pattern, and 'new_context' is not a clear verb. Mixed conventions remain readable but lack strict consistency.
Tool Count2/5
With 40 tools, the server exceeds the recommended range for a focused MCP server. Many tools are highly specialized (e.g., network capture, security scanning) and contribute to a heavy surface, making it feel over-scoped.
Completeness4/5
The toolset covers a wide range of browser automation and security testing operations, including navigation, interaction, cookies, storage, network capture, and security checks. Minor gaps like hover/focus or tab management exist, but overall it's comprehensive for its domain.
Average 3.3/5 across 39 of 40 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and no description, so no behavioral traits such as side effects, permissions, or state changes are disclosed. The tool's behavior is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is not appropriately sized because it conveys no useful information. It fails to be front-loaded with any meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of reloading a page, a complete description would at least mention the action and any relevant behavior. The empty description is wholly incomplete for understanding the tool's purpose and effects.
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?
The input schema is empty, so there are no parameters to explain. However, the description also provides no additional meaning or context, leaving nothing to enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is empty, providing no explicit statement of what the tool does. The name 'reload_page' implies functionality, but without a description, the purpose is not clearly communicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No description means no guidance on when to use this tool versus alternatives like 'navigate' or 'go_back'. There is no context provided for appropriate usage.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not state whether this is a read-only operation, whether it requires prior capture, or if it consumes/clears data. It also doesn't explain what a 'summary' includes (e.g., counts, URLs, response times). The tool likely is a safe read, but nothing confirms that.
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, which is concise and front-loaded. However, it is under-specified, but as a standalone sentence it is efficient. Given the need for more detail, one could argue it is too short, but conciseness is not the issue; completeness is.
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?
With no output schema, no annotations, and 0% parameter description coverage, the description is insufficient. The tool's complexity is moderate (2 params, no required), but the description only provides a high-level statement. The agent lacks information on return format, filtering logic, and preconditions, making complete use difficult.
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%, and the description does not explain the parameters beyond the schema. It says 'filtered' but does not elaborate on what status_filter (e.g., HTTP status code range) or resource_types (e.g., image, script) mean. Without further details, the agent cannot correctly construct filters. The description adds minimal value.
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?
The description 'Get a filtered summary of captured network traffic' clearly states the verb and resource, indicating it returns a summary based on filters. However, it does not explicitly differentiate from sibling tools like 'start_network_capture' or 'stop_network_capture', though the summary nature sets it apart. The purpose is clear but lacks detail on what kind of summary (e.g., counts, list) or how it relates to captures.
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 provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites like needing an active network capture, or contrast with start_network_capture. Since there are many sibling tools, the lack of usage context leaves the agent guessing.
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?
With no annotations, the description must disclose behavioral traits. It doesn't mention whether blocking is reversible, whether it affects all contexts or just the current one, what happens to blocked navigations (error, silent?), or any statefulness. It only states the action without context.
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, front-loaded with verb and object. Efficient but perhaps too sparse; still it's well-structured for what it says.
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?
No output schema, no annotations, and the description is minimal. For a tool that modifies browser/navigation behavior, it's very incomplete. It doesn't explain persistence, scope, or interaction with other navigation tools.
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 coverage is 0%, so the description must compensate. It mentions 'glob-style URL patterns' but gives no details on pattern syntax, examples, or constraints. It doesn't add much beyond the schema's array-of-strings.
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 blocks navigations based on glob-style URL patterns, using a specific verb ('block') and resource ('navigations'). It distinguishes from siblings like stop_network_capture and navigate by focusing on blocking rather than navigating or capturing.
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, no conditions or exclusions. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'navigate back' without mentioning side effects like potential state loss, page reload, or behavior when history is empty. This lack of detail reduces transparency.
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 no unnecessary words. It is well-structured and to the point, making it easy to read and understand.
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 description provides the core action. However, it does not mention the return value or any error conditions (e.g., when history is empty). Given the absence of an output schema, this is a minor gap but acceptable for such a basic 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?
There are no parameters, so schema coverage is trivially 100%. The description adds no parameter-related information, but since none exist, it does not need to. The baseline of 3 is appropriate given the high schema coverage.
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 function: navigating back in browsing history. It is specific to the 'go_back' action and unambiguous, though it does not differentiate from siblings like 'go_forward' or 'reload_page' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 lacks any context about appropriate scenarios, prerequisites, or when to avoid using it, such as when there is no previous page.
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?
The description says it injects and verifies reflection, but with no annotations it must also disclose side effects, whether the payload executes, whether it modifies the page/DOM, what 'verify reflection' entails, and any potential impact. None of that is covered.
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 compact and front-loaded, delivering the core action in one sentence. However, it is slightly too sparse given the need for behavioral and parameter context.
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?
This is a potentially impactful injection tool with two arbitrary string parameters, no annotations, and no output schema. The description does not mention return values, success/failure conditions, page impact, relation to XSS injection, or guidance on payload construction, leaving significant gaps for the agent.
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%, so the description must compensate. It loosely hints that 'selector' selects the target element and 'payload' is the custom input, but it does not explain the expected format, whether selector is CSS/XPath, what values payload should take, or how reflection is verified.
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 ('inject') and target ('target element') plus the follow-up verification ('verify reflection'). It distinguishes itself somewhat from sibling tools by emphasizing custom payload and verification, though it does not explicitly contrast with inject_xss_payload.
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 inject_xss_payload, find_reflection, or fill_input. The context implies injection testing, but there are no explicit conditions, prerequisites, or exclusions.
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?
With no annotations available, the description carries the full burden of disclosing behavior. It only states the action ('list all hyperlinks') without revealing whether it mutates state, requires authentication, is affected by page readiness, or has any side effects. It also doesn't describe the output format or whether it includes duplicates or fragments.
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 states the core action without any fluff. It is perfectly front-loaded and easily parsed, earning a perfect score for efficiency.
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?
Given the tool has one parameter and no output schema, the description should at least explain the parameter's effect and the shape of returned data to compensate. It does neither. The simplicity of the tool does not excuse the missing details, especially since the schema coverage is 0% and no alternative source of information exists.
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 sole parameter `relative_only` (default true) has 0% schema description coverage)Skiping, and the description does not mention it at all. The description adds no value beyond the schema's existence; the parameter's meaning and effect on results are unexplained, which is a significant gap for correct invocation.
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 it lists all hyperlinks on the page, specifying the resource (hyperlinks) and the scope (page). It distinguishes itself from sibling tools like enumerate_forms by focusing on links. However, it could be more precise about what qualifies as a hyperlink (e.g., only `<a>` tags or also href-bearing elements).
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., read_page, get_text, or other navigation tools). The description gives no context about typical use cases, prerequisites, or when it might be preferable to a different tool, leaving the agent to infer applicability.
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?
With no annotations, the description carries full responsibility for disclosing side effects. It mentions returning a result but does not warn about potential destructive side effects of executing arbitrary JS, the execution context (page vs. browser), or any security implications. This is a significant gap for a tool that can run arbitrary code.
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 words. It efficiently communicates the core action and result, earning the highest score for conciseness.
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?
Given the tool's power (arbitrary JS execution), the description is too sparse. It omits return value format, error handling, execution context, and safety warnings. Even with only one parameter, this is insufficient for an agent to use it safely and effectively.
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%, so the description must compensate. However, it merely repeats the parameter name ('expression') without explaining what constitutes a valid expression, how results are returned, or whether it is a full script or a single expression. It adds minimal semantic value beyond the schema.
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 action ('Execute JavaScript expression') and outcome ('return result'). It is specific enough to distinguish from the general browser automation siblings like navigate or click, though it does not differentiate from inject_payload or inject_xss_payload which also execute scripts.
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?
There is no guidance on when to use this tool versus alternatives like inject_payload or inject_xss_payload, nor any prerequisites, context, or exclusions. The description only states what it does, not when it is appropriate.
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?
No annotations, so the description carries full burden. It only states it returns True when found, but does not disclose behavior on timeout (false, exception, etc.), whether it blocks, or any side effects. This is insufficient for an agent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and direct. Every word contributes. It is a two-sentence description with no fluff, appropriate for the tool's simplicity.
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?
The tool is simple but the description omits critical behavior (timeout handling, return value semantics, error conditions). Without annotations or an output schema, the description should explain what happens when the element does not appear. It falls short of being complete for an agent.
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%, so the description must compensate. It does not explain the selector format (CSS vs XPath) or that timeout_ms is in millisecondscould be inferred, but not stated. The description adds no value beyond the schema.
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 waits for an element to appear and returns a boolean. It distinguishes from siblings like click or get_text by being the only wait operation. However, it could be more specific about selector type or context, but it's adequate.
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. It does not mention typical use cases like waiting before interacting with dynamic content, nor does it indicate exclusions or prioritize over other wait mechanisms. The description is purely functional, not contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose potential side effects such as irreversible data loss, impact on active sessions, or any required permissions. The behavioral impact is not addressed.
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 states the tool's purpose. It is front-loaded and avoids unnecessary detail.
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 is minimal and lacks context about the implications of clearing cookies (e.g., logging out users, resetting preferences). Given the simplicity of the action, it is somewhat complete but omits potential consequences.
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 tool has no parameters and the schema is empty, so coverage is 100%. The description does not add any parameter-specific meaning, but the baseline for high coverage 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 (clear) and the object (all cookies) within the current context. It is unambiguous and distinct from sibling tools that manage cookies differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 set_cookie or get_cookies. The description only states the function, not the appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the action without revealing crucial behavior such as whether it waits for the element to be visible/clickable, how it handles multiple matches, or what happens on failure (timeout exceptions). This is insufficient for an agent to predict side effects or error conditions.
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 direct and free of redundancy. It is appropriately sized and front-loaded with the essential purpose. Every word contributes to the 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 the tool is simple, the description lacks important context such as whether it performs a single or multiple clicks (if multiple elements match), any preconditions (e.g., element must exist), and the meaning of the timeout parameter. With no annotations or output schema, the description is too sparse to fully guide an agent in varied usage scenarios.
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%, so the description must compensate. It explains the 'selector' parameter (CSS selector) but completely omits the 'timeout' parameter, its meaning, or its default behavior. Only half of the parameters are semantically enriched.
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: 'Click an element identified by CSS selector.' It specifies the verb (click), the resource (element), and the identification method (CSS selector). It distinguishes from the sibling tool 'click_text' by indicating this tool uses CSS selector rather than text.
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 like 'click_text' or other navigation tools. It does not mention context (e.g., dynamic pages, multiple matches, or waiting conditions) or explicitly state exclusions or preferred scenarios.
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?
No annotations are provided, so the description carries the full burden. It states what it does but not behavioral details like whether it waits for the element, errors if the selector is not found, or returns only the first match. The phrase 'visible text' hints at ignoring hidden elements, but that's not explicit.
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 clear sentence, front-loaded with the verb and object. No redundancy, no fluff.
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?
Given no annotations and no output schema, the description should provide more context: for example, whether it extracts text from all matching elements or just the first, whether it respects visibility as in the CSS 'visibility' property, and how it handles JavaScript-rendered content. The current description is too thin for a tool that depends on CSS selector semantics.
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 defines 'selector' with a default 'body', but the description adds only minimal meaning beyond the schema. Since schema coverage is 0%, the description should elaborate on the selector format (CSS selector), but it just restates 'given CSS selector'. The description adds a little value by indicating 'visible text', which clarifies the extraction scope, but it's minimal.
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 ('Extract') and resource ('visible text under the given CSS selector'), which distinguishes it from sibling tools like 'click_text' or 'read_page'. It's clear but doesn't explicitly contrast with 'read_page' which may also extract text content.
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 instance, it doesn't mention how it differs from 'read_page' or 'dom_analysis', nor does it specify suitable contexts such as extracting text from a specific element after navigation.
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?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Navigate forward in history' without mentioning side effects, error handling (e.g., if no forward history exists), or whether it changes the current page. This is insufficient for a navigation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise, but it is also under-specific. It provides the minimal information without elaboration. This is closer to a title than a helpful description, so a middle score is apt.
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?
For a zero-parameter tool with no annotations and no output schema, the description leaves significant gaps. It does not explain behavior when there is no forward history, does not mention whether it fails silently or errors, and does not clarify relation to other navigation tools. The description is minimalistic and incomplete for production use.
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 schema description coverage is 100% (no properties to describe). Since there are zero parameters, the description doesn't need to add parameter semantics. Baseline 4 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 navigates forward in history, which is specific and distinguishes from the sibling tool go_back. However, it does not explicitly differentiate from navigate, which could be a general navigation tool. The verb 'navigate forward' is clear.
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 go_back or navigate. The description only states what it does, not when it should be preferred.
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 states the core behavioral flow: inject probes and check for reflection. However, with no annotations, it does not disclose important traits such as the default clear_first behavior, whether the page is submitted or navigated, or what the result/return looks like. This is adequate but has clear gaps.
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 repetition. It earns its place but is somewhat underspecified, preventing a perfect score for structure.
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?
Given no output schema, no annotations, and sparse parameter documentation, the description is not complete enough. It does not state return values, side effects like clearing the input, or how reflection is detected. The tool's combined injection-and-detection behavior needs more context to be reliably invoked.
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%, so the description must compensate for underdocumented parameters. It adds some meaning by framing selector as an input/textarea target and payloads as XSS probes, but it does not explain clear_first or the selector syntax/format. Significant parameter ambiguity remains.
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 identifies the action ('inject'), the target ('input/textarea'), and the goal ('check for reflection'). It is specific enough to convey the tool's primary function, though it does not explicitly differentiate from sibling tools like inject_payload or find_reflection.
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 when-to-use or when-not-to-use guidance is provided. Sibling tools such as inject_payload and find_reflection exist, but the description does not explain how this tool relates to them or when to prefer one over the other. The only implied usage is targeting input/textarea elements.
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?
With no annotations, the description bears the burden of disclosing side effects. It implies a mutation (writing) but does not mention overwrite behavior, persistence across sessions, or potential errors. This minimal transparency is insufficient for a state-changing 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, clear sentence with no redundancy or padding, achieving maximum efficiency.
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?
The description does not mention return values, success/failure indications, error conditions, or security implications. Given the tool's simplicity, some basic completion (e.g., what happens on success) is expected, but it is absent.
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 lists key, value, and store, but the description adds little beyond restating 'key-value pair' and the storage options. It does not clarify acceptable values for 'store' (e.g., 'localStorage' vs 'sessionStorage') or enforce any constraints, leaving ambiguity.
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 (write) and the resource (key-value pair to localStorage or sessionStorage), making the tool's purpose unambiguous and distinguishable from other browser automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, such as when localStorage is preferred over sessionStorage or when to use other storage-related tools. The description lacks any contextual or conditional instructions.
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?
Without annotations, the description carries the full burden but discloses only the basic action—no side-effect information, return characteristics, or edge-case behavior. While presumably non-destructive, the description could still note that it's a read-only operation or what environmental context affects results, leaving the agent to guess at the operational contract.
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 one-sentence description is extremely concise and front-loaded with the imperative verb 'Extract.' It wastes no words relative to the tool's zero-parameter complexity, though it sacrifices useful return-value detail for brevity.
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?
For a tool with no output schema or annotations, the description leaves critical gaps—it doesn't define what a 'structural summary' contains, its return format, or when to prefer it over read_page or enumerate_*. Given the agent must rely entirely on this text to understand the tool's output, this lack of detail limits effective use.
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?
With zero parameters, the baseline is 4 per the rubric. The description doesn't need to clarify parameter meaning since none exist, and the schema has full (vacuously so) coverage at 100%.
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 'Extract structural summary of the DOM tree' uses a clear, specific verb-resource pairing that immediately conveys the tool's function. It's concise and avoids tautology, though it doesn't explicitly differentiate from overlapping siblings like read_page, get_text, or js_eval.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention that structural inspection differs from content reading (get_text) or scripted evaluation (js_eval), nor does it provide preconditions or fallback recommendations.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic action 'Set a single cookie' and does not mention side effects such as whether it overwrites existing cookies, requires a loaded page, or any security considerations. For a mutation tool, this is insufficient disclosure.
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, short sentence with no redundant words. It is appropriately concise, though it sacrifices informative content for brevity. Given the tool's complexity, it could benefit from a bit more detail without becoming verbose, so a 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 7 parameters, no annotations, and no output schema. The description provides only a minimal statement of purpose and a vague use case, leaving the agent without essential information about parameter semantics, behavioral implications, or when to use it. It is severely under-specified for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 7 parameters. It merely mentions the action but does not explain the meaning of name, value, path, domain, secure, http_only, or same_site. The description adds no value beyond the schema's field names, making it entirely unhelpful for parameter understanding.
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 single cookie' with the verb 'Set' and resource 'cookie', and it specifically notes the difference from sibling set_cookies by indicating 'single'. The added context 'Useful for session token replay' gives a concrete use case, 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 description provides a clear use case ('session token replay') and implicitly differentiates from set_cookies (plural) by indicating this is for a single cookie. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of full guidance.
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?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without elaborating on side effects (e.g., triggering a change event), prerequisites (e.g., existence of the input), or whether multiple files are supported. The description adds minimal behavioral context beyond the literal action.
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. It has no fluff or unnecessary details, and the core action is front-loaded. It is appropriately sized for the tool's simplicity, even though it lacks depth.
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?
Given the tool's simple purpose, one might expect minimal description, but with no annotations and no output schema, the description should at least explain parameter usage or expected behavior. It does not mention how files are uploaded (e.g., via the DOM files property), whether the tool supports multiple files (the array implies it), or what happens after upload. The description feels incomplete for an agent that must invoke it correctly.
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?
The schema has two parameters (selector and file_paths) with no schema-level descriptions, and the tool description contains no explanation of their meaning or expected formats. With 0% schema coverage, the description fails to compensate; it does not clarify that 'selector' is likely a CSS selector or that 'file_paths' expects absolute paths. This is a critical 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 action: upload file(s) to a file input element. It uses a specific verb (upload) and resource (file input element), distinguishing it from siblings like fill_input or click. The wording is unambiguous and communicates the tool's core function effectively.
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 when to use the tool (when you need to upload files to an input) but provides no explicit guidance on when not to use it or which sibling tools to prefer. Since the purpose is self-evident, this falls under 'implied usage' rather than being absent, but it lacks explicit alternatives or exclusions.
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?
With no annotations provided, the description carries full responsibility. It only says 'check', which implies a read operation, but does not disclose whether it is safe, what it returns, or if it performs any side-effects. Given the security testing context, this is insufficient.
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 no redundant text. It is appropriately minimal for a tool with no parameters, though it could add behavioral detail without sacrificing conciseness.
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 no parameters and no output schema, the description must stand alone. It states the action but omits what the result looks like (e.g., a list of headers, a pass/fail report) and any side effects. Given the simplicity, it's minimally adequate but leaves room for ambiguity about the tool's return value or impact.
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, so the schema is empty örst. According to the rubric, 0 parameters gives a baseline of 4. The description does not need to explain parameters; it merely states the tool's purpose, which is adequate.
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 indicates the tool checks for common security headers and protections, using a specific verb and resource. It is distinct from siblings like recon_technology_stack and find_sensitive_data, though it could be more explicit about what 'protections' includes.
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 given on when to use this tool versus alternatives like reading page content or inspecting network capture. It lacks context about prerequisites or expected scenarios, leaving the agent without clarity on selection criteria.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose an important non-obvious behavior: firing framework-compatible input/change events. However, it omits other meaningful behaviors such as the default clear_first behavior, timeout handling, and limitations around non-form elements, leaving clear gaps.
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 short sentences with no filler. It front-loads the core action and then adds a valuable, non-redundant behavioral detail about event firing.
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?
Given four parameters, no annotations, and no output schema, the description is not complete enough. It does not explain timeout behavior, clear_first semantics, supported element types, or failure modes, which an agent would need 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 0%, and the description adds no parameter-specific meaning for selector, value, timeout, or clear_first. It only provides general context that the tool targets form fields, so it does not compensate for the missing parameter documentation.
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 and resource: 'Fill a form field.' It also adds the behavioral detail of firing framework-compatible input/change events, which distinguishes it from sibling interaction tools like click, press_key, or upload_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?
There is no guidance on when to use this tool versus alternatives such as click_text or press_key. It does not mention exclusions, prerequisites, or scenarios where a different interaction tool would be more appropriate.
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?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the basic action and omits any side effects, such as whether current browser state is overwritten, prerequisites like file format or validity, or whether the file must come from export_state. This is a significant gap for a state-restore 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 exactly one sentence, front-loaded with the action and resource. It contains no filler or repetitive content, making it highly concise and easy to parse.
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 simplicity (one parameter, no output schema, no annotations), a minimal description may suffice, but the lack of detail about the file format or behavior on restore leaves some gaps. It is adequate for a basic action but could benefit from noting that the file is likely from export_state and that the current state is replaced.
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 describes a single required 'path' string with no description, and schema coverage is 0%. The description adds minimal value by implying the path points to the saved file, but it does not clarify expected format, absolute vs. relative, or any constraints. It fails to compensate for the lack of schema documentation.
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 'Restore browser state from a previously saved file' clearly specifies the action (restore), the resource (browser state), and the source (a previously saved file). It distinguishes from sibling tools like export_state (which saves) and other navigation/storage tools, 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 states what the tool does but does not provide explicit guidance on when to use it versus alternatives. The context is clear (restore state, likely after exporting), but no exclusions or conditions are mentioned. The sibling export_state implies the pairing, but the description itself offers no direct advice.
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?
No annotations exist, so the description must disclose behavioral traits. It only states the action (detect) without details on method, side effects, or output format. It doesn't mention whether this is read-only, what data is examined, or what the response looks like.
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 with no filler. Every word is meaningful and directly conveys the tool's purpose.
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?
With no output schema or annotations, the description must compensate by explaining return values or behavior. It does not, leaving the agent uncertain about what the tool will output (e.g., a list of technologies, versions, confidence scores). Given the simplicity, the description is minimally viable but incomplete.
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 there is no semantic burden on the description. The schema coverage is 100% (empty properties), and the description correctly implies no input is needed. Baseline 4 applies due to 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 clearly states the tool detects technologies/frameworks/CMS on the current page, using a specific verb and resource. It distinguishes itself from sibling analysis tools like dom_analysis and enumerate_forms by focusing on tech stack detection.
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. The description implies usage for tech stack detection but offers no exclusions, prerequisites, or comparisons to sibling tools like security_headers_check or dom_analysis.
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?
No annotations are provided, so the description carries full burden. It discloses the action and a basic output ('report totals') but does not mention side effects (e.g., whether capture data is cleared, if it can be called without an active capture, or any state changes). This is minimal for a tool that likely mutates state.
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 short sentence, front-loaded, no filler. Extremely concise and to the point.
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?
The tool is simple but the description omits crucial context: it does not clarify what 'totals' includes, how it differs from get_network_summary, or that it should be called after start_network_capture. Without output schema, the description leaves ambiguity about return format and usage preconditions.
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 schema coverage is trivially 100%. Per the rubric, baseline for 0 parameters is 4. The description does not need to add parameter explanation since there are none.
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 ('stop capturing') and the output ('report totals'). It distinguishes from siblings: start_network_capture initiates, get_network_summary likely reads without stopping, while this stops the capture and provides totals.
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 vs alternatives. It does not mention prerequisites (e.g., must have an active capture) or contrast with get_network_summary or start_network_capture. The usage context is only implied by the tool's name and sibling presence.
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?
No annotations are provided, so the description must disclose behavior. It mentions saving cookies and storage to a file, but does not explain side effects (e.g., whether it overwrites existing files, whether it requires specific permissions, or whether it returns any confirmation). Given the absence of annotations, this is a significant gap.
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, very concise, no fluff.
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 export tool with one parameter and no annotations, the description covers the core purpose but lacks details like file overwrite behavior, file format, or relation to import_state. It is adequately minimal but could be more 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 has one param 'path' with no description in schema. The tool description implies that path is the file destination but doesn't specify format or how it's interpreted. Minimal added meaning beyond the type.
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
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 when to use (to persist browser state), but does not explicitly contrast with alternatives like import_state or get_cookies. It provides clear context but lacks explicit exclusions or guidance on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that cookies are injected and gives a Burp export example; it does not disclose whether existing cookies are overwritten, whether the operation persists, what permissions are needed, or what the result will be.
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 immediately conveys the tool's purpose and a common use case. There is no wasted text or redundant restatement of the schema.
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 having only one parameter and no output schema, the tool lacks annotations and the cookie item schema is empty. The description does not adequately explain cookie object structure or behavioral effects, leaving important gaps for an agent trying to invoke it correctly.
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 shows only 'cookies' as an array of bare objects, with 0% description coverage. The description provides a 'Burp export' hint but does not explain the required fields or shape of each cookie object, leaving the agent to guess what properties such as name, value, domain, or path are expected.
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 specifies the action ('Bulk-inject') and the resource ('cookies'), and the 'Bulk' qualifier distinguishes this from the sibling set_cookie tool. The example 'from Burp export' also anchors the intended use as importing multiple cookies at once.
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 'Bulk-inject cookies' plus the Burp export example provides clear context for when this tool is appropriate. It implies use when you have multiple cookies to set, but it does not explicitly name set_cookie as the alternative for single-cookie scenarios.
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?
With no annotations provided, the description carries the full behavioral burden. It does disclose key semantics: click the first node, match by substring of visible text. But it does not explain timeout behavior, what happens if no node matches, case sensitivity, or whether it waits for the text to appear—leaving the timeout parameter ambiguous.
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?
This is a single, front-loaded sentence that communicates the action, target, and matching rule without filler. Every word contributes meaning.
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 itself is low-complexity, and the core behavior is defined, but with no annotations and no output schema, the description leaves behavioral gaps around timeout and failure handling. It is adequate for basic understanding but not complete for reliable automated 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 0%, so the description should compensate for the parameters. It clarifies 'text' implicitly as the substring to look for in visible text, but 'timeout' is entirely unexplained: what it measures, how it behaves, and what happens on timeout are all absent.
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 (click), the target type (first node), and the matching criterion (visible text contains the given text). This distinguishes it from the generic 'click' sibling tool by specifying text-based targeting rather than selector-based targeting.
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 use case is implied: click a node by its visible text rather than by a structural selector. However, the description does not explicitly say when to prefer this over the sibling 'click' tool or mention any exclusions/when-not-to-use scenarios.
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?
With no annotations, the description carries the full burden. It clearly indicates a read-only operation (checking for reflection), but it does not specify the return format (e.g., boolean or details) or any potential side effects. This is neither highly transparent nor opaque.
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 no redundant information. It is well-structured and easy to understand.
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 one parameter and no output schema, the description adequately states the purpose. It could mention whether it returns a boolean or other result, but this is not strictly necessary given the simplicity and lack of output schema.
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 meaning to the 'text' parameter by indicating it is the string to check for reflection, but it does not specify matching criteria (e.g., exact match, case sensitivity). This is useful but minimal beyond the schema's basic type.
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: checking whether a given text appears in the current page DOM. This is specific and distinguishes it from sibling tools like 'find_sensitive_data' or 'dom_analysis'.
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 that it is suitable for XSS reflection testing, nor does it differentiate it from similar tools such as 'find_sensitive_data'.
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?
No annotations are provided, so the description needs to explain side effects and behavioral boundaries. It says only that the tool scans HTML/text; it does not disclose whether the operation is read-only, whether it modifies browser state, whether it depends on the current page being loaded, or what kind of results are returned.
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 crisp sentence with no filler, no redundancy, and the core action and target are front-loaded. It is appropriately concise for a zero-parameter tool.
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 zero-parameter scan invoked against the current page, the description provides enough core context to be usable. It is slightly incomplete because it does not explicitly state that it works only on the current page or describe what a successful finding looks like, but the overall simplicity keeps it adequate.
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 its schema is fully covered by an empty properties object, so little parameter documentation is needed. The description adds context about what the tool scans, which satisfies the low semantic 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 clearly states a specific action (scan), the target resource (page HTML and text), and the detection goal (leaked secrets, keys, tokens). This distinguishes it from sibling tools like read_page, get_text, and security_headers_check.
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?
There is no explicit guidance about when to use this tool versus alternatives, no prerequisites are stated, and no comparison is made to other scanning/reading tools. The intended usage is only weakly implied by the verb.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Dump' clearly implies a read-only operation, which is correct, but it does not explain what the output format is, whether both storage areas are returned together or separately, or any edge cases (e.g., empty storage). This is adequate for a low-risk read operation but lacks 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 with no filler. It is direct and front-loaded, stating exactly what the tool does. Every word contributes to the purpose, and there is no unnecessary elaboration.
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?
The tool has no output schema, so the description must convey return value structure. It only says 'dump contents,' which is vague about the format (e.g., JSON string, object with separate keys, raw text). Without this information, the agent cannot reliably parse the result. Given the simplicity of the task, this is a significant gap.
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 schema is empty. The description is the only source of meaning, and it clearly names the two storage types being accessed. Since there are no parameters to explain, the baseline for zero-parameter tools is 4, and the description suffices.
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 'Dump localStorage and sessionStorage contents.' uses a specific verb ('dump') and a clear resource (localStorage and sessionStorage). It unambiguously distinguishes this from sibling tools like get_cookies or set_storage_item, which deal with other storage domains.
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 typical scenarios (e.g., inspecting storage before/after actions) or exclude cases where another tool might be better (e.g., get_cookies for cookies). The lack of explicit usage context leaves the agent to infer solely from the tool name.
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?
No annotations are present, so the description carries the transparency burden. It does disclose meaningful behavior: the context is isolated and has a separate cookie jar. However, it does not state whether the new context becomes active, what it returns, or how existing contexts are affected.
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, and it is easy to parse quickly.
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?
This tool creates a stateful browser resource, has no output schema, and has no annotations. The description omits critical details such as the return value/context identifier, whether the new context becomes the active one, and the expected shape of the proxy object. An agent cannot fully determine how to chain this with list_contexts or subsequent navigation.
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 the only parameter, proxy, so the baseline is 3. The description adds no extra proxy semantics, and the schema's 'Proxy settings dict' is thin for a nested object, but it remains acceptable for a single optional 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 clearly uses the verb 'Create' with the resource 'new isolated browser context', and adds a distinguishing detail: 'separate cookie jar'. This makes it easy to identify the tool's function and distinguish it from siblings like list_contexts and get_cookies.
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?
There is no explicit 'use when...' or 'instead of...' guidance. The phrase 'isolated browser context' implies when the tool would be useful, but it does not explain when to choose it over reusing the current context or how it relates to list_contexts/close_browser.
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?
No annotations are provided, so the description carries the full burden. It conveys a read-only 'extract and list' operation, but omits whether the parameters come from the current navigation context, whether values are URL-decoded, and what the output structure looks like.
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 with no filler or redundant elaboration.
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 zero-argument getter, this is mostly sufficient, but the lack of an output schema means the description should clarify the source URL (current page) and the exact return format. The sibling context implies a browser page, but it is not explicitly stated.
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 baseline is 4. The description correctly implies no input is required and 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 uses a specific verb/resource pair: 'Extract and list all URL query parameters.' This distinguishes it from sibling tools such as get_cookies or get_session_info, which target different data.
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 intended use is implied: call this when you need URL query parameters. However, it does not explicitly state that it operates on the current page's URL, nor does it mention alternatives like js_eval for manual extraction.
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?
With no annotations provided, the description carries the burden. 'Release resources' hints at cleanup but remains vague about side effects like clearing sessions or whether it's reversible. For a trivial close operation, it's adequate, but more detail on consequences would improve it.
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 primary action. No wasted words, and every part contributes to understanding the tool's function.
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, and no output schema, the description fully covers the essential behavior. It could mention what happens to browser context or data, but for a close operation in a browser automation suite, it is sufficiently complete.
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?
There are zero parameters, and the schema coverage is 100% (vacuously). The description doesn't need to explain parameters. The baseline for 0 params is 4, and no additional info is required.
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 'Close' and a clear resource 'browser', with the additional detail 'release resources'. It unambiguously distinguishes this from sibling tools like 'navigate' or 'stop_network_capture', and is not a tautology.
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?
Usage is implied by the inherent finality of closing the browser, but there is no explicit guidance on when to use vs. alternatives. For a simple tool, it's acceptable but lacks explicit exclusions or conditions.
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?
There are no annotations, so the description carries full responsibility. It implies a read-only operation ('List'), which is helpful, but it does not disclose whether all forms include hidden or dynamically generated ones, nor does it specify the return format or potential side effects. This is minimal but acceptable for a simple listing tool.
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. It front-loads the action ('List all forms') and directly enumerates the included details (actions, methods, field details). 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 zero-parameter enumeration tool with no output schema, the description adequately covers its functionality. However, 'field details' is somewhat vague and could specify what fields are included (e.g., name, type, value). This is a minor gap given the tool's simplicity.
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 baseline is 4. The description correctly focuses on the output (forms and their details) rather than parameter explanations, as there is nothing to explain.
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 'List' with a clear resource 'all forms' and specifies the content: actions, methods, and field details. This clearly differentiates it from sibling tools like enumerate_links, which focuses on links.
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 enumerating form data, but it does not provide explicit guidance on when to choose this over alternatives such as dom_analysis or enumerate_links. There are no exclusions or alternative mentions, leaving the usage context somewhat implicit.
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?
No annotations are provided, so the description carries the burden. 'List' clearly indicates a non-mutating read operation, but it doesn't explicitly guarantee no side effects or specify whether it returns only non-expired cookies. Still, the behavior is well implied for a simple list tool.
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, front-loaded with the action, and no unnecessary words. It conveys both the primary function and the optional filter efficiently.
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 one-optional-parameter tool with a clear sibling context, the description is adequate. It doesn't describe the return format, but the absence of an output schema makes that less critical. The description is complete enough for the tool's simplicity.
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% for the only parameter, and the description repeats the same 'domain patterns' filtering info without adding new semantics. No additional meaning is provided 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 'List all cookies' uses a specific verb and resource, clearly indicating the tool's action. The optional filter by domain patterns adds scope, distinguishing it from sibling tools like set_cookie and clear_cookies.
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 cookies but does not explicitly state when to use it over alternatives. It doesn't mention when not to use it or reference sibling tools like set_cookie for writing operations.
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?
With no annotations, the description must disclose behavior itself. The word 'snapshot' suggests a read-only operation, but it does not explicitly confirm non-destructiveness, mention authentication requirements, rate limits, or side effects. Some transparency via 'detected tokens' hinting at security checks, but it's not fully explicit.
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, well-structured sentence that front-loads the key purpose ('Full session snapshot') and lists contents. No wasted words or 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?
Even without an output schema, the description conveys the main components returned. It could benefit from clarifying the structure of 'detected tokens' or stating that it's a holistic view, but it's adequate for a straightforward snapshot tool.
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?
There are zero parameters, so the schema provides no info. The description adds value by detailing what the snapshot includes (cookies, storage, tokens), which helps the agent understand the output. Baseline for zero params is 4, and the description earns that.
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 ('snapshot') and clearly lists what it returns (cookies, storage, detected tokens). It distinguishes itself from sibling tools like get_cookies and get_storage_data by offering a combined, comprehensive view.
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 it's for getting a full session overview, but does not explicitly state when to prefer it over targeted tools like get_cookies or get_storage_data, nor does it mention any exclusions or prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately states the action and gives examples, but it does not explain how the key press is delivered, whether the page needs focus, or any side effects. The basic behavior is clear, but details are 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 that is directly informative, with examples front-loaded and no filler. 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 one-parameter tool with no output schema and no annotations, the description covers the essential behavior and examples. It could mention the target of the key press (e.g., active element/page), but the tool is simple enough that the current level is nearly complete.
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 input schema only defines a 'key' string with no description, and schema description coverage is 0%. The description adds meaningful examples ('Enter', 'Control+a') that illustrate accepted value formats, compensating reasonably for the missing schema-level documentation of the single 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 clearly states a specific verb ('Press') and a specific resource ('a keyboard key or combination'), with concrete examples like 'Enter' and 'Control+a'. This effectively distinguishes it from sibling tools such as click, fill_input, and upload_file.
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 keyboard interactions, and the examples convey common scenarios, but it does not explicitly state when to use it versus alternatives or when not to use it. The guidance is implicit rather than directive.
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?
No annotations are provided, so the description carries the burden. It states the tool reads the page and returns a summary, which implies a non-destructive read operation. However, it does not disclose whether the read affects the page state (e.g., by executing scripts), or any prerequisites (e.g., page must be loaded). The description is straightforward but lacks deeper behavioral detail; since it's a simple read, a 3 is fair.
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 packs all relevant information: what it reads, and what it returns. Zero filler, perfectly 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 simplicity (no params, no output schema), the description is nearly complete. It tells the agent exactly what the output is (length, title, metadata). Missing details like edge cases (e.g., what if page fails to load) are not critical for a simple read. The description is sufficient for an agent to decide and invoke.
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 schema coverage is 100% (trivially). The description adds meaning by clarifying what data will be returned (DOM HTML length, title, metadata summary), which is useful for an agent to anticipate the output. Since there are no parameters to document, a baseline of 4 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 clear verb ('read') and specifies the resource ('the full page') with explicit scope: 'DOM HTML length + title + metadata summary'. It distinguishes this from sibling tools like get_text (which extracts text) and dom_analysis (which analyzes DOM), making it a unique read-only page summary tool.
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 a quick page overview), but it doesn't explicitly state when to choose this over siblings like get_text or dom_analysis. No exclusions or suggested alternatives are provided, 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?
No annotations are provided, and the description does not explicitly state whether the operation is read-only or has side effects. While screenshots are typically non-destructive, this is not disclosed, leaving some ambiguity.
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, using a single sentence to convey the action and output options. No unnecessary words or repetition.
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 covers the primary functionality and output, but does not mention potential edge cases (e.g., if both path and base64 return are desired, or what happens when saving to a path). This is minor for a simple tool, but a bit more detail could improve 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?
The path parameter is described in the schema ('File path to save image'), but the full_page parameter lacks any description beyond its default value. The tool description mentions 'saves to path' but does not clarify full_page behavior, leaving its semantics partially 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's function ('Take a screenshot') and specifies the output format (base64 string) or saving to a path. This is specific and distinct from sibling tools like navigation or DOM manipulation.
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 capturing visual page state, but does not explicitly state when to choose this over alternatives. However, its purpose is self-evident, and the mention of output options provides 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It transparently states that all HTTP(S) requests/responses will be captured and that this is a 'begin' operation, but it does not disclose side effects such as whether previous captures are cleared, whether capture persists across navigation, or any performance impact.
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 communicates the tool's purpose without extraneous detail. Every word contributes to understanding what the tool does.
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 no-parameter start action, the description is reasonably complete: it names the protocol, the direction of capture, and the scope. It could mention how capture is retrieved or stopped, but the sibling tools make this inferable, and the action itself is minimal.
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 schema provides complete coverage, so there is no parameter information to compensate for. The baseline for a zero-parameter tool is 4, and the description adds appropriate conceptual context without needing 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 uses a specific verb ('Begin capturing') and clearly identifies the resource and scope: all HTTP(S) requests/responses on the current page. This distinguishes it from sibling tools like stop_network_capture and get_network_summary.
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 states what the tool does but does not explicitly say when to use it relative to alternatives. It implies the start of a network capture session, especially given the stop_network_capture sibling, but lacks explicit 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?
No annotations are provided, so the description carries the disclosure burden. It clearly scopes the operation to 'active' contexts and uses 'list', implying a read-only, non-mutating behavior. It could add return-format details, but for a zero-parameter list operation this is sufficiently transparent.
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 short sentence with no filler. The verb, scope, and resource are front-loaded, and 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?
For a parameterless list tool with no output schema, the description is appropriately complete. It names the resource and the scope ('active'). Mentioning the exact return format would be a minor improvement, but the current description is adequate for such a simple tool.
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 an empty input schema. The baseline for no parameters is 4, and the description does not need to explain parameter semantics that do not exist.
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 'list' and a clear resource 'active browser contexts'. It distinguishes itself from sibling tools like new_context and close_browser, which create or close contexts rather than enumerate them.
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 'List all active browser contexts' implies when to use the tool: when you need an inventory of active contexts. However, it does not explicitly mention when not to use it or point to alternatives such as new_context or close_browser.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool performs navigation and reports the final URL, title, and HTTP status, which are key behavioral traits. It does not mention side effects like waiting for load or potential failures, but for a basic navigation tool this is sufficient and non-contradictory.
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 states the action and the return value. There is no fluff, making it easy for an agent to parse quickly.
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 two parameters (100% schema coverage). The description mentions the output fields (final URL, title, HTTP status), which is sufficient for its simple functionality. However, it doesn't elaborate on side effects like network activity or page load waiting, but given the simplicity and no output schema, it covers the core essentials. Slightly better than average.
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 complete descriptions for both parameters (url and timeout_ms), achieving 100% schema coverage. The description adds no additional meaning beyond what the schema states. Since the schema fully documents the parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (navigate) and the resource (URL), and specifies the expected outcomes (final url, title, HTTP status). It distinguishes itself from sibling tools like go_back, go_forward, and reload_page by indicating it navigates to a new URL rather than performing in-page actions.
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 the tool should be used to load a new URL, which is clear from the context. It doesn't explicitly discuss when not to use it or compare with alternatives, but the purpose is unambiguous for the given set of browser tools. The mention of returning final URL hints at handling redirects, providing contextual clarity.
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:

[![browser-firefox-mcp MCP server](https://glama.ai/mcp/servers/ironessi/browser-firefox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ironessi/browser-firefox-mcp)

Score Badge

Copy to your README.md:

[![browser-firefox-mcp MCP server](https://glama.ai/mcp/servers/ironessi/browser-firefox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ironessi/browser-firefox-mcp)

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/ironessi/browser-firefox-mcp'

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