Public Browser

Server Quality Checklist

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

Latest release: v2.10.0
Disambiguation5/5
Every tool has a distinct, well-defined purpose. Overlapping tools like view_page vs capture_image are clearly delineated by use cases and cost guidance. Even generic tools like evaluate and set_page_data are scoped to specific legitimate uses, avoiding ambiguity.
Naming Consistency5/5
All tool names follow a consistent lower_snake_case verb_noun pattern (e.g., virtual_desk, capture_image, network_monitor). Verbs are clear and predictable, with no mixed conventions or vague synonyms.
Tool Count4/5
25 tools is on the higher end, but each tool addresses a distinct browser automation capability (navigation, interaction, monitoring, data injection). The set is comprehensive without being bloated, as most tools have narrow, non-overlapping roles.
Completeness5/5
The tool surface covers the full browser automation lifecycle: navigation, page inspection, interaction, tab management, waiting, observing, dialogs, file handling, network/console monitoring, downloads, and advanced scripting. No critical gaps are apparent for the stated purpose.
Average 4.5/5 across 23 of 25 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions features like variables, conditions, error strategies, and suspend/resume but lacks details on execution order, side effects, or error handling specifics beyond naming abort/continue/capture_image.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and enumerate features with no wasted words. Ideal structure for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description omits what the tool returns (e.g., plan ID, results). For a complex orchestration tool, this is a significant gap. Also lacks details on error strategies and variable scoping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so the description adds minimal value beyond high-level feature listing. It groups concepts but doesn't elaborate on parameter usage beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes a sequential plan of tool steps server-side, listing key features. The name 'run_plan' is self-explanatory, and it distinguishes itself from single-step sibling tools like click, type, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-step orchestration versus single-step siblings but does not explicitly state when not to use or provide alternative tools for simpler tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the optional clear buffer action (a behavioral trait), but does not disclose other behaviors such as performance impact, rate limits, or what happens to logs after reading. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main purpose and then listing parameters concisely. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the tool returns (e.g., an array of log objects with message, level, timestamp). It does not, which is a gap. Additionally, it does not relate to siblings like batched actions or session management.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds clarity by specifying the enum values for level (info/warning/error/debug), explaining pattern as regex matching, and noting that clear is optional. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves browser console logs and provides specific filtering options (level, regex) and an optional clear action. It is distinct from sibling tools like network_monitor or observe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you need to retrieve console logs) and what parameters are available, but does not explicitly state when not to use or compare to alternatives. It provides sufficient context for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool can view/set defaults and apply auto-promote suggestions, and that using profile launches Chrome with a named profile. However, it does not detail side effects, persistence, or safety aspects (e.g., whether changes affect ongoing interactions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first covers the overall purpose, the second explains the two operational modes, and the third provides a critical usage instruction. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description explains the main functionality and modes. It notes that viewing returns current defaults and suggestions, but does not specify the return format or how changes affect subsequent session actions. Overall, it is fairly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds extra value beyond the schema by specifying the timing for the profile parameter ('BEFORE any browser interaction'). This enhances the semantic understanding beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool can view or set session defaults for recurring parameters like tab and timeout. It distinguishes between viewing current defaults and applying auto-promote suggestions. This is distinct from sibling tools which are mostly browser interaction or evaluation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to view or set defaults, and with the autoPromote parameter to apply suggestions. It also gives a crucial usage tip for the profile parameter (use before browser interaction). However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses scope sharing, IIFE wrapping for top-level declarations, and that if/else may return undefined—suggesting ternary or explicit return. This is valuable beyond the input schema, though it could mention sandboxing or security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points and clear sections, front-loaded with the main purpose. Every sentence adds value, though it is slightly verbose. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite thorough coverage of usage and behavior, the description omits information about the return value of the executed JavaScript. Since there is no output schema, this is a significant gap for an agent to understand what the tool returns, especially for promise handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (expression and await_promise are fully described in the schema). Description adds minimal additional meaning beyond the schema, primarily discussing execution behavior rather than parameter details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Execute JavaScript in the browser page context' with a specific verb and resource. It distinguishes good uses (computation, style mutations, shadow-root traversal) from bad uses with explicit alternatives (view_page, scroll, fill_form), differentiating it from 24 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists good uses, bad uses, and alternatives for each bad case (e.g., automatic recovery after failure → view_page; scrolling → scroll via run_plan; element discovery → view_page or fill_form). Provides clear when-to-use and 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions CDP and captures all page-initiated requests. It explains stop action clears data, but does not disclose potential side effects, permissions, or limitations beyond what is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, efficient use of words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description implies return format of 'get' action. Workflow hints are sufficient for a simple tool. Could mention return structure but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions. Description adds workflow context and explains the 'stop' action behavior, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool monitors network requests via CDP, distinguishing it from evaluate-based interceptors. Verb+resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow (start, trigger action, get) and advises using instead of evaluate-based fetch interceptors. Lacks explicit when-not-to-use scenarios but provides clear context.
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 reveals an important behavior: it can optionally focus an element via ref or selector before pressing the key. This is clear and sufficient for a simple keyboard press tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering the action, optional focus, and typical uses. Every word contributes meaning, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers all necessary aspects: the key press action, optional focusing, and example keys/shortcuts. It could mention that pressing a key may trigger page events, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with detailed explanations for each parameter. The description adds only the phrase about optional focus, which is already present in the schema for 'ref' and 'selector'. Thus, it provides minimal additional value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (press a key) and the resource (keyboard). It distinguishes from siblings like 'click' and 'type' by specifying keys, shortcuts, and optional element focus. Examples like 'Enter', 'Escape', and 'Ctrl+K' make the purpose immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives specific use cases ('Enter, Escape, Tab, arrows, shortcuts (Ctrl+K)'), which guides the agent on when to use this tool. It implies the tool is for individual key presses or shortcuts, not for typing text (use 'type') or clicking (use 'click'), but does not explicitly state exclusions or 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?
No annotations provided, so description must cover behavior. It mentions sequential execution and batch nature but lacks details on return format, error behavior, or auth needs. Schema covers timeouts and continue_on_error partially. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with essential info. No unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes purpose and usage well, but lacks output schema or explanation of return results. For a batch tool, missing output behavior is a gap. Parameters are well-documented, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context like 'sequential' and 'controlled batch' beyond schema. Slight extra value beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it visits multiple URLs sequentially and evaluates JavaScript expressions. Distinguishes from siblings like view_page/run_plan by noting batch use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (controlled batch checks) and when not to (normal page reading, clicking, form work). Provides alternative tools (view_page, run_plan) for different scenarios.
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?
Discloses the exact event sequence (mousePressed → interpolated mouseMoved → mouseReleased) and parameter group constraints (from_ref/from_selector OR from_x+from_y). No annotations exist, so description carries full burden, and it does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with mechanism and use cases; each sentence adds information. Slightly dense but not overly verbose. Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For 9 parameters, no output schema, and no annotations, the description is quite thorough. Explains event mechanism, parameter groups, and limitations. Minor gap: no mention of return value or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds value by explaining the two coordinate/selector groups and clarifying the 'steps' default and minimum. This context helps understanding beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Drag', 'mouse events') and lists concrete use cases (slider thumbs, resize handles, text selection), clearly distinguishing from HTML5 Drag&Drop API. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use (CSS-driven drag) and explicitly when NOT to use (HTML5 Drag&Drop). Could mention alternative tool for HTML5 Drag&Drop, but the exclusion is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It explains that the tool uses CDP Page.javascriptDialogOpening and works even when dialog blocks JS, providing good behavioral context for a setup tool. No contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of three short sentences, each providing essential information: purpose, usage timing, and technical advantage. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers purpose, prerequisites, and mechanism. It is complete given the tool's simplicity and the richness of the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters (action enum with explanations, text usage). The description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure browser dialog handling (alerts, confirms, prompts).' It distinguishes itself from sibling tool 'evaluate' by explicitly stating it replaces evaluate-based workarounds and works even when JS is blocked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Pre-configure BEFORE triggering actions that may show dialogs.' It also mentions replacing evaluate-based workarounds, implying when not to use evaluate. However, it does not exhaustively list all alternatives for every scenario.
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 fully discloses key behaviors: observer is set up before click_first, duration and until are mutually exclusive, polling interval fallback, and timeout limit. It does not mention any destructive side effects, but that's expected for a read-only watch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At ~100 words, the description is efficient and front-loaded with purpose. It could be slightly more structured with bullet points, but it avoids fluff and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, important timing/interactions, no output schema), the description covers the major points: modes, mutual exclusions, click_first timing, then_click usage. It lacks explicit return type description but mentions 'return all text/attribute changes'. Overall, it is sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, but the tool description adds significant context: explains the two modes (collect/until), provides examples of use cases, and clarifies parameter interactions (e.g., then_click only works with until). This adds value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool watches an element for changes, explicitly distinguishing it from writing custom MutationObserver/setInterval code in evaluate. It defines two modes and uses specific verbs like 'watch', 'collect', and 'wait for'. This differentiates it from sibling tools like evaluate and wait_for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (instead of writing observe logic in evaluate) and explains the two modes. However, it does not explicitly mention when not to use it or compare to other observation tools like wait_for, leaving some ambiguity.
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. It discloses that the tool returns position and content-growth tracking, and that it handles settle timing automatically. It does not mention potential side effects or error conditions, but the key behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a critical warning, front-loaded with the core action. Every sentence adds value: what it does, return info, warning, usage pattern. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters, no output schema, and no annotations, the description covers the core behavior, return values, and parameter relationships reasonably well. It could mention error handling or edge cases, but it is sufficiently complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the relationship between ref/selector and container/direction/amount, noting defaults (direction: down, amount: 500), and clarifying that amount is only used with direction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls the page, a container, or an element into view, using specific verbs and resources. It distinguishes itself from sibling tools like evaluate by explicitly warning against using window.scrollTo/scrollBy and explaining the automatic position tracking and settle timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use container_ref/container_selector with direction for scrolling inside a container, and advises against using evaluate for scrolling. However, it does not fully cover all alternative scenarios or prerequisites for each parameter combination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description fully carries the burden. Discloses inability to drive click/type or read text, and provides size/format constraints. Clearly communicates what the tool cannot do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with key factual details. One minor redundancy: 'Do NOT call this to see what is on the page — call view_page instead' could be slightly tighter, but overall no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple screenshot tool with no output schema. Provides size limits and use cases. Missing details on return format or error handling, but not critical given its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds no further semantics to parameters (full_page, som). Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('capture') + resource ('image') with technical details (WebP, max 800px, <100KB). Distinctly contrasts with sibling 'view_page' by stating its limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns against using for general page visibility, recommends 'view_page' as cheaper alternative (10-30x). Lists three narrow valid use cases and advises 'use view_page' when unsure.
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 behavioral burden. It discloses that downloads happen automatically, that the tool waits for downloads (status) or returns immediately (list), and that it does not trigger downloads—preventing a common misuse. It does not describe the return format or side effects, but for a simple read-only check tool, the essential behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It uses a clean structure: a first sentence stating the function, a key clarification about not triggering downloads, and bulleted usage examples. While it could be slightly tighter (the second sentence could be merged), it is well-organized and each sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters, no required params, no output schema, and no annotations, the description provides sufficient context. It covers the main use cases, explicitly mentions the session scope, explains the waiting behavior, and distinguishes between status and list actions. Nothing an agent needs to call it correctly is missing; the only minor gap is lack of a description of the return value format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds value by demonstrating usage patterns: the default download() call and the download({ action: "list" }) call, and by clarifying the behavior of the 'action' parameter beyond the enum values (e.g., list never waits). This goes slightly beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement: 'Check status of file downloads or list all downloaded files in this session.' This identifies a specific verb (check/list) and resource (downloads) and immediately clarifies the scope. It also distinguishes itself by stating it does NOT trigger downloads, which sets it apart from any potential sibling that might initiate downloads. This is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when NOT to use it ('you do NOT need to call this tool to trigger downloads') and when to use it: waiting for a large download or listing downloaded files. It provides concrete call patterns (download() and download({ action: "list" })) and even hints at polling use with 'list' returning immediately. This fully equips the agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool types text, can clear fields, uses ref or selector, and handles stale-ref errors. It warns about bypassing framework listeners if using evaluate, which is a behavioral trait. However, it does not mention any permissions, rate limits, or confirm whether the action is destructive (though typing is generally non-destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with information but remains efficient at 4 sentences. It is front-loaded with the core purpose, then expands with usage guidelines and error recovery. While slightly long, every sentence earns its place, making it useful without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, none nested, no output schema), the description covers the main aspects: behavior, parameter usage, alternatives, and error handling. It lacks explicit mention of return values, but that is somewhat inferable. The guidance on stale-ref and evaluate are valuable additions that enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, baseline is 3. The description adds value by explaining the relationship between ref and selector ('preferred over selector') and the clear parameter's purpose. It clarifies that ref is from view_page and selector is a CSS fallback, which goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Type text into an input field identified by ref or CSS selector.' It distinguishes from siblings like fill_form and press_key by specifying when to prefer them, making the purpose and differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'For multiple fields in the same form, prefer fill_form' and 'For special keys... use press_key instead.' It also includes error recovery instructions for stale-ref errors and warns against using evaluate as a default, covering when-not-to-use scenarios comprehensively.
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 effectively conveys the tool's read-only nature and output contents. It could mention error handling (e.g., if ref is invalid), but the core behavioral traits are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant words. First sentence states output, second gives precise usage guidance—maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, output types, and usage boundaries. It doesn't detail subtree depth or error responses, but the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'ref' is explained in schema; description adds value by linking ref to view_page's refs, aiding cross-tool consistency. Schema coverage is 100%, elevating baseline from 3 to a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides structured layout data (bounding boxes, computed styles, paint order, colors) and distinguishes from siblings view_page and capture_image, making the purpose explicit and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Openly states when to use ('spatial questions view_page cannot answer') and when not to ('for element discovery or text: use view_page; for visual verification: use capture_image'), providing explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It states the upload action and the required file paths, but does not mention whether the file is immediately selected or if form submission is needed. However, the core behavior is clear and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, each serving a distinct purpose. The first states the main action and required inputs; the second provides guidance on parameter choice. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a straightforward use case, the description covers the essential behavioral details and parameter usage. It could mention the lack of automatic form submission, but overall it is adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the ref vs. selector distinction beyond the schema's descriptions, clarifying when each is appropriate. This elevates the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Upload'), resource ('file(s) to a file input element'), and the two identification methods (ref or CSS selector). It distinguishes this tool from siblings like 'download' or 'capture_image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use 'ref' (visible input in view_page) vs 'selector' (hidden file inputs, as in many React/Vue apps). This provides clear context and alternatives, making it easy for the agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It discloses that refs become invalid after switching and advises against using evaluate as a shortcut. However, it does not mention potential side effects like closing a tab's resources or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a warning), front-loaded with purpose, then usage guidelines, then important behavioral notes. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers purpose, usage, and cross-tab behavior. It mentions sibling tool 'navigate' for differentiation. It does not explicitly state the default for close action (active tab), though the schema does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with descriptions (100% coverage). The description adds useful context: tab IDs come from virtual_desk, and actions have defaults. This adds value beyond the schema but does not introduce new parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the three actions (open, switch, close) and the specific resource (tabs). It distinguishes from the sibling tool 'navigate' by advising preference for 'open' when not wanting to affect the user's active tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: prefer 'open' over 'navigate' to avoid touching the active tab. It also instructs to call view_page after switching to get fresh refs, and warns against reusing old refs via evaluate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly explains the wait behavior, the effect of assert:true (single check, fail, default timeout becomes 0), the failure code _meta.code = 'assertion_failed', and even notes that text matching is case-sensitive and uses document.body.innerText. This is thorough and leaves little ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and packs in the most important usage notes (condition preference and assert behavior) without filler. Every clause earns its place; it is appropriately sized for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the key operational details: conditions, timeouts, assert failure behavior, and text matching semantics. It doesn't explicitly state what the tool returns on success, but for a wait tool that is typically a boolean or void, and the absence is minor. The description is sufficient for an agent to call it correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description enriches the schema by adding practical guidance: it explains that text is case-sensitive and matches visible innerText, and it recommends condition:'text' over JS expressions for page-text checks. This goes beyond the schema's bare descriptions and adds decision-making value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Wait for') and resource ('a condition') and enumerates the distinct condition types (element visibility, page text, URL, network idle, JS expression). It is unambiguous and provides enough specificity that an agent can understand the tool's role without needing to inspect siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers concrete usage guidance: it recommends preferring condition:'text' over a JS expression for checking page text, and explicitly explains when to use assert:true ('check once and fail instead of waiting'). While it doesn't spell out when to avoid this tool in favor of an alternative, the preference and assert instructions give clear context for choosing among the tool's own modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavioral traits: element refs become stale after reload, waits for settle, overwrites active tab, and first call auto-redirects to virtual_desk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense in a single paragraph, front-loading the main purpose and covering key warnings. While concise, it could benefit from bullet points for improved readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers actions, side effects, and usage warnings well. Lacks mention of return value (e.g., success/error) since no output schema, but for a navigation tool the behavioral completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context: explains the url parameter's role for goto, enumerates and clarifies action enum values with side effects (stale refs on reload), and describes settle_ms as extra wait time.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'navigate' and resource 'ACTIVE tab', enumerates specific actions (goto, back, reload) with examples, and implicitly distinguishes from sibling tools like 'switch_tab'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about overwriting the active tab, instructs to call virtual_desk first, and notes the auto-redirect on first call, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that data is 'cached' and lists specific fields (URL, title, ready, errors). This implies read-only behavior and provides key behavioral context beyond the empty schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only. First sentence defines purpose and outputs. Second sentence provides sibling differentiation. No wasted words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values (URL, title, ready, errors). Covers essential aspects for a zero-parameter tool: what it returns, when to use, and alternative tools. Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%). Baseline score 4 applies; description adds no parameter info, which is appropriate given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides cached URL, title, ready status, and errors for sanity checks. Uses specific verb-resource combination and distinguishes from siblings by referencing virtual_desk and view_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (mid-workflow sanity checks like 'did my click navigate?') and when not to use (tab discovery via virtual_desk, page content via view_page).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context: it is 'Cheap, call liberally' implying low cost and safe to call frequently. It implies a read-only listing operation without stating it explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, front-loaded with purpose, each sentence adds essential value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers purpose, usage timing, and behavior. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description correctly adds no parameter info beyond the empty schema. Baseline 4 applies as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all tabs with IDs, URLs, and state, using a specific verb 'Lists'. It distinguishes itself as the 'PRIMARY orientation tool' from siblings by explicitly recommending it be called first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance provided: 'call first in every new session, after reconnect, or when unsure.' Also advises using returned IDs to avoid opening duplicates, giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses key behaviors: partial errors do not abort, each field reports its own status, supports multiple input types, and prefers ref over selector. Could be improved by mentioning what happens after filling (e.g., form submission), but that's not critical for a fill action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-structured: opens with the core purpose, then specifies how to use parameters, lists supported control types, gives usage guidance and error recovery steps. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that fills forms with one call, the description covers all necessary aspects: input specification, behavior on partial errors, retry strategy, and warnings against using evaluate. Even without output schema, the agent has enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds significant value: explains that each field requires ref or selector plus value, clarifies value types for different controls, and recommends ref as preferred. Also notes minItems constraint implicitly. This goes beyond the schema's descriptive properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('fill a complete form'), the resource ('form'), and positions itself as the preferred method for forms with 2+ fields. Distinguishes itself from siblings like 'type' and 'evaluate' by explicitly saying to use it instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use (forms with 2+ fields) and when not to (avoid multiple type calls or evaluate). Provides clear alternative actions for error recovery: call view_page and retry failing fields, and warns against using evaluate directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses chunking, CDP sequential order, race condition, encoding defaults, chunkSize cap, and post-call state (__complete flag).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but every sentence provides value; front-loaded with purpose and constraints. Minor redundancy could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, parameters, behavior, and post-call state without output schema. Complete for a complex chunking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context for each parameter: encoding defaults, chunkSize limit, source options meaning, and key format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a large payload (>1 MB) to window.__pb_data[key] via server-side chunking, distinguishing it from siblings like evaluate and file_upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Use when' scenarios (big base64 images, stubbing fetch responses, feeding binary data) and 'Do NOT use for' situations (small payloads, file_upload), plus concurrency warning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: returns text and element refs, cost comparison to capture_image (10-30x cheaper), collapsed container display format, depth controlling indentation not visibility, and automatic downsampling based on max_tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is well-structured and front-loaded. Every sentence provides value. It is slightly long but necessary given the complexity of parameters and usage scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four optional parameters, no output schema, and multiple sibling tools, the description is remarkably complete. It explains return type, usage contexts, filter differences, cost, and expansion of collapsed containers. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant context beyond the schema: depth controls indentation not visibility, filter modes explained, ref for subtree, and max_tokens for downsampling. This helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'The way to see what is on the page.' It specifies when to use it (after navigate/click/switch_tab, not capture_image) and what it returns (text content + stable element refs). It effectively distinguishes from sibling tools like capture_image, click, and navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to call the tool (after navigation actions, not capture_image) and how to use different filters ('interactive' for actionable elements, 'all' for paragraphs/table cells). Also explains expanding collapsed containers and mentions cost efficiency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it dispatches real CDP mouse events, reports new tabs automatically, includes DOM diff in response, and explains error recovery. No annotations so description carries full burden, and it does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive; every sentence adds value. Front-loaded with main purpose, then behavioral details, then recovery guidance. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: parameters, usage modes, response contents (DOM diff, new tab detection), error recovery, and anti-patterns. Complete for a click tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter has a clear description in the schema (100% coverage), and the description adds extra context: ref vs selector priority, text targeting without view_page, x+y for canvas, and wait_for_diff behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (click) and resources (element by ref, CSS selector, or coordinates). Distinguishes from siblings by specifying use cases for different target types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use coordinates for canvas, recover from stale ref by calling view_page, avoid using evaluate click as default recovery. Also highlights when to use text-based targeting without prior view_page.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Silbercue/public-browser'

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