agent-browser

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct browser operation (e.g., click, fill, hover, scroll) with no overlapping responsibilities. Even similar tools like get and read are differentiated by specific data returning or page fetching, and snapshot is distinct from screenshot.
Naming Consistency5/5
All tools follow a consistent 'browser_<verb>' pattern (e.g., open, click, fill, type, press), with no mixed conventions or vague names. The naming is predictable and clearly conveys each tool's action.
Tool Count2/5
With 39 tools, the count exceeds the typical range and feels heavy for most workflows. While the browser automation domain is broad, many tools are granular (e.g., browser_console, browser_trace), leading to potential selection overhead.
Completeness4/5
The tool set covers a comprehensive range of browser interactions: navigation, element actions, state management, debugging, performance monitoring, and network control. Minor gaps exist (e.g., file upload, form submission explicit handling), but most core workflows are well-supported.
Average 2.2/5 across 39 of 39 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails entirely to mention any side effects, permissions, or operational details. The agent cannot infer whether this tool mutates state, reads data, or requires specific conditions.
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?
The description is under-specified to the point of being practically empty. It is not a case of efficient conciseness but of critical information missing. There is no structure or front-loading of any useful detail.
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?
With two parameters, no output schema, and no annotations, the description is drastically incomplete. An agent has no idea what actions are possible, what the effects are, or what the return values might be. This is a profoundly inadequate definition for a tool that likely handles multiple profile operations.
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?
Although the input schema has 100% coverage with descriptions like 'Profile name' and 'Profile action', these are themselves largely uninformative. The description adds no clarification on what constitutes a valid action or how the parameter semantics relate to the tool's operation. It fails to compensate for the schema's vagueness, providing no additional meaning.
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 'Chrome profiles' is a noun phrase that merely restates the tool name without any verb or resource specification. It does not indicate what actions can be performed or what the tool's purpose is precisely, and it does nothing to distinguish it from the many sibling browser 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?
There is no guidance on when to use this tool versus alternatives like browser_session or browser_tab. The description provides no context, prerequisites, or exclusion criteria, leaving the agent entirely without direction on appropriate usage.
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 side effects, safety, and other behaviors. The description contains no behavioral information—no mention of whether actions mutate state, require permissions, or how responses are returned. It is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be seen as concise, but it is under-specified to the point of being a noun phrase rather than a meaningful description. It lacks a clear structure and provides no information that warrants its brevity; it is a placeholder rather than a concise description.
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?
With 11 parameters, no output schema, and no annotations, the description is grossly incomplete. An agent cannot infer how to call this tool correctly, what side effects to expect, or how to interpret results. The description does not even hint at the tool's capabilities.
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?
While the schema descriptions cover all parameters at 100%, the tool description adds no additional meaning about how parameters relate or should be used together. The phrase 'Network requests/routes' does not clarify the role of 'action' or how 'url' interacts with 'mock'. It fails to compensate for the ambiguity of the tool's purpose.
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 'Network requests/routes' is a fragment, not a statement of purpose. It does not specify a verb or resource, and it is ambiguous whether the tool inspects network activity, mocks routes, or both. It does not differentiate from sibling tools like browser_console or browser_trace.
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. The description gives no context about scenarios that favor network inspection or routing, and it names no sibling tools or exclusions. An agent receives no help in selecting this tool appropriately.
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?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only says 'Take screenshot' and does not mention what happens to the screenshot (saved to disk?), whether it returns a path or data, any side effects, or environmental dependencies. This is grossly insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, but this is under-specification rather than conciseness. No useful information is front-loaded, and the single sentence carries no substantive content about the tool's behavior or usage.
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?
For a tool with three optional parameters and no annotations or output schema, the description is completely inadequate. An agent cannot determine what the tool does beyond the obvious, nor what inputs are expected or what it returns.
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?
While the schema provides 100% coverage of parameters, the descriptions are vague ('Full page screenshot' as a string is particularly unclear). The tool's description adds zero additional meaning to the parameters, and does not compensate for the schema's ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply states 'Take screenshot', which is essentially a direct restatement of the tool name 'browser_screenshot'. It conveys a generic verb and resource but provides no specificity about what kind of screenshot, its scope, or how it differs from the sibling tool 'browser_snapshot'.
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?
There is no guidance on when this tool should be used versus its many siblings (e.g., browser_snapshot, browser_state, browser_trace). No context, no exclusions, no alternatives are mentioned.
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, and the description discloses no behavioral traits: no side effects, return values, authentication needs, rate limits, or destructive potential. The word 'devtools' implies some form of inspection but nothing concrete is stated, so the agent is left completely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short but grossly under-specified. This is not effective conciseness; it omits essential information. The single phrase offers no structure or front-loaded guidance, making it closer to a placeholder than a usable description.
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?
For a tool with 4 parameters, no output schema, and no annotations, the description is woefully incomplete. An agent cannot determine what actions are valid, what the JSON output is for, or what a 'fiberId' or 'session' represents in practice. The description fails to provide any context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 per the rubric. The tool description adds no additional meaning beyond the schema entries (e.g., 'React action', 'Fiber ID for inspect'). While the schema descriptions are minimal, the description itself contributes nothing, so the baseline stands.
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 'React devtools' is a noun phrase with no verb or action. It does not state what the tool does, only hints at a subject area. It is vague and could apply to any of many React-related tools, and does not differentiate from the extensive browser_* sibling list.
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?
There is no guidance on when to use this tool, prerequisites, or alternatives. The description gives no conditions for selection, leaving the agent to guess when 'React devtools' is appropriate versus the 38 sibling browser tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. It doesn't mention side effects (e.g., modifying browser state), permissions, return values, or whether actions are reversible. The description 'Manage cookies' reveals nothing about what the tool actually does at runtime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but it's under-specified for a tool with four parameters and unknown behavior. Conciseness should not come at the cost of necessary information. The description doesn't earn its place because it communicates almost nothing beyond the tool name.
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?
For a tool with four parameters, no annotations, and no output schema, the description is completely inadequate. It omits critical details like what actions are supported, parameter constraints, return format, and side effects. An agent has virtually no information to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since all parameters have descriptions, but those descriptions are trivial field labels ('Cookie name', 'Cookie value', etc.) that add no semantic depth. The 'action' parameter is described as 'Cookie action', which is circular. The tool description contributes no additional meaning to the parameters, leaving the agent without understanding what values are valid or how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage cookies', which is a verb plus a resource, but the verb 'manage' is too generic and doesn't specify the actual operations (get, set, delete, etc.). It fails to differentiate from sibling browser tools and gives no indication of what specific cookie-related tasks it accomplishes. The intent is nearly tautological with the tool name, providing little clarity.
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 usage context or guidance is provided. There is no mention of when to use this tool, when not to, or how it relates to alternatives like browser_storage or other browser tools. An agent gets no help deciding whether to invoke this tool for cookie operations.
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?
With no annotations provided, the description carries the full behavioral burden, and it discloses nothing: no mention that subsequent commands target the switched frame, no failure behavior for invalid selectors, no persistence or session effects. This is a significant gap for an operation that mutates navigation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is under-specification, not conciseness. There is no front-loading of any useful constraint, no additional context, and nothing an agent can act on beyond the name itself.
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?
For a tool that changes navigation context with 2 optional params, no annotations, and no output schema, the description is completely inadequate. An agent cannot determine when to call it, what it returns, or what side effects to expect — it cannot be used correctly from this definition alone.
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 100%, so the schema documents both params. However, the description adds zero meaning beyond the schema — it never hints which parameter combination applies in which situation or what 'omit for main' means in practice. The baseline of 3 is not met because the description offers no semantic support at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and resource ('Switch frame') but adds almost nothing beyond the tool name itself. It does not explain what a frame is here (likely iframes), when frame-switching matters, or how it differs from siblings like browser_navigate or browser_tab. It is a borderline tautology.
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 on when to use this tool versus the 37 siblings, when a frame is in play, or when to switch back to the main frame. The schema's 'omit for main' hint is the only usage signal and it lives in the schema, not the description.
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?
With no annotations, the description must disclose any side effects, permissions, or state changes. 'Session management' reveals nothing about whether the tool creates, destroys, or modifies sessions, nor what data it accesses. The agent has no basis to predict consequences of invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but this is under-specification rather than conciseness. It has no wasted words because there are barely any words at all. A concise description would still convey essential information; this does not.
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?
For a tool with three parameters and no annotations or output schema, the description is entirely inadequate. It fails to explain what actions are valid, what scope and prefix mean, and what the tool returns. An agent cannot safely call this tool based on the provided information.
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?
Although schema coverage is 100%, the parameter descriptions ('Session scope', 'Session action', 'Session prefix') merely restate the names and add no meaning. The description adds nothing beyond the schema, and the schema itself is unhelpfully generic. An agent cannot infer valid values or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Session management', which states a resource but no verb or specific operation. It fails to distinguish this tool from siblings like browser_state or browser_navigate, leaving the agent guessing whether it creates, deletes, or queries sessions. This is more informative than a pure tautology but still woefully vague.
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. There are no conditions, context hints, or mentions of sibling tools. The description gives zero information about the intended use case.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Natural language browser control' with no information about side effects, permissions, scope of actions, or whether it modifies browser state. This is completely insufficient for an agent to anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but that brevity reflects under-specification rather than efficiency. It omits essential information about what the tool does and how it works, making it an underspecified placeholder rather than a concise, informative definition.
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 large sibling set and no annotations or output schema, this description is grossly inadequate. An agent cannot determine the tool's purpose, inputs, or expected behavior, making it impossible to use correctly without external knowledge.
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 covers 100% of parameters with descriptions ('Session name' and 'Natural language instruction'), so baseline is 3. The description adds no additional semantic meaning beyond what the schema already provides, so it remains at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Natural language browser control' states a resource (browser) and a general capability (control) but is too vague to indicate the specific function. It does not distinguish this tool from the many specific sibling tools like browser_navigate or browser_click, making it hard for an agent to select this tool over others.
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 on when to use this tool versus alternatives. With over 30 sibling tools covering specific actions, the description gives no conditions or exclusions. An agent cannot tell if this tool should be used for complex multi-step instructions or if it's a fallback for other tools.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals nothing about what 'handle' entails — whether dialogs are dismissed, accepted, or answered with text — nor what happens to the session when a dialog is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words with no wasted text, but this is under-specification rather than conciseness. Every sentence should earn its place; here there is barely a sentence, and it fails to communicate the tool's actual capabilities.
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?
A dialog tool fundamentally requires explaining what actions are available (accept, dismiss, prompt text) and what the text parameter does. With no output schema and no annotations, the description leaves an agent unable to reliably invoke this tool for even a basic accept or dismiss interaction.
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%, so each parameter has a description in the schema. The description itself adds zero value beyond the schema's 'action', 'text', and 'session' hints; 'Dialog action' and 'Prompt text for accept' remain ambiguous about valid values and format. Baseline 3 applies but no additional information is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
'Handle dialogs' restates the tool name without adding specificity. It doesn't name the concrete operations supported (accept, dismiss, prompt input) nor distinguish dialog handling from browser_click or browser_read, which could also interact with UI elements.
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 whatsoever on when to use this tool versus any of the 38 siblings. There is no mention of prerequisites (e.g., pending browser dialog), no exclusions, and no alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails to mention that the 'fix' parameter runs destructive repairs, that the tool may mutate state, or any side effects. The only hint of danger is buried in the parameter description, not the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is not conciseness but under-specification. The description fails to provide any structure or context, and every useful bit of information is absent. A tool with a destructive repair option deserves at least a sentence.
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 tool's potentially destructive behavior, the lack of annotations, and no output schema, the description is completely inadequate. It doesn't explain what it diagnoses, what the output is, when to use it, or what risks exist. Agents would have no way to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'fix' and 'offline' have descriptions), so the baseline is 3. The description itself adds no parameter details beyond what the schema already provides, but it doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Diagnose install' is extremely vague. It gives a general verb ('diagnose') and a resource ('install') but doesn't specify what aspect of install is diagnosed, what conditions it applies to, or how it differs from siblings like browser_install. It's not a tautology but lacks specificity.
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?
There is no guidance on when to use this tool versus the many browser_* siblings, nor any exclusions or context. The description provides zero indication of intended invocation scenarios.
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 behavioral disclosure — and it fails completely. For an arbitrary code-execution tool, there is no disclosure of execution scope (page context vs. browser context), side effects, persistence, return value format, asynchronous behavior, or permission requirements. The agent cannot assess the impact of running a script.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which reads as severe under-specification rather than conciseness. There is no front-loaded qualifying detail or narrative, just a bare phrase. A real conciseness win would pack useful context into a short space; this simply omits everything.
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?
For a dangerous, unannotated code-execution tool with no output schema, this description is wholly inadequate. An agent cannot determine what the script runs against, what it returns, how errors surface, or what side effects persist in the session. Given the tool's complexity and risk profile, this falls far short of a minimum viable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3: the schema already documents both parameters ('JavaScript to execute' and 'Session name'). The description adds nothing beyond the schema, not even context tying the parameters together. It neither improves nor degrades the schema's own coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
'Execute JavaScript' is nearly a tautology of the tool name 'browser_eval' — it states a verb and resource but is barely more informative than the name itself. It does not differentiate from sibling tools like browser_console or browser_react, which also deal with script/code execution contexts. An agent choosing among 39 browser tools gets no discriminating information here.
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?
There is zero guidance on when to use this tool versus browser_console, browser_react, browser_state, or any of the other 38 siblings. No conditions, no alternatives, no exclusions are mentioned. The description provides nothing to help an agent route to the correct tool.
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 behavioral disclosure. It does not mention that hovering may trigger DOM events, requires a visible element, or has any side effects. With zero behavioral context, the agent cannot anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single uninformative phrase. While concise, it does not earn its place by adding value; it merely repeats the name. It lacks structure or a leading action verb beyond the tautological 'Hover element'.
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?
For a tool with many siblings, this description is severely incomplete. It gives no guidance on prerequisites, return behavior, or how it differs from similar actions. An agent cannot determine when to call this tool correctly without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'session' and 'selector' are described). The tool description adds nothing beyond the schema, so the baseline of 3 applies. No extra meaning is provided, and there is no contradiction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover element' essentially restates the tool name 'browser_hover' and adds only the generic resource 'element'. It gives no detail about what hovering does (e.g., triggering CSS :hover events) and does not distinguish this from siblings like browser_click or browser_fill. This borders on tautology, earning a 2 rather than a 3.
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?
There is no guidance on when to use this tool versus alternatives. The description provides no context such as 'use this to trigger hover styles' or 'use click instead to interact'. An agent receives no help in selecting this tool over the many sibling browser tools.
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 behavioral disclosure. 'List/get' implies read-only, but the description does not confirm that, nor does it disclose any side effects, permissions, return format, or error behavior. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('List/get skills') and can be considered concise, but it is under-specified rather than appropriately sized. It is a fragment that conveys no actionable detail, making it closer to the 'process' example of under-specification than a genuinely concise description.
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?
With 3 parameters, no output schema, no annotations, and a two-word description, the tool is completely under-specified. An agent has no idea what a 'skill' is, what 'action' values are valid, how to list vs get, or what the response looks like. This is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all three parameters. Per the baseline rule, a score of 3 is appropriate. However, the description adds no semantic clarity beyond the schema – it does not explain how 'all', 'name', and 'action' interact, nor does it clarify the required 'action' parameter's meaning beyond the vague 'Skills action'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb 'list/get' and an object 'skills', but 'skills' is undefined and ambiguous in the browser tool context. It is not a tautology, but it is too vague to distinguish this tool from anything else – it merely hints at a capability without explaining what a 'skill' is or how this tool differs from the dozens of other browser_* siblings.
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?
There is no guidance on when to use this tool, when to use 'list' vs 'get', or any alternatives. The description does not provide context, prerequisites, or exclusions. An agent is left without any decision framework for selecting this tool.
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?
With no annotations, the description carries full behavioral disclosure burden. 'WebSocket streaming' reveals nothing about side effects, connection lifecycle, error handling, data format, or rate limits. It fails to inform the agent of any behavioral traits beyond the bare minimum implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but this is under-specification rather than effective conciseness. It is front-loaded (only the minimal text exists), but it fails to earn its place by providing any actionable information. It is too sparse to be useful.
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 tool has 3 parameters (one required), an ambiguous 'action' parameter, no enums, no output schema, and no annotations, the description is wholly inadequate. An agent cannot determine valid actions, expected behavior, or how to handle responses. This is critically incomplete.
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%, so the schema already documents the meaning of 'port', 'action', and 'session'. The description adds no extra semantic value beyond the schema, so the baseline of 3 applies. Despite the ambiguity of 'action', the description does not attempt to clarify it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'WebSocket streaming' is tautological – it restates the tool name without a specific verb or resource. It doesn't clarify what the tool actually does (e.g., initiates a stream, receives events, manages connections), and fails to differentiate from 40+ sibling browser_* tools. The purpose is ambiguous.
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?
There is no guidance on when to use this tool versus alternatives like browser_trace, browser_network, or browser_console. No context is provided about typical use cases, prerequisites, or exclusions. The agent is left to guess.
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 behavioral disclosure. 'Manage tabs' reveals no behavioral traits: it doesn't say whether the action is destructive, whether it requires a session, what side effects occur, or what the response contains. This is entirely opaque for a tool with multiple actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks structure such as action enumerations, parameter grouping, or usage examples. The single vague phrase does not help the agent understand the tool.
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 is a 5-parameter tool with a required action, no output schema, and no annotations. The description is wholly inadequate – it gives no information about valid actions, required fields, session handling, or return values. An agent cannot correctly invoke this tool based on the provided definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no meaning beyond the schema – it does not explain how parameters relate or what actions they enable. However, the schema does provide per-parameter descriptions, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage tabs' is vague – it states a resource (tabs) but not a specific action. It lacks the specificity needed to distinguish this tool from siblings like browser_open or browser_navigate, which also deal with tab-like operations. It does not indicate whether the tool creates, closes, switches, or lists tabs.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or exclusion conditions. An agent would have no basis for choosing this over other browser tools.
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 behavioral disclosure. It does not mention whether this operation is read-only, has side effects, requires authentication, or returns data. The agent learns nothing about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is efficiently brief, but it is under-specified rather than concise. It fails to front-load any actionable information, such as requiring a URL or interpreting JSON output. The phrase barely earns its place.
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?
The tool has 3 parameters, no annotations, and no output schema, so the description must compensate for missing structural context. It does not explain what Web Vitals metrics are returned, how the session parameter affects behavior, or what the JSON output contains. The description is wholly inadequate for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (url, json, session). Although the descriptions are brief, they do exist. The tool description adds no additional meaning beyond the schema, so the baseline of 3 for full coverage is appropriate, but no value is gained from the tool description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Web Vitals metrics', which essentially restates the tool name 'browser_vitals' without adding specificity. It does not indicate what metrics are measured, whether it requires a URL, or what the output looks like. This is near-tautological and fails to distinguish from sibling 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 vs siblings. The description offers no context for selecting browser_vitals over browser_profile, browser_trace, or browser_network. An agent receives no direction on appropriate use cases.
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 behavioral disclosure. It offers none—no details about the audit process, output format, side effects, auth requirements, or whether it is a read-only operation. The description is a bare noun phrase with zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is woefully under-specified at only three words. This is not appropriate conciseness but rather a failure to provide necessary detail. There is no structure or front-loading of key information; it simply restates the topic.
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?
For a tool with 5 optional parameters, no output schema, and no annotations, the description is severely incomplete. An agent cannot determine the tool's purpose, invocation context, expected behavior, or return value from this description alone. It does not meet the minimum requirements for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a brief description (e.g., 'URL to audit', 'axe tags filter'). The description adds no additional parameter meaning beyond what the schema already provides, but since the schema documents all parameters, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Accessibility audit' is a noun phrase that merely restates the tool name (a11y = accessibility) without a verb or resource. It does not specify the action taken or the object audited. No differentiation from sibling tools is provided, and it reads as a title rather than a functional description.
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. No mention of appropriate scenarios, prerequisites, or exclusions. The description offers no context to help an agent decide between this and other browser_* tools.
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 behavioral disclosure. It only says 'Record trace' – it does not explain what gets captured, side effects on the browser session, dependencies, or any safety concerns. This is essentially a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but that is under-specification, not conciseness. It lacks any structural breakdown of purpose, usage, or parameters, failing to communicate even the basic intent of the tool.
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?
For a tool with three parameters, no annotations, no output schema, and a large set of siblings covering similar domains (network, profiling, vitals), this description is completely inadequate for an agent to determine when and how to call it correctly. Nothing about return value, side effects, or typical invocation is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already provides basic descriptions for all three parameters. However, the tool description adds no additional meaning beyond that, leaving the parameter semantics overly generic (e.g., 'Trace action' is ambiguous). Baseline of 3 applies since coverage is full, but there is no enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Record trace' is vague – it states a verb and object but does not specify what kind of trace (network, performance, JavaScript, etc.) nor how it differs from siblings like browser_profile or browser_vitals. It is barely more informative than the tool name itself.
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 any of the many sibling tools. There is no context on typical scenarios, prerequisites, or situations where another 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to mention whether navigation waits for page load, how it affects the session state, whether it returns any result, or if it can fail (e.g., no history to go back). The terse phrase gives no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three words, which is efficient but arguably too sparse to be useful. It is front-loaded but fails to include necessary context, making it less 'appropriate' in size despite its 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 two parameters and no output schema, the description is incomplete. It does not explain the expected values for 'direction', whether 'session' is optional/required, or what side effects occur. An agent cannot confidently call this tool correctly based on the given description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented (though minimally). The description hints that 'direction' might accept values like 'back', 'forward', or 'reload', but does not explicitly define them. It adds a small amount of semantic value beyond the schema's generic 'Navigation direction', but does not fully clarify allowable values or the role of 'session'.
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 'Back/forward/reload' indicates the tool performs browser navigation actions, conveying a specific purpose but lacking a clear verb+resource structure. It distinguishes from siblings like browser_open (which loads URLs) but is vague about the exact mechanism and doesn't fully differentiate from other navigation-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_open or browser_wait. There is no mention of prerequisites, typical use cases, or conditions under which navigation would apply, leaving the agent to infer usage.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Select dropdown option' reveals none of the tool's side effects, such as whether it triggers change events, waits for React updates, or requires visibility. It does not mention error conditions, return values, or any external effects. This is a severe gap for a tool that mutates UI state.
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 and front-loaded, which is concise, but it is under-specified. It conveys the core action and target without fluff, but the brevity leaves out critical context. It is not as vague as a single-word tautology, but it does not earn its place fully since it adds minimal value beyond the name and 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?
Given the tool has no annotations, no output schema, and a simple but non-trivial action (selecting a dropdown option), the description is insufficiently complete. It fails to explain how to specify the option (by value/index/text), whether the dropdown must be open, or any expected behavior after selection. For an agent to invoke this reliably among 38 siblings, more context is needed.
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 includes descriptions for all three parameters (value, session, selector) with 100% coverage. The description adds no additional meaning beyond what the schema already states, so the baseline of 3 applies. No extra clarification is provided for how 'value' is interpreted (e.g., by attribute or text) or how '@ref' works.
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 'Select dropdown option' provides a clear verb ('select') and resource ('dropdown option'), which distinguishes it from generic click or fill tools. However, it lacks detail on what the selection entails (e.g., setting a value, triggering events) and does not explicitly differentiate from similar tools like browser_set, though 'dropdown' adds specificity. It is not a tautology but is minimal.
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 browser_click or browser_fill. The description does not state prerequisites (e.g., dropdown must be open) or scenarios where this is preferred. No context or exclusionary information is provided, leaving the agent to infer usage from the name and schema alone.
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?
With no annotations, the description carries the full burden of disclosing behavior, but it only says 'Manage' which implies both read and write operations without any detail. It does not state side effects, persistence semantics, permission needs, or whether actions are destructive. The minimal description fails to communicate any meaningful behavioral traits.
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 concise sentence with no wasted words, which is structurally clean and front-loaded with the resource. However, it is so brief that it borders on under-specification, yet that is a completeness issue rather than a conciseness issue. It earns points for being tight and direct.
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?
For a tool with 5 parameters, no output schema, and no annotations, the description is grossly incomplete. It fails to explain what actions are available, how key/value/session parameters interact, and what the expected outcomes are. An agent cannot reliably call this tool correctly based on the description and schema alone.
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%, so each parameter has a description, but those descriptions are simply the property names restated (e.g., 'Storage key') without conveying expected values or formats. The tool description itself adds no parameter semantics. Since the schema descriptions are uninformative, the baseline of 3 is applicable due to coverage but no extra value is provided.
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 states a clear resource (localStorage/sessionStorage) and a verb (Manage), but 'Manage' is vague and doesn't specify the exact operations (e.g., get, set, delete) or scope. It distinguishes from siblings like browser_cookie by pointing to web storage, but lacks the specificity needed to select it confidently over other storage-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention conditions like choosing between localStorage and sessionStorage, or when to prefer this over cookie-related tools. The agent is left to infer usage from the name and schema.
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?
With no annotations and no behavioral disclosure, the description fails to inform the agent about side effects, error handling, execution order, return values, or whether it requires a browser context. The 'bail' parameter hints at stopping on error, but this is not explained in the description.
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 concise with no fluff, but it is under-specified. It provides only a bare phrase, which feels more like a label than a structured description, lacking essential details that an agent needs.
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?
For a tool that executes multiple commands, the description is severely incomplete. There is no information on command format, execution semantics, error behavior, or relationship to sibling tools, making it nearly impossible for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, and the description adds no additional meaning beyond what the schema already provides. Since schema coverage is high, the baseline score of 3 applies.
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 that the tool executes multiple commands, specifying a verb ('execute') and a resource ('multiple commands'). However, it does not distinguish itself from sibling tools like browser_eval or browser_click, which also execute actions, so it relies on the term 'multiple' to imply batching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an active browser session), scenarios fitting batch execution, or why one would choose it over individual command tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Install' but gives no indication of side effects, system modifications, required permissions, or reversibility. An agent has no idea what installing Chrome entails or what the outcome is.
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 brief (two words), which is concise, but it is under-specified rather than deliberately compact. There is no front-loading of key information because there is only one clause. Conciseness is not a virtue when it omits essential details.
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?
For an installation tool with no annotations, no output schema, and no parameter elaboration, this description is grossly incomplete. It lacks information on behavior, effects, return values, and any prerequisites or usage constraints. An agent cannot safely or correctly invoke this tool based on the given definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for the single parameter 'deps' (Install system deps), giving 100% coverage. The tool description adds no additional meaning beyond that. Per the baseline rule, a score of 3 is appropriate since the schema covers the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Install Chrome.' It is clear what the tool does, but it doesn't differentiate from siblings. However, none of the sibling tools are install-related, so it stands out naturally. The purpose is unambiguous but lacks any additional scoping.
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 or when not to. There is no mention of prerequisites, alternatives, or context. The description is a single imperative phrase with no supporting conditions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Scroll page' and fails to note whether it scrolls the viewport or a specific element, whether it requires an active session, or whether it has side effects on the page state. This is a critical gap for a browser automation tool.
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 a single short sentence, which is efficient in length but lacks substantive content. It's concise in a structural sense but under-specified, failing to include any useful detail. It neither earns extra credit nor is it verbose enough to penalize heavily.
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 four parameters and no output schema, the description should explain how parameters interact (e.g., whether pixels and selector are exclusive, what direction values are accepted). This description provides none, leaving the agent to infer everything from the schema alone, which is insufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all four parameters with descriptions like 'Scroll direction' and 'Element to scroll'. The description adds no additional meaning beyond the bare action, so 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 states a specific action ('scroll') and resource ('page'), clearly indicating what the tool does. It's not a tautology and distinguishes from other browser tools like click or navigate. However, it lacks nuance about scrolling within an element or by pixels, which could be inferred from the parameters but isn't mentioned here.
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?
There is no guidance on when to use this tool versus alternatives such as browser_navigate or browser_get, or even whether a session is required. The description does not mention any prerequisites or typical scenarios, leaving the agent without any decision framework for selection.
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 carry the burden of behavioral disclosure. It only states the action without explaining consequences (e.g., whether closing is destructive, if unsaved state is lost, or if it affects the entire application vs. just a session). The parameters hint at session-specific behavior, but the description does not elaborate, leaving the agent without critical knowledge for a mutating operation.
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 concise ('Close browser'), but it under-specifies rather than being efficiently complete. It is not verbose, but it omits essential details (e.g., parameter semantics, scope). The brevity is not earned; it sacrifices clarity for minimalism.
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 annotations, no output schema, and only a two-word description, the tool is incomplete for an agent to use correctly. It does not clarify what happens when no parameters are provided, how to close all sessions, or the relationship to sibling tools like browser_session. The agent would need to infer too much from the parameter descriptions alone.
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% – both 'all' and 'session' have descriptions in the schema. The tool description itself adds no extra meaning about parameters, but since the schema already documents them, the baseline of 3 is appropriate. No additional semantic value is provided beyond the schema.
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 states a clear verb ('Close') and resource ('browser'), so the basic purpose is understandable. However, it does not specify the scope (e.g., current session vs. all sessions), and it does not differentiate from sibling tools like browser_session or browser_state. It is minimally clear but lacks precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or context. The description simply says 'Close browser' without explaining whether to use it for closing a specific session, all sessions, or how it relates to other browser_* tools. No exclusions or alternatives are mentioned.
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 does not mention network requests, side effects, session dependencies, or whether reading modifies the page state. The terse phrase 'Read page content or fetch URL' gives no insight into operational behavior.
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 concise (single sentence), with no wasted words, which is good for readability. However, it is under-specified—it conveys almost no actionable detail, so the conciseness is not effective in communicating how to call the tool correctly.
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 a complex ecosystem of sibling tools and no output schema, the description is incomplete. It does not explain return formats, default behavior (active tab handling), or the role of filter and session parameters in practice. An agent would struggle to use this correctly without inspecting the schema and other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (url, filter, session) already has a clear description. The tool description does not add any extra meaning about how the parameters interact, such as the active-tab default when url is omitted, but per the baseline rule for high coverage, a 3 is appropriate.
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 states a verb ('Read') and a resource ('page content') but 'fetch URL' is vague and ambiguous. It does not specify what the tool returns or how it differs from siblings like browser_get, browser_navigate, or browser_snapshot. It is more specific than a pure tautology but lacks functional specificity.
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. With 30+ sibling tools, the description does not mention any conditions, exclusions, or when to prefer browser_navigate for navigation or browser_snapshot for visual captures. The agent must infer usage from the name and schema.
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 says 'Find elements semantically' but does not reveal whether the function performs an action (despite having an 'action' parameter), what it returns, if it mutates state, or if it has side effects. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the action, but it is under-specified. It does not effectively earn its place because it omits necessary details, making it feel less like a helpful summary and more like a placeholder.
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?
For a tool with 5 parameters (3 required), no annotations, and no output schema, the description is grossly inadequate. It lacks any information about return values, error conditions, method options, or action semantics, leaving the agent with almost no guidance on how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters; it doesn't clarify what values 'Find method' or 'Action' accept, nor how 'Accessible name filter' interacts with the required fields. It fully relies on the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (find) and resource (elements) with an adverb (semantically) that distinguishes it from sibling tools like browser_click or browser_snapshot. However, it is vague about what 'semantically' entails (e.g., accessible name, role), so it lacks the specificity of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention cases where browser_get or browser_eval might be more appropriate, nor does it give any context about typical scenarios or prerequisites. The agent receives no routing help.
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 the full burden of behavioral disclosure. It only says 'view/clear' without explaining side effects (e.g., whether clearing is permanent), required permissions, return format, or how the session parameter affects behavior. This is insufficient for safe invocation.
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, which is concise, but it may be under-specified rather than efficient. It conveys the core purpose in one phrase, but the lack of detail suggests incomplete guidance rather than deliberate 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?
Given the tool has 3 parameters, one required (action), and no output schema, the description does not provide enough to call it correctly. It does not explain valid action values, the meaning of 'json' or 'session', or what the tool returns. An agent would need to guess or inspect other sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the parameter descriptions are minimal: 'JSON output' is confusing (input vs output), 'Console action' is vague, and 'Session name' lacks context. The tool description adds no additional clarification, so the score stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (view/clear) and a specific resource (console logs and errors), which distinguishes it from sibling tools that focus on other browser features like network, storage, or DOM. However, it is ambiguous whether the tool supports actions beyond 'view' and 'clear', and how these are selected.
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. Sibling tools like browser_state or browser_network may also surface console-related information, but no exclusions or selection criteria are provided. The agent must infer usage from the vague purpose.
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 present, the description must carry the full behavioral burden. It only states the core action without disclosing whether it is read-only, what it returns, any side effects, or auth requirements. This is insufficient for a tool with six parameters.
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 concise (six words), which earns points for brevity, but it is under-specified for a complex tool with six parameters. It lacks structure, front-loading, or any elaboration that would aid an agent.
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 six parameters, no output schema, and no annotations, the description is far from complete. It does not explain the diff workflow, the meaning of 'type' (e.g., visual vs. DOM), how baseline and target are used, or what the output JSON contains. An agent would struggle to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters have descriptions. The tool description adds minimal meaning beyond the schema—it implies baseline and target are compared, but does not explain their roles or how parameters relate. Baseline 3 applies since the schema carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Diff snapshots/screenshots' clearly states a specific operation (diff) on a resource (snapshots/screenshots). It is not a tautology and distinguishes from siblings like browser_snapshot or browser_screenshot, though it lacks detail on what 'diff' entails.
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 browser_snapshot or browser_screenshot. The description does not mention prerequisites, exclusions, or any contextual cues for selection.
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 carry the full behavioral burden. 'Clear and fill input' implies mutating the page, but it does not disclose side effects, whether the input must be visible or focused, how the session parameter affects behavior, or what the return value is. For a mutation tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one phrase, which is technically efficient, but it is under-specified. It lacks structure and depth, providing only the bare action without any elaboration. This is brevity bordering on vagueness rather than effective 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?
For a browser automation tool with 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return value, error conditions, or any behavioral nuances. An agent would lack critical information needed to call this tool correctly and understand its effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter described (text, session, selector). The description adds no additional meaning beyond the schema; it merely states the tool's action. Baseline 3 is appropriate because the schema already documents parameters, but the description does not clarify how the parameters interact or any special syntax.
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 'Clear and fill input' provides a clear verb and resource – it specifies that it clears and fills an input element. It is distinct enough from siblings like browser_click or browser_scroll, but it does not explicitly differentiate itself from similar input-related tools such as browser_set or browser_type, so it lacks full sibling differentiation.
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 browser_set, browser_type, or browser_press. No context, prerequisites, or exclusions are provided, leaving the agent to guess which tool fits a given scenario.
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 disclosing side effects. It only says 'Set viewport/device/geo/media' and does not indicate whether changes are session-scoped, persistent, reversible, require a reload, or affect other browser state. The optional 'session' parameter hints at session scoping, but the description does not confirm it.
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 compact phrase with no filler and every word contributes to identifying the operation. It is concise but slightly under-explanatory; there is no structure for parameter details or usage context.
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?
For a tool with no annotations, no output schema, and vague parameter descriptions, this one-line description is far too incomplete. An agent would not know valid values for 'setting' or 'value', what session scope applies, what success or failure looks like, or how this interacts with other browser tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the parameter descriptions are largely tautological ('Setting value', 'Session name', 'Setting to change') and do not specify accepted values or formats; the tool description's list of setting categories is the only meaningful addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Set' and lists four concrete setting domains (viewport/device/geo/media), making clear this configures browser emulation settings. It distinguishes itself from sibling tools like browser_navigate, browser_click, and browser_state, though it does not explicitly call out that distinction.
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 about when to use this tool versus alternatives, no mention of prerequisites like an open session, and no context about whether it should be called before navigation or after. Usage is only implied by the word 'Set' and the listed setting categories.
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 behavioral disclosure. It only says 'Type text into input' and does not explain whether it clears existing content, appends, triggers events, requires focus, or handles special characters. This is a significant gap for a typing tool with potentially nuanced behavior.
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 concise, but it is under-specified rather than efficiently informative. It consists of a single clause that essentially restates the tool name. There is no front-loading of critical information, and no sentence earns its place beyond stating the obvious action.
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 existence of many sibling browser tools and the lack of annotations or output schema, the description is incomplete. It does not clarify when to use this tool over alternatives, nor does it describe any behavioral edge cases (e.g., handling of non-input elements, validation, or return values). An agent using this description alone would lack essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters have descriptions), so the baseline is 3. The description adds no additional meaning beyond the schema: it repeats the basic action without explaining how parameters interact (e.g., what 'text' does in relation to the selector, or when 'session' is needed). It meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Type text into input.' It is unambiguous about the action, but it does not differentiate from sibling tools like browser_fill or browser_press. It lacks specificity about the target (e.g., 'the element matching selector') and does not mention any distinguishing behavior, so it falls short of a 5.
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 similar siblings such as browser_fill, browser_press, or browser_set. There is no mention of prerequisites, alternatives, or exclusions. The description is a bare statement of action, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool waits, implying blocking behavior, but does not disclose timeout handling, return values, or what happens when the condition is never met. This is a minimal behavioral disclosure that leaves critical aspects ambiguous.
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 a single short phrase with no wasted words, which is concise. However, it is under-specified and lacks structure; it does not prioritize key information or provide any supporting details. Being short is not necessarily good if it sacrifices necessary content.
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 5 optional parameters and no output schema, the description is incomplete. It omits what happens when no condition is supplied, how timeouts work, and what the tool returns upon success or failure. The presence of many sibling tools suggests the agent needs more context to avoid misusing it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for each parameter (url, text, session, timeout, selector). The tool description loosely maps to these (element/text/URL), but does not explain whether parameters are mutually exclusive, combinable, or how they interact. It adds marginal value over the schema without clarifying usage semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for an element, text, or URL pattern, specifying both the action and the resource types. However, it does not differentiate from siblings like browser_find (which might also locate elements) or browser_state (which could check conditions), missing an opportunity to distinguish itself.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any sibling tools, conditions for use, or exclusions. An agent would have to infer that browser_wait is for synchronous waiting, but nothing explicitly helps with tool selection.
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 behavioral disclosure. It only says 'click element' without revealing any side effects (e.g., potential navigation, page state changes, waiting behavior, or failure modes). The agent is left unaware of what happens after the click or any requirements such as element visibility.
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 concise sentence with no filler words. It front-loads the action and selector types effectively. While it is minimal, it avoids verbosity and is efficient for such a simple operation, though it could afford a bit more context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (2 params, no output schema), the description is too bare to be contextually complete. It fails to mention when to use it (vs siblings), any necessary preparation (like a snapshot), or potential outcomes of the click. For an agent choosing among many browser_* tools, this lack of context increases the chance of inappropriate selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with both parameters already described ('Session name' and 'CSS selector or @ref from snapshot'). The description adds no new information beyond restating the schema's content, so it does not enhance parameter understanding beyond what the agent can already derive from 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 states a clear verb 'click' and the target resource 'element', and explicitly mentions the two selector types ('selector' or '@ref'). It is specific enough to distinguish from tools with different verbs, but it doesn't differentiate from sibling actions that also operate on elements (e.g., browser_hover) beyond the verb itself.
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 browser_hover, browser_select, or browser_fill. It does not mention any prerequisites (e.g., needing a snapshot first) or conditions that would make this the appropriate choice. The description is purely a statement of action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states only that it 'gets' properties, implying a read operation, but does not disclose side effects, if any, whether permissions are needed, or what happens when required parameters are absent. It also does not clarify behavior for different property types beyond the schema's note that selector is required for text/html/value.
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 brief ('Get text/html/value/url/title'), which is concise but arguably too sparse. It front-loads the essence but omits any context or caveats that could help an agent. It is not verbose, but it also does not feel complete.
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 many siblings and no output schema, so the description should clarify what the tool returns and how it interacts with other tools. The listing of property types hints at possible return values, but there is no note about the return format, error cases, or relationships with tools like browser_snapshot or browser_state. The description is insufficient for an agent to call this correctly in all contexts.
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 schema describes each parameter (session, property, selector) with basic descriptions, giving 100% coverage. The description adds significant value by enumerating the allowed values for the 'property' parameter (text/html/value/url/title), which is not present in the schema. This helps agents know what to pass.
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 names a clear verb (Get) and a specific resource (browser property), and lists the exact property types it can retrieve: text, html, value, url, title. This gives a concrete idea of what the tool does. However, it does not explicitly differentiate from sibling tools like browser_read or browser_snapshot, which may have overlapping capabilities.
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. The description does not mention any conditions, exclusions, or prerequisites. With 38 sibling tools, an agent has no basis for choosing browser_get over others without deeper inspection.
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 bears full responsibility for disclosing behavior. It only states 'Open URL in browser' without mentioning side effects like tab behavior, waiting, or session isolation. The session parameter exists but is not explained, leaving critical behavior undisclosed.
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 wasted words. It is appropriately front-loaded and concise, though it could be more informative without being verbose.
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 presence of a session parameter for isolation and many sibling tools that may overlap, the description is incomplete. It does not explain what session isolation entails or when to choose this over browser_navigate. The lack of an output schema also means return behavior is unexplained, making this insufficiently complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so both 'url' and 'session' are documented in the schema itself. The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate given the high 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 states a specific verb and resource ('Open URL in browser') which clearly indicates the action. However, it does not distinguish from sibling tools like browser_navigate or browser_get, which might also open URLs. Thus it is clear in isolation but lacks differentiation.
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 such as browser_navigate or browser_get. The description does not mention any specific scenarios, prerequisites, or distinctions, leaving the agent to infer 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 the full burden. It only says 'Press key' without disclosing any behavioral traits such as whether it triggers keydown/keyup events, requires a focused element, or has side effects like navigating or submitting forms. The schema example 'Control+a' hints at shortcuts but the description does not elaborate.
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 concise sentence with no superfluous words, and the action is front-loaded. It is appropriately sized for a simple tool, though it could include a bit more context without becoming verbose.
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 annotations, output schema, and many siblings, the description is incomplete. It does not explain what element receives the key press, whether a session is required, or how it differs from similar actions. While the schema covers parameters, behavioral and usage context are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'key' and 'session' already described in the input schema. The tool description adds no additional parameter meaning beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press key (Enter, Tab, etc)' clearly states the verb (press) and resource (key) with concrete examples. It distinguishes this from most siblings like browser_click or browser_type, though it doesn't explicitly differentiate from browser_type (which types text) or browser_scroll. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives like browser_type or browser_click, nor does it describe any conditions or context (e.g., requires focus, works on current page). There is no exclusion or alternative routing.
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 behavioral disclosure. It does not mention whether the operation is read-only, how 'refs' are defined, what the output format is, or any side effects. This is a significant gap for a tool that likely returns a complex structural tree.
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 zero fluff. It is concise and efficient, though arguably too sparse to fully communicate the tool's value. Still, for brevity it earns a 4.
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 that likely produces a complex accessibility tree with references, the description lacks essential context: what 'refs' mean, how the output is structured, any limitations, and when this tool is preferred over browser_a11y. Without an output schema or annotations, the description is incomplete for correct invocation and interpretation.
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 a description for the single 'session' parameter (100% coverage), so the description adds no extra meaning beyond what the schema states. It does not explain how the session affects the resulting tree, but the baseline of 3 is appropriate when the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('accessibility tree with refs'), making the tool's purpose understandable. However, it does not differentiate from the sibling tool 'browser_a11y', which likely serves a similar accessibility-related function, so it does not reach a 5.
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 browser_a11y or browser_read. It does not specify any conditions, exclusions, or prerequisites, leaving the agent to infer usage from the name alone.
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 bears the full burden of disclosing behavioral traits. It only states 'save/load' without detailing side effects, such as file writes, overwriting behavior, or whether any authentication is required. The description does not reveal what happens on save vs load, whether it processes the path or session, or any error conditions. This is insufficient for a state-management tool.
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, concise sentence that captures the core purpose. It is front-loaded with the action verbs and clearly states the resource. No unnecessary words are used, making it efficient for an agent 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?
Given the tool's simplicity, one might expect a short description, but it lacks essential details an agent needs to call it correctly. The description does not explain how the 'action' parameter works, whether 'path' and 'session' are required or optional depending on the action, or what the return/output looks like. Since there is no output schema, the agent would be left guessing about the response format and edge cases.
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 descriptions for all three parameters with 100% coverage, setting a baseline of 3. The description 'Save/load auth state' does not add any further meaning beyond what the schema states, such as clarifying the allowed values for 'action' or the relationship between 'path' and 'session'. It does not compensate beyond the schema, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: saving and loading authentication state. It uses specific verbs ('save/load') and a specific resource ('auth state'), which is sufficient to understand its purpose. However, it does not explicitly differentiate from sibling tools like browser_cookie or browser_storage, which might manage related data.
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 gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or scenarios where saving or loading auth state would be appropriate. The only implied usage is from the task itself, but nothing explicit is provided.
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:

[![AgentbrowserMcp MCP server](https://glama.ai/mcp/servers/Nirmalraj10567/AgentbrowserMcp/badges/card.svg)](https://glama.ai/mcp/servers/Nirmalraj10567/AgentbrowserMcp)

Score Badge

Copy to your README.md:

[![AgentbrowserMcp MCP server](https://glama.ai/mcp/servers/Nirmalraj10567/AgentbrowserMcp/badges/score.svg)](https://glama.ai/mcp/servers/Nirmalraj10567/AgentbrowserMcp)

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/Nirmalraj10567/AgentbrowserMcp'

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