brave-mcp

by menoxz

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Several tools have overlapping purposes: fill, fill_form, and type_text all handle text input; browser_launch and browser_restart are nearly identical; browser_list and browser_status both report on browser state. While descriptions provide some clarification, an agent could easily misselect between these pairs.
Naming Consistency3/5
The majority of tools follow a verb_noun pattern (list_pages, close_page, take_screenshot, navigate_page), but several browser management tools reverse this (browser_list, browser_launch, browser_status) and some tools are single verbs (click, hover, fill, drag). The mixed ordering and occasional vague names (emulate) create an inconsistent but still readable pattern.
Tool Count2/5
With 34 tools spanning page interaction, form handling, performance tracing, network/console inspection, and browser management, the server is heavily overloaded. While the domain is broad, the count exceeds the 25+ threshold and many tools could be consolidated (e.g., merging fill and type_text, or combining browser_list/status).
Completeness4/5
The toolset covers a comprehensive browser automation lifecycle: navigation, page selection, interaction, form filling, file upload, screenshots, snapshots, performance traces, and network/console inspection. Minor gaps include lack of explicit cookie management or request interception, but these can be worked around via evaluate_script.
Average 3.7/5 across 34 of 34 tools scored. Lowest: 2.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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false indicates a mutating operation, but the description adds no behavioral details. It does not disclose whether overrides persist, how the page is affected, or how to reset emulation. Beyond what the annotation already implies, the description contributes nothing.
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 (one sentence), but it is under-specified rather than concise. It omits essential context and merely restates the tool's name, similar to the 'Process' example where under-specification earns a 2.
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 6 parameters, no output schema, and only a readOnlyHint annotation, the description should explain the tool's purpose, behavior, and usage context. The single vague sentence is completely inadequate for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (viewport, userAgent, colorScheme, etc.) has detailed descriptions. The tool description itself adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Emulates various features on the selected page' uses a vague verb and resource but fails to specify which features are emulated (e.g., viewport, user agent, geolocation). It largely restates the tool name 'emulate' without distinguishing it from sibling tools like resize_page or navigate_page.
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 that it handles device emulation, nor does it explain exclusions or relationships with sibling tools. There is no clear context for appropriate 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?
The annotation readOnlyHint=false already indicates a mutating operation, but the description adds no behavioral context beyond the action. It does not disclose side effects, required conditions, or event behavior, so the description contributes minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words or filler. It is front-loaded and delivers the core message efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and the readOnlyHint annotation, the description is minimally sufficient. However, it lacks any mention of return values, error conditions, or usage context, making it less complete than it could be.
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 (from_uid, to_uid, includeSnapshot) are already well-described. The description adds no additional parameter semantics, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (drag) and the target (an element onto another element), distinguishing it from sibling tools like click and hover. However, it is terse and does not elaborate on drag semantics or use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention alternatives, exclusions, or specific scenarios where dragging is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the bare action. Annotations include readOnlyHint:false, but this is not contradictory; however, neither annotations nor description explain side effects, output format, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is clear and front-loaded, with zero unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite five parameters and no output schema, the schema descriptions are thorough. The description is terse but combined with the schema it is largely sufficient. It does not explicitly state return behavior, though the filePath parameter implies default attachment to the response.
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 all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description's phrase 'page or element' adds no extra meaning beyond what the uid parameter already conveys.
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 takes a screenshot of the page or element, using a specific verb and resource. It distinguishes from siblings like take_snapshot by mentioning 'screenshot', but does not explicitly contrast the two 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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description only says what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, which is consistent with 'upload'. However, the description does not disclose side effects, prerequisites, or behavior beyond the act of uploading, such as what happens after upload or any required element type.
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, clear sentence that is appropriately concise and front-loaded. It wastes no words, though it could benefit from additional structured guidance.
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 performs a mutating action (upload) with no output schema and minimal description. It does not explain return values, error conditions, or how the element should be identified, making it incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with descriptions, so schema coverage is 100%. The description does not add any additional parameter semantics beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Upload a file through a provided element' with a specific verb and resource. It differentiates from sibling tools like fill or type_text by focusing on file upload.
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 fill or fill_form. The description only states the action without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint false annotation, the description adds only the default URL behavior. It fails to disclose important side effects such as bringing the new tab to focus, background opening, or the isolated context feature, which are relevant for a mutating action.
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 short and front-loaded, with the core action stated first. However, the second sentence is problematic due to contradicting the required URL, so it does not fully earn its place, though the overall structure is concise.
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 four parameters and no output schema, this description is notably incomplete. It lacks information about the return value, the effect on the current page, background handling, and isolated contexts, leaving the agent with insufficient behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description introduces confusion by suggesting the URL can be omitted ('Use project URL if not specified otherwise'), while the schema marks url as required. This contradictory guidance undermines parameter understanding rather than adding value. No other parameters are addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'open' and resource 'new tab', and explains the URL loading behavior. This effectively distinguishes it from siblings like navigate_page, which likely operates on the current tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new tab is needed, and the project URL fallback provides some context. However, it does not explicitly mention alternatives or when not to use this tool, leaving some ambiguity.
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 only readOnlyHint=false as annotation, the description carries the burden for behavioral disclosure, but it only states what is filled, not how. It does not mention side effects like clearing existing values, triggering events, or behavior on unsupported elements. No detail on selecting options from a <select> is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and without wasted words. It efficiently captures the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and parameters are well-documented in the schema, the description lacks sufficient context for an agent to decide when to use this instead of sibling tools like type_text or fill_form. It also does not mention the role of the snapshot uid or the includeSnapshot parameter, which are relevant for practical usage.
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 all parameters with descriptions (uid, value, includeSnapshot), so the tool description adds no additional semantic value. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs and targets: 'Type text into an input, text area or select an option from a <select> element.' It distinguishes from siblings like click or hover by specifying form-filling behaviors, including the unique ability to select from a <select> element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as type_text or fill_form. The description does not mention exclusions, prerequisites, or scenarios where another sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation (readOnlyHint: false) indicates this action is not read-only, but the description adds no further context about side effects, return behavior, or what hovering does beyond simply moving the cursor. No additional behavioral traits are disclosed beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of fluff. It efficiently conveys the tool's purpose without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and complete schema, the description covers the basic action, but it does not explain the effects of hovering (e.g., triggering popovers) or the nature of the response when includeSnapshot is true. The absence of an output schema and minimal behavioral disclosure leave some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (uid and includeSnapshot) with clear descriptions, providing 100% coverage. The description's phrase 'provided element' adds no information beyond what the schema already states, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('hover') and the target ('provided element'), using a specific verb and resource. This distinguishes it from sibling tools like 'click' and 'drag' which perform different mouse actions.
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. The description does not mention any prerequisites, scenarios, or alternative tools, leaving the agent without context on choosing this over other mouse interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: false signals that this is not a read-only operation, and the description accurately states the click behavior. However, it adds no extra context about side effects, such as triggering navigation or waiting for page loads, beyond what the annotation already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, and front-loaded with the action. Every word earns its place with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool with a fully documented schema and no output schema, this description is sufficient. It clearly states the core behavior, and the schema covers optional parameters like dblClick and includeSnapshot, so no critical information is 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?
The input schema has 100% description coverage, so parameters are already well-documented. The description only refers to 'the provided element,' which aligns with the uid parameter, and does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks on a provided element, using a specific verb and resource. While it distinguishes 'click' from siblings like hover and drag by naming the action, it does not explicitly differentiate itself further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool instead of alternatives such as hover, drag, or press_key. There is no mention of contexts or exclusions, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key constraint ('The last open page cannot be closed'), which adds value beyond annotations. However, readOnlyHint: false already indicates mutation, and the description doesn't elaborate on error behavior, side effects, or whether the operation can be undone. The added constraint justifies a mid-score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — two short sentences that front-load the main action and then state the key limitation. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single well-documented parameter and no output schema, the description covers the core behavior and an important edge case. It omits what happens when an invalid pageId is provided or whether the browser state changes, but these are secondary for this simple mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter, including a description that tells the agent to call list_pages. The tool description adds the phrase 'by its index', which could be interpreted as positional rather than ID-based, potentially causing confusion. Overall, the description does not improve parameter clarity beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Closes the page') and the resource ('page'), with a specific scope ('by its index'). It distinguishes itself from siblings like new_page and select_page. However, 'index' is potentially ambiguous because the schema parameter is called 'pageId', which could imply a stable identifier rather than a positional index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool or when to prefer alternatives. The schema hints to call list_pages to obtain page IDs, but the description itself doesn't mention that workflow or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden and does well by warning that an existing browser without CDP will be closed and relaunched, a key destructive side effect. It also states it does not create an isolated profile, adding useful behavioral context. It stops short of describing return values or whether a default page is opened.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three concise sentences, each serving a distinct purpose: stating what it launches, warning about existing browser behavior, and clarifying the profile limitation. There is no redundant or filler 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?
While the core purpose and a key side effect are covered, the description omits critical operational details such as parameter semantics, expected return value, and whether a new page is automatically created. Given the lack of an output schema and annotations, these gaps leave the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of the three parameters (browser, confirmKill, additionalFlags). The description mentions CDP and user profile but does not map these to any parameter, leaving the agent without guidance on what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool launches a Chromium browser with CDP and the user profile, including sessions, cookies, and accounts. It also explicitly distinguishes this from an isolated profile launch, making it specific and differentiated from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a browser with CDP and a persistent user profile, and clarifies that it will restart an existing non-CDP browser. However, it does not name alternatives or explicitly state when not to use this tool versus siblings like browser_restart or browser_use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool closes and relaunches a browser, which implies destructive action, but does not detail consequences like loss of unsaved tabs or session data. The need for confirmation (confirmKill) is only present in the schema, not the description, so impact is under-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words, front-loading the action and then providing the use case. It is well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (killing a browser), the absence of parameter explanation and behavioral detail makes the description incomplete. It lacks clarity on what happens to the existing browser process, how confirmKill is used, and what the user should expect after the restart. The description is too sparse for a potentially impactful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. However, it gives no explanation of what 'browser' or 'confirmKill' mean, leaving the agent without guidance on how to fill them. The only hint is 'votre profil utilisateur' which implicitly relates to profile use but not to specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it closes a current browser (without CDP) and relaunches it with CDP and the user profile. This specific verb+resource combination distinguishes it from sibling tools like browser_launch or browser_status, which handle different scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use it: 'Utile quand le navigateur est déjà ouvert mais pas en mode debug' (Useful when the browser is already open but not in debug mode). This gives clear guidance on appropriate scenarios, though it does not mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'displays status' and does not mention whether it requires an active browser, whether it is side-effect-free, what the output contains, or any potential errors. This leaves the agent uncertain about the tool's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without waste. It is appropriately concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells the agent what the tool does but omits details about the output structure or prerequisites. Since there is no output schema, the agent is left guessing what 'detailed status' includes. For a simple zero-param status tool, this is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. The description adds no parameter-specific meaning, but the baseline for zero-param tools is 4, and the description is not expected to clarify non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays the detailed status of the CDP connection and open pages, using a specific verb ('Affiche') and resource. It distinguishes itself from siblings like browser_list and list_pages by focusing on CDP connection status rather than merely listing browsers or pages.
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 explicit when-to-use guidance, exclusions, or alternatives. It implies usage for checking status but does not differentiate from similar tools like browser_list or list_pages, and offers no context on when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Get' wording is consistent with a non-mutating operation. It does not add meaningful behavioral context such as return format, ordering, or potential errors, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's function. No unnecessary words or repetitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description is largely sufficient. It clearly indicates that the output is a list of pages, though it does not specify what fields or details are included for each page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema that fully covers them (100% coverage). No parameter documentation is needed, so the baseline score of 4 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?
Description states a specific action ('Get a list') and resource ('pages open in the browser'), making the core purpose clear. However, it does not distinguish itself from sibling tool 'browser_list', which may have overlapping functionality.
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_list' or other page-related tools. The description only states what it does, not the context in which it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral constraint that returned values must be JSON-serializable, which is valuable. However, it does not disclose that executing arbitrary JavaScript may cause side effects (navigation, DOM changes, network requests), though the annotation readOnlyHint=false already hints at mutation. Given the minimal annotations, the description could do more to explain potential impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-woven sentence that front-loads the primary action and immediately follows with the crucial output constraint. No words are wasted, and the structure makes it easy for an agent to grasp the core purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a JavaScript execution tool, the description covers the basic purpose and return format, and the schema provides detailed parameter information. However, it omits important context such as potential side effects, error behavior, and when to prefer this tool over higher-level alternatives. This is adequate but leaves clear gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-described with examples for the function and args. The description adds no additional parameter semantics beyond what the schema provides, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Evaluate'), a resource ('a JavaScript function'), and context ('inside the currently selected page'). It also adds a key detail about JSON serialization, which distinguishes it from sibling tools like click or fill that perform predefined actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'inside the currently selected page,' but it does not provide explicit guidance on when to choose this tool over alternatives like click, fill, or handle_dialog. No exclusions or alternative recommendations are mentioned, so the usage context remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral note—that selecting a page sets it as a context for subsequent calls—which goes beyond the readOnlyHint annotation. However, it does not disclose whether the selection persists across calls, whether bringToFront has any side effects on the browser, or any limitations. The readOnlyHint is consistent with the tool's purpose, so there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It front-loads the core purpose immediately and earns every word, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, simple annotations), the description is mostly adequate. However, it lacks important usage context such as when to select a page before other actions, how the selection affects sibling tools, and whether the selection persists. These gaps make it slightly incomplete for an agent deciding how to sequence calls.
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 already provides descriptions for both pageId and bringToFront, covering 100% of the parameters. The tool description does not add parameter-specific information, but the phrase 'context for future tool calls' gives a small amount of context to pageId, implying it becomes the active page target. This is enough to merit the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (select), the resource (a page), and the purpose (as a context for future tool calls). This distinguishes select_page from sibling tools like new_page, close_page, and navigate_page, which have different operations on pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'as a context for future tool calls' implies that select_page should be used before other tools that operate on a page, but it does not explicitly state when to use it or name alternatives. The schema's pageId description suggests calling list_pages for valid IDs, but there is no direct guidance on when not to use this tool or how it compares to other page-related actions.
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?
Beyond the annotation readOnlyHint=false (indicating this is not read-only), the description adds only the precondition that a dialog has been opened. It doesn't disclose what happens when no dialog is present, whether promptText is required for certain dialog types, or any failure behavior. The description could provide more context about the tool's effects on the browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the condition and the action. It contains no filler or redundant information, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a clear schema, the description combined with the schema provides sufficient context. However, the lack of output schema and absence of error handling details (e.g., what happens if no dialog is open) leaves a minor gap, making it not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (action with enum values, and optional promptText), covering 100% of the parameters. The description adds no extra semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool handles a browser dialog, using the specific verb 'handle' with the resource 'browser dialog'. This distinguishes it from sibling browser automation tools like click, fill, and hover which do not target dialogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for use: 'If a browser dialog was opened'. This tells the agent when to invoke the tool. It doesn't explicitly mention alternatives or when not to use it, but since no sibling tool handles dialogs, the condition alone is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds context about the source (insight set from a trace recording) but does not disclose additional behavioral traits such as return format, error handling, or side effects. It adds some value beyond annotations but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the purpose. It is concise, front-loaded with the verb, and contains no unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with two well-documented parameters and a read-only annotation, the description provides sufficient context about the tool's role in the performance analysis workflow. It could be improved by mentioning the expected output format, but the absence of an output schema and the tool's straightforward nature make the current description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (insightSetId and insightName) clearly documented in the input schema. The tool description does not add any extra parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: providing more detailed information on a specific Performance Insight. It specifies the resource (Performance Insight of an insight set) and the context (highlighted in a trace recording), which distinguishes it from sibling tools like performance_start_trace and performance_stop_trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (after a trace recording, to get details on a highlighted insight) but does not explicitly mention alternatives or exclusions. There is no direct comparison to other performance tools, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, so the mutation nature is known. The description adds that it resizes the 'window' rather than content, but does not disclose potential side effects (e.g., triggering resize events, requiring page selection, or affecting layout). With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, full schema coverage, and an annotation set, the description is mostly sufficient. It lacks units (e.g., pixels) and the prerequisite of selecting a page, but these are minor given the low complexity and presence of sibling tools like select_page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for width and height ('Page width', 'Page height'). The tool description adds no additional semantic detail beyond 'specified dimension', so it does not exceed the baseline for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Resizes') and a specific resource ('selected page's window') with an outcome ('so that the page has specified dimension'). It is distinct from all sibling tools, as none other mention resizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite (a 'selected page') but does not explicitly state when to use this tool vs alternatives, nor mention any exclusions or alternative tools. This is implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, covering safety. The description adds that the wait occurs on the selected page, which is useful context, but does not disclose behavior on timeout or error conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple synchronization tool with a well-documented schema and no output schema, the description adequately conveys the core behavior. It lacks details about timeout outcomes, but that is not critical for selecting or invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with 100% coverage, so the description adds no additional parameter meaning. Baseline score of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool waits for specified text to appear on the selected page, using a specific verb and resource. This distinguishes it from sibling action tools like click, hover, and type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'wait', but there is no explicit guidance on when to use this tool vs alternatives, nor any exclusions or conditions. Context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently describes the tool's core behavior (listing installed Chromium browsers and their runtime status) and the specific status categories it reports. However, it does not disclose potential prerequisites, side effects, or limitations (e.g., whether it scans the system or relies on a pre-existing CDP connection), which prevents a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource, immediately clarifying the tool's purpose. It includes essential details (browser types and status output) without any superfluous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool, the description provides adequate context about what the tool does and what information it returns. However, it lacks detail on the exact structure of the output (e.g., whether it returns names, paths, or IDs) and does not reference related tools or use cases. Given the tool's low complexity and lack of output schema, this is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, giving 100% schema description coverage vacuously. With no parameters to document, the baseline is 4. The description does not need to add parameter semantics, and it does not attempt to invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Liste tous les navigateurs Chromium installés') with specific browser examples (Chrome, Brave, Edge) and the information returned (status: running, CDP active). This is a specific verb-resource combination that distinguishes it from sibling tools like browser_launch or browser_status, which imply targeted operations rather than a comprehensive listing.
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 explicit guidance on when to use this tool versus alternatives. It does not mention alternative tools like browser_status or browser_launch, nor does it explain scenarios where this tool is preferred. The use case is implied by the description but not stated, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical side effect: if the native browser lacks CDP, it will be closed and relaunched with CDP and the user profile. This is important because it may terminate an existing session. However, no other behaviors such as error handling or requirements are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured with bullet points. It front-loads the purpose and uses minimal text to convey key options and side effects, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and the main side effect, which is crucial. Yet it lacks guidance on when to use the tool versus siblings, and the confirmKill parameter is left ambiguous. Given the simplicity of the tool, it is nearly complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some meaning for the 'target' parameter by specifying valid names (Brave, Chrome, Edge) and ports (9222, 9223). However, the 'confirmKill' parameter is not explained, and there is no explicit mapping of parameters to their roles in the described behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Bascule' (switch) and the target resource (connexion to a specific browser). It distinguishes the tool by specifying acceptable targets (names, ports) and the native browser mode, which differentiates it from sibling tools like browser_launch or browser_restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for switching to a specific existing browser (native with profile) or connecting via ports, but it does not explicitly state when to prefer this tool over alternatives like browser_launch or navigate_page. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds performance characteristics (faster, more reliable) but doesn't disclose side effects like partial failures or state changes. With only readOnlyHint=false in annotations, it provides modest additional context, but not enough for a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, concise and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core usage scenario and provides guidance. It doesn't explain return values or includeSnapshot behavior, but the schema covers the parameters. Given the tool's moderate complexity, it is reasonably complete but could acknowledge response handling.
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 already provides full descriptions for all parameters, so the description doesn't need to add much. The example 'Fill username, password, and check Remember Me' illustrates usage but doesn't add new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fill out multiple form elements at once', with a specific verb and resource, and distinguishes from sibling tools like 'fill' and 'click' by emphasizing the batch capability. The example further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'ALWAYS prefer this tool over multiple individual fill or click calls when interacting with forms', naming the alternatives and the condition. It also explains why (faster, reliable, reduces turn count). However, it doesn't state exclusion cases, so not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint false, so the agent knows the tool isn't read-only. The description adds the behavior of returning the currently selected request when reqid is omitted, which is useful context. However, it doesn't mention file-saving side effects (only in the schema) or return format, so it adds some but not rich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 20 words, front-loaded with the verb and resource, and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 optional parameters and no output schema. The description covers the core functionality and the fallback behavior, which is sufficient for the low complexity. It doesn't describe return values, but for a getter this is reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter fully described in the schema. The description only repeats 'optional reqid' already present in the schema, so it adds no additional parameter meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') and resource ('network request'), and clarifies the optional reqid behavior and fallback to the currently selected request. This clearly distinguishes it from sibling tools like list_network_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to supply a reqid and what happens when it's omitted, giving clear usage context. It doesn't explicitly name alternatives or exclusions, but the purpose inherently differentiates it from listing tools, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety. The description adds the useful scoping detail that messages are only since the last navigation, but it does not disclose return format, pagination edge cases, or whether preserved messages are included by default (parameters cover that). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and scope. No filler words or redundant information, earning it a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with full schema coverage and an annotation, the description covers the core purpose and data scope. It lacks explicit mention of alternatives or return shape, but the schema's parameter descriptions and the 'list' verb are sufficient for most use cases. Could be more complete by naming related tools, but overall solid.
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 (types, pageIdx, pageSize, includePreservedMessages) has a clear semantic in the schema. The description adds no additional parameter-level meaning beyond the word 'all', so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List'), specifies the resource ('console messages'), and scopes it precisely ('for the currently selected page since the last navigation'). This distinguishes it from siblings like get_console_message, which focuses on a single message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: for a selected page's console messages since navigation. However, it does not explicitly mention alternatives or exclusions, such as using get_console_message for a single message, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false already indicating the operation is not read-only, the description adds minimal behavioral context. It does not warn about side effects like the automatic reload (which is covered in the schema but not the description). It mentions what insights can be gained, but not what the trace does to the page or runtime. Given annotations carry the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the verb and resource. The second sentence explains the purpose without waffling. Every word adds value, and it is succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a start-trace action with well-documented parameters and no output schema. The description covers the core trigger and use case. It does not explicitly mention the full workflow (start → stop → analyze), but sibling tools imply this, and the schema's reload guidance covers setup. This is nearly complete for selection and invocation, though it could mention stopping the trace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has a detailed description, including usage guidance for `reload` and `filePath`. The description itself does not explain parameters, but the schema fulfills that burden. Therefore, a baseline score of 3 is appropriate since the tool description adds no param-specific info beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a performance trace') and the target resource ('the selected webpage'), and it differentiates from sibling tools like performance_stop_trace and performance_analyze_insight by focusing on initiation. The added use case (Core Web Vitals, page load speed) reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'Use to find frontend performance issues, Core Web Vitals...' It does not explicitly mention when not to use it or name alternative tools, but the purpose is specific enough to guide selection. It could improve by referencing complementary tools like performance_stop_trace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, indicating a mutating action. The description adds context around the active trace but does not disclose failure conditions (e.g., no active trace) or what happens to trace data without a filePath.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that conveys the action with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema. The description covers the core action and the schema explains the parameter; however, it does not specify default behavior when filePath is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the filePath property described in detail. The description does not add parameter-specific information, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and a clear resource ('active performance trace recording') with a scope ('selected webpage'). This clearly defines the tool's action and distinguishes it from sibling performance_start_trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the context (stopping an active trace on the selected page). It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent would know to use this after starting a trace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include readOnlyHint: false, indicating a mutating action, but the description does not add behavioral details such as event firing, focus requirements, side effects, or return behavior. The description adds usage context but no additional behavioral traits beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the purpose and then providing usage guidance. Every sentence earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description adequately covers purpose and when to use it. However, it omits any mention of return values or post-conditions, which could be relevant given the optional includeSnapshot parameter, though the schema covers that parameter's existence.
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 both parameters (key and includeSnapshot) are fully described in the JSON schema. The tool description adds no extra parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool presses a key or key combination, which is a specific action on a specific resource. It also distinguishes from sibling tools like fill by explicitly mentioning keyboard shortcuts and special key combinations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use this when other input methods like fill() cannot be used (e.g., keyboard shortcuts, navigation keys, or special key combinations).' It names an alternative (fill) and lists concrete use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint: false, meaning the tool performs a write operation. The description adds that it captures a heap snapshot of the selected page, providing some context about the operation's effect. However, it does not disclose potential side effects like file creation details or whether the page is paused, so transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and annotations present. The description covers purpose and usage context, making it reasonably complete for an agent to decide when to use it, though it could benefit from a note about saving the snapshot file.
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 fully describes filePath (coverage 100%), so the description does not need to explain it. The description adds no additional parameter info beyond the schema, yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture a heap snapshot of the currently selected page' – a specific verb and resource. It also mentions the use case for memory analysis, distinguishing it from siblings like take_snapshot or performance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the intended use case: 'analyze the memory distribution of JavaScript objects and debug memory leaks.' This implies when to use it, though it does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description is not required to state mutation. The description adds the precondition of a focused input, but does not disclose potential side effects (e.g., replacing existing text, no focus behavior, or the optional submitKey press) beyond what the schema provides. Minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and precondition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is adequate. It specifies the action and the necessary precondition. Minor gaps like submitKey behavior are covered by the schema, so the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented. The description adds no additional parameter meaning beyond what the schema provides; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Type text using keyboard') and the target resource ('previously focused input'). It distinguishes itself from siblings like fill and press_key by specifying the precondition of a focused input, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: it should be used when there is a previously focused input. It implies the tool is for typing into an already-focused element, but does not explicitly mention alternatives or when not to use it, hence not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by describing the a11y tree source and the indication of the selected element in the DevTools panel. It does not explicitly address potential write side effects from filePath, but the schema covers that, and the annotation is not contradicted.
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 paragraph with multiple sentences, each carrying useful information. It is slightly verbose but not wasteful, and every sentence contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains what the snapshot contains (element list with uids) and the indication of the selected element, which is sufficient for the tool's purpose. It could mention how to use the uids, but the sibling tools imply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'verbose' and 'filePath'. The tool description adds no extra parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Take a text snapshot of the currently selected page' and specifies the source as the a11y tree. It also distinguishes from screenshot by noting preference and describes the unique uid identifiers, differentiating it from memory snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Always use the latest snapshot' and states 'Prefer taking a snapshot over taking a screenshot,' providing clear preference over an alternative. It does not explicitly mention exclusions, but the guidance is sufficient for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, which indicates potential side effects. The description adds the exclusion of performance but does not disclose other behavioral traits such as whether the audit navigates/reloads the page, the format of the report, or any prerequisites (e.g., an open page). The schema mentions navigation mode, but the description does not elaborate on side effects, making this acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and directly front-loads the primary purpose. The first sentence states what the tool does, and the second provides a crucial exclusion and alternative. No unnecessary words or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (three optional parameters, no output schema). The description covers the main purpose and the key performance exclusion, which is helpful for tool selection. However, it lacks details about return values, prerequisites, and exact side effects (e.g., does it require an open page? does it save files?). Given the absence of an output schema, the description could be more complete, but it still provides adequate context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema fully documents mode, device, and outputDirPath. The description does not add any parameter-specific meaning beyond the schema. It mentions the audit categories but does not map them to parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get Lighthouse score and reports' for specific categories (accessibility, SEO, best practices, agentic browsing). It also explicitly excludes performance, which distinguishes it from the sibling performance_start_trace. The verb and resource are specific, and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states what the tool does not cover ('This excludes performance') and directs the user to 'run performance_start_trace' for performance audits. This provides clear when-to-use and when-not-to-use guidance, including a named alternative. No other exclusions or alternatives are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful detail that the project URL is used if none is specified. However, it does not disclose other behavioral aspects such as handling of beforeunload dialogs or timeout behavior, which are only in the schema. With readOnlyHint=false, the mutating nature of navigation is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the main action and includes a useful default behavior note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema covering all parameters and the simple navigation task, the description is complete enough. It could mention how this differs from opening a new page (new_page), but the core behavior and scheduling are adequately covered.
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 covers all 6 parameters with descriptions, so the baseline is 3. The description adds value by clarifying that the URL parameter is optional and defaults to the project URL, which is not explicitly stated in the schema property description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs and resources: 'Go to a URL, or back, forward, or reload.' This distinguishes it from sibling tools like click or new_page, and it also notes the default behavior of using the project URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (navigation) and specifies the default URL behavior if none is provided. It does not explicitly exclude alternatives or compare to siblings like new_page, but the task is distinct enough that it is easily understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, which already signals a safe read operation. The description adds no extra behavioral context such as return format, error handling, or side effects, so it provides minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and then efficiently points to the sibling for the broader operation. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no nested objects), the presence of read-only annotation, and full schema coverage, the description adequately covers the necessary context. It provides the key distinction from the list operation and is complete for a simple retrieval tool even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter msgid is 100%, with a description that clarifies it comes from listed console messages. The tool description adds no additional parameter information, so the baseline score of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Gets' with a resource 'console message' and qualifies 'by its ID', clearly indicating a targeted retrieval. It also distinguishes itself from sibling tool list_console_messages by noting the alternative for retrieving all messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that for all messages, use list_console_messages, implying this tool is for a single message by ID. This provides clear guidance on when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint is already true, so the read-only nature is covered by annotations. The description adds valuable behavioral context beyond that: the scope is limited to the currently selected page and only since the last navigation. No hidden side effects or exclusions are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately identifies the action and resource, and contains no superfluous wording or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, a read-only annotation, and a precise scope statement, the description is sufficient for an agent to decide when and how to invoke the tool. The list return type is implied by 'List all requests,' and no output schema 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 input schema describes all four parameters with 100% coverage, so the description does not need to add parameter details. It does not go beyond the schema, but the baseline of 3 is appropriate because the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and names the resource 'network requests' with a clear scope: 'for the currently selected page since the last navigation.' This directly distinguishes it from the sibling 'get_network_request' (single request retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it operates on the currently selected page and covers requests since the last navigation. However, it does not explicitly mention alternatives or when not to use it, though the sibling distinction is implied.
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:

[![brave-mcp MCP server](https://glama.ai/mcp/servers/menoxz/brave-mcp/badges/card.svg)](https://glama.ai/mcp/servers/menoxz/brave-mcp)

Score Badge

Copy to your README.md:

[![brave-mcp MCP server](https://glama.ai/mcp/servers/menoxz/brave-mcp/badges/score.svg)](https://glama.ai/mcp/servers/menoxz/brave-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/menoxz/brave-mcp'

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