Browser Navigator MCP
Server Quality Checklist
Latest release: v2.0.0
- Disambiguation2/5
The 'computer' unified-interaction tool overlaps heavily with dedicated click, type, scroll, hover, navigate, screenshot, and wait tools, making it unclear which to call. Additionally, read_page, get_page_content, list_elements, and inspect_dom all expose page content/structure in different forms, so selection is not obvious.
Naming Consistency2/5Names are a mix of single verbs (click, scroll, hover), verb_noun (get_page_info, inspect_dom), noun_verb (network_start, bookmark_add), and bare nouns (tabs, windows, cookies, health). While bookmark_* and network_* clusters are internally consistent, the overall set lacks a predictable naming convention.
Tool Count2/5At 41 tools, the server is well over the typical well-scoped range, and the count is inflated by a 'computer' meta-tool that duplicates many purpose-specific tools. A consolidated set of 15-20 targeted actions would likely cover the same functionality with less redundancy.
Completeness5/5The tool surface covers the full browser automation lifecycle: connect, navigate, interact, read, wait, capture, manage tabs/windows, handle CAPTCHAs, media, search, network, cookies, bookmarks, and history. No obvious dead ends or missing core operations for mainstream browser automation tasks.
Average 3.3/5 across 41 of 41 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only repeats the action enum already present in the schema. It does not explain side effects, state changes, differences between similar actions (e.g., type vs fill or click vs hover), or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the only substantive phrase is 'Unified interaction'; the rest is a verbatim enumeration of the schema's action enum. This is under-specification rather than earned conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 13-parameter tool with no output schema, no annotations, and no parameter descriptions, yet the description provides no action-specific semantics, usage context, or behavioral details. It is severely incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 13 parameters, and the description adds no meaning to x, y, text, selector, key, delay, scroll_direction, or any other parameter. It merely lists action names already defined in the schema's action enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Unified interaction' plus the action list conveys that this is a consolidated interaction tool, so it is not a pure tautology. However, it does not state a specific resource or distinguish itself from sibling tools like click, type, navigate, hover, and scroll, which offer the same individual 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many specialized sibling tools. The word 'Unified' only implies that it consolidates interactions, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the request carries the browser session/cookies, which is useful, but it says nothing about side effects of non-GET methods, response contents, redirects, error behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words or redundant restatements of the tool name. It could benefit from more structured detail, but as written it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no annotations and no output schema, this one-line description leaves substantial gaps: no return value shape, no usage context versus sibling network tools, and no behavior expectations for methods or timeouts. The session/cookie note is helpful but not sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the five parameters or their intended semantics. It does not clarify how body, headers, timeout_ms, or method should be supplied beyond what the bare schema names and types show.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Send an HTTP request through the browser profile', which tells an agent what the tool does. The parenthetical '(cookies/session apply)' hints at the differentiating factor from generic HTTP tools or other network sibling tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over siblings such as navigate, execute_js, or network_start. The browser-profile context implies a use case, but no explicit exclusions, prerequisites, or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining side effects. It only names actions and does not disclose that 'close' is destructive, 'open' may create and focus a tab, or 'switch' changes the active tab. This is a substantial transparency gap for a tool with mutable behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no filler, and the action verbs are front-loaded. However, it is under-specified for a tool with six parameters and multiple action modes; the brevity veers toward incompleteness rather than tight, high-value structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action, six-parameter tool with no annotations and no output schema, the description is insufficient. It does not specify which parameters are needed per action, what each action returns, or any prerequisites such as an active browser connection, leaving an agent to guess important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds nothing about url, tab_id, window_id, active, or background. The schema's enum and property names provide some limited guidance, but the description does not explain how actions map to required parameters or how active and background interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs—list, open, switch, close, inspect—tied to the tab resource, and the action enum confirms these exact operations. It clearly identifies the tool's scope as tab management, though it does not explicitly contrast itself with nearby siblings like search_tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to choose this tool over alternatives such as search_tabs, get_page_info, navigate, or windows. There are no explicit when-to-use or when-not-to-use conditions, and no exclusion criteria to help an agent route between sibling 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists actions but does not explain side effects, state changes, whether fullscreen affects the browser or only the video element, what get_info returns, or how actions behave when no video/audio is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient line with the core purpose front-loaded and a comprehensive action list. It contains no filler, though it is essentially a bare enumeration rather than a structured explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with no output schema and no annotations, the description leaves important invocation details unstated: value semantics, expected return payloads, and behavioral caveats. An agent could guess the basic actions but would be unable to know correct input formats or what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the optional 'value' parameter. It does not clarify which actions require a value, whether seek uses seconds or a percentage, or how strings differ from numbers. The action enum is already in the schema, so the description adds nothing beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Control HTML5 video/audio playback,' and then enumerates the specific operations it supports. This distinguishes it from the browser-navigation siblings, though it relies heavily on the action list rather than a crisp one-line purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, nor when not to use it. The sibling list contains no other media-control tool, so it is not misleading, but the description leaves all usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only says 'wait for ... load state'. It does not mention whether the tool blocks until the condition succeeds, what happens on timeout, whether it throws or returns a status, or how the 'until' values affect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of filler. It could be slightly more informative, but for the core purpose statement, it is appropriately sized and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, plus two parameters with meaningful enums, the description is under-specified. It omits timeout failure behavior, the meaning of the different load-state conditions, and when to prefer this tool over sibling wait-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no information about 'until' or 'timeout_ms'. The enum values like 'commit', 'domcontentloaded', and 'networkidle' are not explained, and the description gives no guidance on choosing among them or understanding timeout behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('wait') applied to a specific resource ('the page ... load state'), which is more concrete than a tautology. However, it does not explicitly distinguish itself from the sibling tool 'wait_for', relying mostly on the name and the generic phrase 'load state' to convey its narrower purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'wait_for', 'wait_for_captcha', or 'navigate'. The description only states what the tool does, leaving the agent to infer appropriate usage context, such as waiting after navigation or before interacting with the page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool lists elements and returns selectors, which implies a read-only behavior, but it does not disclose whether hidden elements are included, what selector format is returned, or how scope/contains filtering behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence with no fluff, front-loading the main action and giving useful examples. It could be slightly more informative, but as a concise opener it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 4-parameter tool with no output schema and no annotations, yet the description only addresses the purpose and partially the 'kind' parameter. An agent would lack critical information about filtering parameters, return format, and default behavior, so the explanation is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter explanations. It only clarifies 'kind' with examples like links and buttons; the meanings of 'scope', 'contains', and 'limit' are left entirely to the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: listing elements by kind, and adds what is returned (names and reusable selectors). It distinguishes itself from content-reading tools like get_page_content or read_page, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs selectors for page elements, but it gives no explicit guidance about when to prefer this tool over inspect_dom, get_page_content, or read_page. It also does not mention any limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the basic hover action and its intended effect, but does not disclose whether it moves the pointer permanently, whether it waits for menus to render, how failures are reported, or whether it changes UI state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that clearly states the action and its purpose. It is not bloated, though the brevity comes at the cost of important behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, four completely undocumented optional parameters, and no mention of return or failure behavior, the description is too sparse for the agent to invoke this tool reliably. The action is understandable, but the operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no guidance for any of the four parameters (ref, scope, by_text, selector). The agent is left without any hint about which locator to choose or what the parameters mean, so the description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a clear verb and resource ('Hover over an element') and states the point of doing so ('reveal hover menus, tooltips, or submenus'). It is distinguishable from siblings like click and type, though it does not explicitly contrast itself with focus_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose clause implies when to use it: when the agent needs to surface hover-dependent UI. However, there is no explicit guidance about when not to use it or how it relates to alternatives such as click or focus_element.
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 behavioral disclosure burden. It only says navigate and 'wait for it to settle', which hints at blocking behavior but does not explain side effects, what happens to the current page, or what 'settle' means. It also does not mention any permissions, rate limits, or failure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core action, making it easily parsable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with ive params, an enum, and no output schema or annotations, this description is too sparse. It omits contextual details like default tab behavior, background navigation implications, timeout semantics, and return value. The schema covers defaults and constraints, but the description does not enrich the call context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds little parameter -specific meaning beyond the schema's own property names. It implies url and tab_id, and hints at wait_until / timeout with 'wait for it to settle', but it does not explain background, timeout_ms, or the wait_until enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Navigate') and identifies the resource ('a tab' to 'a URL'), making the core action clear. It also distinguishes itself from the sibling navigate_history by emphasizing a URL destination rather than history traversal, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like navigate_history, search, or wait_for_load. The description merely states what the tool does, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool starts capture; it does not mention whether capture persists until network_stop, whether results are returned, whether a browser connection is required, or any stateful side effects. This is a meaningful gap for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and the core action is front-loaded. It is concise and well-structured, even though it leaves important behavioral detail out.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateful operation with no annotations and no output schema, the description is incomplete. It does not explain what the tool returns, when capturing stops, or how this relates to sibling tools like network_stop and network_list. These details matter for correct invocation and interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention max_time or include_static at all. An agent must infer that max_time caps capture duration and include_static controls whether static resources are included, which is not reliable enough without explicit documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (start capturing), a clear resource (HTTP traffic), a target (active tab), and a mechanism (CDP). It is immediately distinct from siblings like network_stop and network_list because it names the initiating role rather than stopping or listing captured traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus network_stop, network_list, or network_request. The intended usage is only implied by the verb 'start', and no prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It only mentions repetition via `times`; it does not explain whether the key press targets the focused element, how the optional `selector` interacts, what side effects occur, or what the tool returns. This is a significant transparency gap for an input-injection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with concrete examples and the repeat behavior included. It has no filler or redundant phrasing and is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description needs to cover parameter meaning, preconditions, and invocation context. It covers the core key-sending action and `times`, but omits `selector` semantics, focus requirements, and any guidance relative to sibling tools, leaving important gaps for the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It illustrates possible `key` values and explains `times` as a repetition count, but `selector` is completely unexplained and accepted key-string syntax is only hinted at through two examples. Agents cannot confidently construct valid parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action directly with 'Send keyboard keys' and gives concrete examples like 'Enter' and 'Control+a', making the core purpose clear. It does not contrast itself with sibling tools such as type, but the resource and verb are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use press_key versus type, focus_element, or click, and offers no exclusions or preconditions. The examples imply it is intended for special keys and shortcuts, but that is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It states that the tool waits up to timeout_ms, but does not explain what happens on timeout, whether it returns as soon as the CAPTCHA is solved, whether it fails if no CAPTCHA is present, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core behavior and directly references the only parameter. Every word earns its place, with no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and no annotations, so the agent is left without key contextual details like return values, timeout results, and whether the tool assumes a CAPTCHA has already been detected. The description is not complete enough for an agent to confidently predict the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It does connect timeout_ms to the waiting behavior, indicating it is the maximum wait duration, but it adds little beyond the parameter name and does not explain timeout consequences or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'wait' and the specific resource 'the page's CAPTCHA', making the tool's primary function obvious. However, it does not explicitly differentiate itself from sibling tools like detect_captcha or wait_for, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as wait_for, wait_for_load, or detect_captcha. There is no mention of prerequisites like having already detected a CAPTCHA, nor any exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that bookmarks can be searched by keyword/tags, without revealing matching semantics (AND vs OR), the effect of limit, or what the response looks like. Even the read-only nature is only implied by the verb 'search,' so this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no filler, front-loading the purpose. It is very concise, though the brevity forces all other information to be omitted. This earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, the one-line description leaves the agent to infer result format, pagination/limit behavior, and the relationship between query and tags. It covers only the most basic purpose, so it is not complete for a tool with sibling alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps query to 'keyword' and tags to 'tags,' adding a little meaning beyond the schema, which has no property descriptions (0% coverage). However, it says nothing about the limit parameter or how keyword and tags combine (the 'and/or' hints at it). This partially compensates for the schema's silence but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear: 'Search bookmarks' names the resource and operation, and 'by keyword and/or tags' specifies the search criteria. It distinguishes itself from sibling bookmark_list (which likely lists all) and history_search (which searches history) by its filter parameters, though it doesn't explicitly name any sibling. A 4 is warranted because it is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus bookmark_list, history_search, or the generic search. The only implied context is that it handles bookmark search by keyword/tags. No exclusions or alternatives are mentioned, so this is scored 2.
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 word 'Extract' conveys a non-destructive read operation, and the description names the output formats. However, with no annotations present, the description carries the full burden and doesn't disclose behavior such as whether the page/element is modified, how the limit affects output, or what happens when no selector is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no unnecessary words. It is appropriately sized for a simple reading tool, though it forgoes any structured param or usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and ambiguous sibling tools like 'read_page', the description is too terse. It doesn't explain param behavior, usage context, or what distinguishes this tool from similar sibling tools, leaving the agent to guess about important call decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'format' to 'text or raw HTML' and 'selector' to 'element', but the 'limit' parameter is left completely unexplained. This is only partial compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Extract') and states both the resource ('page or an element') and the two possible output forms ('readable text or raw HTML'). This makes the core function clear, but it does not explicitly differentiate it from the similarly named sibling tool 'read_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like 'read_page', 'get_page_info', or 'inspect_dom'. The description implies a read operation but does not state when to choose it over other page-reading tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does list the returned data fields and implies a read-only operation via 'Get', but it does not disclose how tab_id affects behavior, possible error conditions, or whether any waiting is involved. This leaves important operational aspects unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action verb, and enumerates all returned properties without filler. There is no wasted or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The missing tab_id semantics, lack of any output schema, and absence of usage guidance mean the tool cannot be invoked with confidence. An agent must guess the parameter's meaning and the return structure, despite the clear field list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single optional tab_id with no description (0% coverage), and the tool description never mentions this parameter. The agent cannot tell whether tab_id is required, what it identifies, or how it relates to the 'current page'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), a resource ('current page'), and a precise list of fields: URL, title, loading status, scroll state, interactivity, and CAPTCHA presence. This clearly differentiates it from content-focused siblings like get_page_content, though it does not name a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no information on when to use this tool versus alternatives such as get_page_content or read_page, no prerequisites, and no mention of the optional tab_id behavior. The only implication is 'when you need page info,' which is weak guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It states the action but does not mention side effects such as triggering a page load, behavior at the beginning/end of history, or whether the tool returns a value. For a navigation-changing tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It accurately and efficiently states what the tool does and where it operates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, even a simple two-parameter tool needs more context. The description omits behavior at history boundaries, whether navigation waits for page load, and interaction with the active tab lifecycle, leaving the agent to infer these from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about the two parameters (steps or direction). The direction enum and defaults are only in the schema, and the description makes no effort to explain or contextualize them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Go back or forward') and identifies the exact resource ('active tab's session history'). This clearly distinguishes it from siblings like navigate (URL navigation) and history_search (searching history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over navigate or history_search, and there are no prerequisites or exclusions. The phrase 'active tab's session history' implies the context, but it does not state when to use it versus 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?
With no annotations, the description carries the behavioral transparency burden. It discloses the recency ordering, but does not state whether it returns full-page snapshots, metadata only, how query matches, or how hours/limit affect behavior. This is adequate for a simple read-only search tool, but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and ordering behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description is too sparse. It does not clarify parameter semantics, result format, or how the hours filter and limit are applied, leaving important context for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the three parameters. It does not explain the meaning or interaction of hours, limit, and query. The parameter names and schema defaults provide some clues, but the description itself adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Search') and resource ('recorded navigation history'), and adds useful ordering information ('most recent first'). It is distinguishable from navigation and tab-search siblings, though it does not explicitly differentiate itself from navigate_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to use this tool versus alternatives such as navigate_history, search, or bookmark_search. The intended context must be inferred entirely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It indicates a connection is established and state is reported, but it does not explain side effects, whether a browser window is launched, what 'state' includes, or failure behavior. It is not misleading but minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and it front-loads the action. It is appropriately sized, though 'report its state' is somewhat underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters, so complexity is low. However, 'report its state' is vague, and there is no clarification about connection lifecycle, prerequisites, or return shape. Still, the basic intent is clear enough for a no-arg tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. The baseline of 4 for parameterless tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (connect) and resource (browser via the extension), and states a result (report its state). It is distinguishable from siblings like disconnect and health, though 'state' remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as health or disconnect. It does not mention prerequisites like extension installation, whether the browser must be running, or when connecting would be inappropriate.
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 behavioral burden. It discloses the core behavior and the optional char-by-char mode, but it does not mention side effects like clearing existing content, event firing, or whether the element must already be focused. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to the purpose, and the optional char-by-char detail is included without adding noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no parameter descriptions, no annotations, and no output schema, the description is too thin to enable fully correct invocation. It leaves unanswered questions about element targeting, timing semantics, and interaction with page state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds meaning for 'text' via 'Type text'. The targeting parameters (ref, selector, scope), timing parameter (delay), and per-character delay are not semantically explained, so an agent would struggle to choose the right parameters confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type text') and names the target element types (input/textarea/contenteditable), making the tool's purpose clear. It doesn't explicitly name sibling tools for contrast, but the distinction from press_key, click, and hover is evident from the wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever text needs to be entered into an editable element. However, it provides no explicit guidance about prerequisites such as focusing the element, nor does it mention when to prefer alternatives like press_key or execute_js.
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?
Without annotations, the description carries the disclosure burden. It reasonably implies a read-only inspection and enumerates what will be returned (tag, attributes, CSS path, subtree, optional HTML). However, it does not disclose behavior on missing elements, whether the page is modified, or how max_depth affects the returned subtree, leaving partial but not complete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to defining what the tool inspects, and the optional HTML clause is compactly handled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, so the description needs to explain both targeting and return behavior. It provides a useful summary of the returned data, but leaves the parameter semantics, error cases, and the meaning of max_depth/include_html under-specified, making the tool not reliably callable by an agent without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not define the core targeting parameters: scope, by_text, and selector. Only loose hints exist, such as 'optionally HTML' mapping to include_html and 'subtree' mapping to max_depth, but an agent cannot reliably determine how to specify which element to inspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and names the exact resource: an element's tag, attributes, CSS path, subtree, and optionally HTML. This clearly identifies it as an element-level introspection tool and separates it from page-level siblings like get_page_content or read_page and from action tools like click/type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternative selection is provided. An agent must infer from the verb 'Inspect' that this is for element inspection, and the description does not say when to prefer it over sibling tools like list_elements, get_page_content, or read_page, nor does it mention prerequisites such as a loaded page.
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 behavioral burden. 'Check whether' appropriately implies a non-mutating read operation, but it does not explicitly reveal whether the check waits for a CAPTCHA to appear, what happens if no page is loaded, or what the return value looks like. The provider list adds useful scope, but timing and response behavior remain implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then efficiently lists the supported CAPTCHA types. There is no redundancy or filler; every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter detection tool, the core purpose is present and understandable. However, since there is no output schema, the description should clarify what the call returns (e.g., a boolean, provider name) and whether it is an immediate snapshot or a waiting check. The missing return-value and timing details leave the agent with uncertainty about how to consume the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema properties are empty, so there are no parameter semantics to document. The description's mention of supported CAPTCHA providers is extra scope context rather than parameter documentation; the baseline for 0-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check whether') and resource ('current page shows a CAPTCHA'), and enumerates the supported provider types (recaptcha/hcaptcha/turnstile/geetest/funcaptcha). It is clear about the tool's core function, though it does not explicitly contrast with the sibling tool wait_for_captcha.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives like wait_for_captcha or other page-state tools. The description does not state whether it should be used after page load, whether it returns immediately, or under what conditions the sibling wait_for_captcha would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does reveal that the tool produces a PNG and saves it under data/screenshots, which is useful. However, it does not explain default capture behavior, whether files are overwritten, or what is returned after the screenshot is taken.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. Key facts are front-loaded: the action, the target, the output format, and the default save location are all covered without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters, no annotations, no output schema, and 0% schema description coverage. The description does not clarify the default capture scope (viewport vs full page), how selector and full_page interact, or what happens when both are omitted. More context is needed for an agent to invoke this reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare parameter names. It partially does: 'full page' maps to full_page, 'one element' maps to selector, and 'saved under data/screenshots' relates to save_path. But it never explicitly names the parameters or explains selector format, save_path handling, or default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') and resource ('page (full page) or one element') and identifies the output format as PNG. It does not explicitly name pdf_export as a sibling alternative, but the 'PNG' format distinguishes it from the PDF-focused sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a PNG image of the page or an element is needed. It gives two capture modes, but it does not explicitly state when to choose this over pdf_export or other browsing tools, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the polling mechanism, the wait condition, and the timeout fallback. However, it does not state what happens on timeout (error/return value), whether ref targets a specific frame/window, or whether visibility is required for both selectors and text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action, covers the main condition, and mentions the timeout. No filler or repetition; every phrase contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no output schema, and no annotations, the description is minimally adequate: it conveys the polling behavior and target condition. But it omits key calling details like whether at least one of selector/text must be provided, how ref scopes the operation, and the success/failure contract on timeout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'selector' and 'text' by explaining that either a CSS selector or visible text can be the wait target. It does not clarify 'ref', the relationship between selector and text (mutually exclusive? combinable?), or the semantics of timeout_ms/interval_ms beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Poll') and names the resource ('the DOM') and the termination condition ('until a CSS selector or visible text appears'). It clearly distinguishes itself from siblings like wait_for_load and wait_for_captcha by focusing on selector/text appearance rather than page load or captcha state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it versus alternatives such as wait_for_load or wait_for_captcha. There are no 'use this when...' or 'instead of...' cues for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys the destructive nature of deletion but omits any detail about irreversibility, what happens when both id and url are provided, what happens when neither is provided, or any return/error semantics. For a destructive operation, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the action ('Delete a bookmark') followed by the two parameter variants. There is no filler or repetition; every word adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers the core operation and identifiers, but leaves several gaps: no required parameters, so behavior when neither is supplied is undefined; mutuality of id and url is not stated; permanence is not mentioned; and there is no output schema or return-value description. These gaps affect an agent's ability to invoke the tool correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the parameters have no schema descriptions, so the description's mention of 'id' and 'exact URL' is the only semantic cue. It clarifies the role of each parameter and that a URL must be exact, but it does not explain precedence if both are supplied, the expected URL format, or the meaning of 'or' in terms of mutual exclusivity. Partial compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), a specific resource ('a bookmark'), and the two accepted identifiers ('id' or 'exact URL'). This clearly distinguishes it from sibling bookmark tools such as bookmark_add, bookmark_search, and bookmark_list, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when a bookmark should be removed, but it does not explicitly say when to choose this over sibling bookmark tools, nor does it mention prerequisites such as needing to first search for the bookmark ID. There is no guidance on parameter preference, so usage context is only implicit from the verb 'delete'.
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 transparency burden. It does add useful behavioral context: delete/clear auto-backups first, and export/import uses encrypted snapshots. However, it does not explain the broader side effects of set/delete/clear/import on the cookie store, nor does it mention any prerequisites 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the most common action (get) and packs the other modes efficiently. The slash-heavy phrasing is slightly dense, but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, six action modes, no output schema, and no annotations, yet the description only gives high-level hints. It does not state which parameters are required for each action, what file should contain for import/export, or what the return value looks like. An agent could invoke simple get/set, but would likely struggle with correct import/export or clear usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that domain and name are filters for get, cookies is used for set, and file is implied by export/import snapshots. However, it does not explain the action parameter's role in selecting these behaviors, nor does it fully specify how each parameter applies to each action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the resource (cookies) and enumerates concrete operations: get with domain/name filtering, set, delete/clear with backup, and export/import of encrypted snapshots. This is a specific, non-tautological statement that clearly separates cookie management from the browser-navigation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or when not to use it. The purpose is strongly implied by the name and the listed actions, so an agent can infer the usage context, but there is no explicit guidance or exclusion wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the core behavior, moving keyboard focus, and adds one important behavioral dependency with press_key. However, there are no annotations and the description does not disclose side effects, failure behavior, visibility requirements, or whether focus changes are synchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one front-loaded sentence that communicates the action and the key usage context with no wasted words. It is a model of concise, structured tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition explains what the tool does and when to use it, but it is not complete enough for reliable invocation: three optional parameters are undocumented, and there is no output schema or annotations to clarify return/error behavior. An agent would need to guess how to construct valid calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names (scope, by_text, selector) with zero descriptions, and the description never explains how an element is targeted or what scope means. With 0% schema description coverage, the description was expected to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Move keyboard focus to an element' and immediately ties it to a real workflow: 'needed before press_key on custom widgets'. This clearly differentiates it from sibling interaction tools like click, hover, and press_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'needed before press_key on custom widgets' explicitly states a when-to-use condition, which is strong context for an agent. It does not mention exclusions or alternative tools for other cases, so it stops short of full routing 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?
With no annotations, the description carries the full burden. It does disclose that the tool is non-disruptive to capture ('without stopping capture'), which is useful behavioral context. However, it does not state what happens when no requests are captured, whether the view is live/snapshot, or any side effects beyond not stopping capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a zero-parameter tool, though 'peek' is slightly informal and 'captured requests' could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the core action but leaves the tool's output format undefined. An agent knows it can view captured requests without stopping capture, but not what data will be returned or how to interpret it, which is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter semantics burden. The description does not need to clarify parameters, and the 'peek' framing aligns well with the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('peek') and resource ('captured requests'), and adds a meaningful qualifier ('without stopping capture') that distinguishes it from network_stop. However, 'peek' is slightly informal and does not specify whether it returns a list, summary, or details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without stopping capture' implies this tool should be used while capture is running, rather than after network_stop. But it does not explicitly say when to prefer this over siblings like network_request or network_start, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It transparently states the request-reply nature ('await its reply'), implying blocking behavior. Yet it omits what happens on timeout, if the script name is unknown, or whether side effects can occur, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no filler. The core action is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, this description is too minimal. It lacks parameter semantics for 'name', timeout behavior, return value structure, and prerequisites, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies the data parameter ('JSON data') and the general notion of an injected script. The required 'name' parameter is unexplained as the script identifier, and timeout_ms is not mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb (send), resource (injected script), and a clear follow-up action (await reply). It differentiates from siblings like inject_script (which injects) and execute_js (which executes arbitrary JS) by targeting a named, already-injected script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: one must first inject a script, then send data to it. However, the description does not explicitly state when to choose this over execute_js or inject_script, nor mention any prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden. It discloses the key behavioral facts: the script is persistent and replays on every navigation. However, it does not mention the run_now default, whether registering an existing name overwrites it, or what the call returns, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence contains the core action, the resource, and the key behavioral condition, with no filler or redundant phrasing. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a flat 3-parameter tool with no output schema, the description covers the main concept but omits the run_now behavior and any guidance about overwriting or re-registration. An agent could infer most of the call shape but would still be guessing about an important parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for the undocumented parameters. It does not mention name, code, or run_now at all. While name and code are inferable from 'script', run_now's semantics and default are entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Register') and resource ('named persistent script') and clearly states the defining behavior ('replays on every navigation'). This distinguishes it from sibling execute_js, which implies one-off execution, so an agent can identify this tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The persistent, replay-on-navigation behavior implicitly tells the agent when to use this tool, but there is no explicit guidance contrasting it with execute_js or send_to_injected. No exclusions or alternative-selection conditions are provided, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses page format (A4), background setting, and the default output location ('data/screenshots'). It does not disclose how the optional save_path parameter affects behavior, whether the file is overwritten, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, tightly worded, and front-loaded with the action. Every element — current page, PDF, A4, backgrounds on, output location — earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-required-parameter tool, the description gives enough to make a basic call and expected the file under data/screenshots. However, the missing parameter semantics and lack of return/overwrite behavior keep it from being complete, especially because there are no annotations or output schema to fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented save_path parameter. It only hints at the default destination and never explains how save_path should be formatted, whether it is a directory or full file path, or whether it overrides the default. This leaves significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save'), a specific resource ('the current page'), and a specific output format ('PDF'), with concrete constraints (A4, backgrounds on). This clearly separates it from sibling tools like screenshot by making the PDF output explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: an agent should call this when a PDF of the current page is needed. However, the description does not explicitly contrast it with alternatives such as screenshot, and it does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses the core behavior and output, but it does not mention side effects such as navigating the active tab away from the current page or potential captcha/network issues. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 13-word sentence with the action and location front-loaded. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is enough for a basic call, but with no annotations and no output schema, it leaves unspecified what exactly 'top results' contains and does not warn about page navigation side effects. The lack of guidance relative to sibling search tools adds a mild completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It hints at 'query' through 'web search' and at 'limit' through 'top results', but it does not explain region or platform, which remain undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Run a web search'), a location ('in the active tab'), and an output ('return the top results'). This makes it easy to distinguish from sibling tools like search_tabs or navigate, even without naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a web search result list is needed and notes the active-tab constraint, but it provides no explicit guidance about when to prefer this over search_tabs or related tools. It lacks exclusions and alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a read-only listing behavior and the scope ('all saved bookmarks'), but it does not mention output format, ordering, pagination, or potential volume. This is minimum viable transparency for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The action and resource are front-loaded, making it immediately scannable and easy to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description provides the essential action and scope, but gaps remain: no mention of what data is returned for each bookmark, no note on sorting or limits, and no context contrasting with bookmark_search. Given the sibling set, a short usage hint would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema is empty with 100% coverage. The baseline for 0 parameters is 4 because there is nothing for the description to explain beyond the schema, and no parameter ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('all saved bookmarks'). It is clearly distinguishable from sibling tools like bookmark_search (which implies querying/filtering) and bookmark_add/delete (which are mutations). The scope 'all' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus bookmark_search or history_search. There are no explicit when-to-use or when-not-to-use conditions, leaving the agent to infer the appropriate choice solely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It usefully discloses that the browser itself keeps running, a key side effect. However, it does not mention whether the connection can be re-established, whether any session state is lost, or what happens if no connection exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The parenthetical adds a meaningful clarification about the browser continuing to run, so every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description supplies the core action and the most important side effect. It is sufficient for invoking the tool correctly, though a brief note about reconnecting via connect_brave would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is effectively complete, so there is nothing for the description to add about parameters. This is the baseline case for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Drop' and the resource 'the connection to the browser,' making the action unambiguous. It does not explicitly name or contrast a sibling tool like connect_brave, but the parenthetical clarifies it is not closing the browser, which adds useful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is only implied: an agent can infer it should use this tool when it wants to end a browser connection. There is no explicit guidance about when not to use it or which sibling alternative to choose for reconnecting.
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 carries the full burden of disclosure. It reveals that secrets are redacted unless redact=false, and highlights the danger and mandatory confirm=true. This is meaningful behavioral context beyond the raw schema, though it does not cover all side effects of arbitrary JS execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and result. Every phrase delivers useful information—return syntax, redaction default, and the danger warning—with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a powerful, potentially destructive tool with 4 parameters, no output schema, and 0% schema coverage, the description gives critical warnings but misses important context. It does not explain how tab_id is used, what the result format looks like, or how errors are surfaced, leaving an agent partially under-informed when invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for code (use return to get a value), redact (secret redaction toggle), and confirm (needs to be true). However, tab_id is completely unaddressed, leaving one parameter semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run JavaScript in the page') and a specific outcome ('return its result'). It is easily distinguishable from most siblings, though it does not explicitly differentiate itself from similar tools like inject_script or send_to_injected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical usage tips: 'Use `return` for a value', redaction behavior, and the confirm requirement. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving selection among sibling execution tools somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the kind of data returned (status, transport, store sizes, live refs, uptime), making clear this is a read-only health check. It does not mention side-effect free behavior or response format, but for a health endpoint the behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact phrase that lists the key output categories with no filler. It is front-loaded with 'Server status,' which immediately signals the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description lists the main return areas sufficiently for an agent to understand what it will get. It could specify whether this returns metrics as a snapshot or continuously, and could include a leading verb, but it is essentially complete for a health-status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides no parameter semantics to clarify. The description is not required to explain parameters, and the baseline of 4 applies because there is nothing missing in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports server health information: 'Server status, connection transport, store sizes, live refs, and uptime.' It is clear what resource this covers, though it lacks an explicit verb like 'check' or 'retrieve.' It is sufficiently distinct from all browser-automation sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for checking server health and uptime, but it does not explicitly state when to use it versus alternatives or when not to use it. Since no sibling tool is a plausible alternative for health checks, the omission is minor, but guidance is still only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses that 'close' is destructive and that 'focus' changes window focus, but it does not describe return formats, side effects of focusing, or whether closing requires confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that lists all supported operations with no filler. Every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is reasonably complete, but missing details like default action behavior, return value shape, and parameter requirements by action leave gaps. The absence of an output schema and annotations raises the burden on the description, which it only partially meets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by mapping action values to list/focus/close and implying window_id identifies the window, but it does not clarify that window_id is required for focus/close or ignored for list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific operations (list, focus, close) on a specific resource (browser windows), making the tool's function immediately clear. It also implicitly distinguishes itself from the sibling 'tabs' tool by explicitly mentioning windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action verbs: use when you need to list, focus, or close browser windows. No explicit exclusions or comparisons to alternatives like 'tabs' are given, so the guidance is adequate but not thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals the core action and the infinite-scroll usage pattern, but does not explain what happens if a selector is invalid, whether scrolling is instant or animated, or whether any output is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and target, then adds a genuinely useful parenthetical hint about infinite scroll. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose is clear and sufficient for a trivial scroll call, but with no output schema, no annotations, and little parameter guidance, the description alone does not fully equip an agent for edge cases or exact behavior. It is adequate but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are completely absent (0% coverage), so the description needs to compensate. It hints at 'element' for selector and 'down' for direction, but does not explain the amount parameter, the direction enum values beyond down, or how selector interacts with the page. The compensation is partial at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('scroll') and identifies the targets clearly: the page or an element. Among the sibling tools, none other offers scrolling, so this tool is immediately distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool and adds a practical note about repeating down-scrolls for infinite scroll. It does not explicitly name alternatives or exclusions, but no sibling provides the same capability, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the full burden of behavioral disclosure. It explicitly reveals the key non-obvious behavior: the tool updates title/tags rather than creating a duplicate when the URL exists. It does not cover details like tag merge semantics, but the most critical behavior is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the main action front-loaded and the conditional update behavior in parentheses. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool, but missing details such as what happens when tags are omitted during an update and whether the tool returns the created/updated bookmark. Without annotations or an output schema, more explicit behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It adds that URL is the uniqueness key and title/tags are the updatable fields, but it does not explain the full semantics of the tags parameter, such as whether tags are replaced or appended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a bookmark and immediately discloses the upsert behavior when the URL already exists. This distinguishes it from sibling tools like bookmark_delete, bookmark_search, and bookmark_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The upsert note implies when the tool is appropriate (adding a new bookmark or updating an existing one), but no explicit guidance is given about alternatives or when not to use it. There is no reference to sibling tools such as bookmark_search or bookmark_list to help route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a meaningful implementation detail ('trusted CDP click with DOM fallback') and explains the supported locator types, but it does not disclose side effects such as navigation, waiting behavior, or failure modes after the click.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single efficient sentence with the action and locator options front-loaded and the implementation note placed at the end. Every phrase adds value, and there is no filler or repetition of schema-visible information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven parameters, no annotations, and no output schema, the description covers the essential invocation path but omits important operating details such as the meaning of scope, precedence among locator options, and whether clicking waits for navigation or page load. It supports basic use well but is incomplete for advanced or edge-case calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps three of the seven parameters to concrete locator modes (selector, by_text, ref) and clarifies through the word 'or' that they are alternatives. However, with 0% schema description coverage, it leaves scope, button, trusted, and double_click unexplained, so it only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Click') and the resource ('an element'), and it specifies three distinct ways to identify the target: selector, visible text, or ref_N from read_page. This is specific and unambiguous, and it distinguishes the tool from siblings like hover, type, and focus_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever an element needs to be clicked and can be located by selector, visible text, or a ref from read_page. It does not explicitly list exclusions or alternatives, but the usage context is strong enough to guide tool selection.
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 carries the disclosure burden. It discloses a key behavioral trait: the tool produces a snapshot with stable ref_N ids that remain usable for later targeting. It implies a read-only, non-destructive operation, though it does not explicitly discuss side effects, performance, or scope 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It leads with the core action and then gives the key use case, which makes it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential contract—the page snapshot contains stable refs for targeting—but does not describe the returned snapshot shape or how filter/max_refs affect the result. With no output schema and no annotations, this leaves gaps for non-default invocations, though the default call is reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not explain filter or max_refs. The reference to click/type targeting only weakly implies the 'interactive' filter, and the agent must infer parameter semantics from names and enum values alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Build an accessibility snapshot of the page') and a distinguishing outcome ('stable ref_N ids for click/type targeting'). This clearly differentiates read_page from siblings like get_page_content, list_elements, and inspect_dom, which focus on content or DOM structure rather than reference-stable accessibility snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for click/type targeting' provides clear context: this tool should be used to obtain refs before performing click or type actions. It does not explicitly name alternative tools or state when not to use it, but the intended usage is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the search scope, fields, and ranking algorithm, but does not describe the output shape, no-match behavior, or case sensitivity. For a read-only search this is acceptable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The scope is front-loaded, and the TF-IDF ranking detail is a compact, valuable addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose and invocation are clear, and the tool is simple with only two parameters. However, there is no output schema, and the description does not explain what a result contains or what happens with no matches, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides the only meaningful semantics for the query parameter: it searches title or URL. The limit parameter is not described, but its name plus the schema's default/min/max constraints make its purpose inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and resource ('all open tabs'), and names the fields searched (title or URL) plus the ranking method (TF-IDF). This makes it easy to distinguish from history_search, bookmark_search, or generic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you need to find an open tab by title or URL. It does not explicitly name alternatives or state when not to use it, but the 'across all open tabs' scope provides adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states both the state-changing action ('stop network capture') and the data-return behavior ('return everything captured so far'), which covers the key side effect an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. It front-loads the main action and immediately clarifies the return behavior, making it easy to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides the essential context: what action occurs and what the agent receives. It is slightly vague about the return format or behavior when no capture is active, but these are minor gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('stop') and resource ('network capture') and clearly states the return behavior. It distinguishes itself from sibling tools like network_start, network_list, and network_request by focusing on stopping and returning captured data, so an agent can select it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: an agent would call this after starting capture with network_start and wanting to retrieve results while ending the capture. However, there is no explicit guidance about when to prefer this over network_list or network_request, nor any mention of prerequisites or alternatives.
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:
Score Badge
Copy to your README.md: