dawg-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each browser_ tool has a distinct action (navigate, click, type, screenshot, etc.) and each scrape_ tool has a distinct purpose (single page, batch, crawl, status). The only potential overlap is between browser_snapshot and browser_take_screenshot, but they serve different use cases (interaction vs visual verification). Overall, tools are clearly differentiated.
Naming Consistency5/5All tools follow a consistent verb_noun pattern: browser_* for browser operations and scrape_* for scraping operations. All use snake_case. No mixing of conventions, making it predictable and easy to understand.
Tool Count4/524 tools is on the higher side but still reasonable for a server that combines browser automation and web scraping. Each tool serves a clear purpose, and the count is justified by the breadth of functionality. Could be reduced slightly, but not overwhelming.
Completeness4/5The browser tools cover most common actions (navigation, clicks, form filling, tabs, screenshots, session management). The scraping tools provide single page, batch, and crawl operations with status checks and cancellation. Missing some advanced browser features (e.g., file upload, iframe handling), but the core workflows are well-covered.
Average 3.5/5 across 24 of 24 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it 'Returns a fresh AI snapshot' after hovering, but provides no information about side effects (e.g., triggering tooltips, focus changes) or required permissions. With no annotations, the agent lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information. The first sentence states the action and the second describes the output. However, it sacrifices necessary detail for brevity.
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, output schema, and parameter descriptions, the description is incomplete. It does not explain how to use the 'element' and 'ref' parameters, nor does it describe the snapshot format or any prerequisites. For a browser interaction tool, this is insufficient.
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?
With 0% schema coverage, the description must explain parameters but fails to do so. It mentions 'element identified by ref' but does not clarify the purpose of the 'element' parameter, leaving ambiguity. The 'session_id' parameter is not mentioned at all.
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 action ('Hover over an element') and the resource ('identified by ref'). It distinguishes from sibling tools like browser_click or browser_type since 'hover' is a unique action. However, it does not explicitly differentiate its use case from other interaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives (e.g., browser_click, browser_get_text). No prerequisites or conditions are mentioned, making it hard for an agent to determine the appropriate context for hovering.
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 mentions 'visible text' but does not define what constitutes visible (e.g., excludes hidden elements) or how the tool handles iframes, dynamic content, or pagination. It also omits session requirements and potential performance implications for large pages.
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 a single concise sentence, front-loading the core action. However, it is too brief to cover essential details, making it under-specified rather than efficiently complete. It could add more information without becoming overly verbose.
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 3 parameters, 0% schema coverage, no output schema, and the complexity of browser operations (requiring session management, state handling, and potential large returns), the description is incomplete. It does not mention session requirements, return format, or error conditions, leaving significant gaps for an agent to understand 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?
The schema description coverage is 0%, and the description only hints at the 'selector' parameter ('optionally scoped to a CSS selector'). It does not explain the 'session_id' parameter (required for context) or the 'format' enum (text vs HTML). This forces the agent to rely solely on the schema names, which may be insufficient for correct invocation.
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 that the tool gets the page's visible text or HTML, and optionally scoped to a CSS selector. This is a specific verb-resource combination that distinguishes it from other browser tools like browser_snapshot (captures screenshot) and browser_evaluate (runs JavaScript). However, it does not explicitly differentiate from potential similar tools that might also return text content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 browser_evaluate for extracting text via JavaScript, or browser_snapshot for visual capture. It does not mention prerequisites (e.g., an active session) or contexts where this tool is preferred or should be avoided.
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 must disclose behavior. It mentions returning a fresh snapshot, which is a behavioral detail. However, it does not mention error handling, loading states, or that the previous page is replaced.
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 very short (one sentence plus a brief result mention), making it concise. However, it could include more structure, such as listing parameters or usage examples.
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, the description is insufficient. It does not cover required parameters, error scenarios, or how it relates to sibling navigation tools. The tool appears to be part of a complex browser suite, and the description is too sparse.
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. It fails to explain any of the three parameters (url format, session_id usage, timeout meaning). This is a critical 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 it navigates to a URL, which distinguishes it from other browser tools like navigate_back/forward and snapshot. However, it does not explicitly differentiate from similar navigation commands like 'browser_tabs' or mention that it sets the active 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?
No guidance on when to use this tool versus alternatives like navigate_back/forward or whether a browser session must be provisioned first. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the return of a snapshot. It does not disclose whether the tool is destructive, requires authentication, or other behavioral traits, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and to the point, with no unnecessary words. However, it is overly brief given the missing details, so it is concise but not optimally structured.
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 covers the core action and result. However, it lacks explanation of the session_id parameter, error conditions, and prerequisites, making it only minimally complete.
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 has one parameter (session_id) with 0% description coverage, and the description does not mention or explain this parameter at all. The description adds no meaning beyond the schema's title 'Session Id'.
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 action 'Go back in history' and the return value 'Returns a fresh AI snapshot'. It is specific and distinguishable from sibling tools like browser_navigate_forward.
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, nor any prerequisites or conditions. It is purely functional with no contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Press' without detailing side effects (e.g., whether it affects focus, fires events, or requires active session). Modifier key example 'Control+a' suggests combination press, but no clarification.
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?
Single sentence with examples; no redundant words. Could be improved by adding a note about parameter details, but current form is 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?
Tool is simple with only 2 parameters and no output schema, so minimal description may suffice, but lacks context on how it interacts with the browser (e.g., active tab, focused element). Somewhat incomplete.
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%; the description does not explain the key parameter's allowed values (e.g., case sensitivity, special key names) or the session_id parameter's purpose. Examples only hint at valid entries.
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?
Clear verb-resource combination: 'Press a keyboard key'. Examples differentiate from sibling tool 'browser_type' which types text strings, and 'browser_click' which clicks mouse buttons.
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 on when to use press_key versus similar tools like browser_type or browser_fill_form. No mention of prerequisites (e.g., element focus) or fallback 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?
The description only states 'release', but does not disclose if the browser is destroyed, connections closed, or if it's irreversible. With no annotations, the description carries the full burden and provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, achieving maximum conciseness.
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 simple tool with one optional parameter and no output schema, the description is still insufficient; it omits prerequisites (e.g., valid session), return value, and side effects.
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 coverage is 0% and the description does not explain the session_id parameter, its purpose, or when it can be null. The parameter is optional and nullable, but no guidance is given.
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 verb 'release' and the resource 'provisioned browser' and the action 'back to the pool', which distinguishes it from sibling tools like browser_provision (create) and browser_list_sessions (list).
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 on when to use this tool, such as after acquiring a session via browser_provision, or not to use if the browser is not provisioned. Lacks context for appropriate use.
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 provided; the description merely says 'Cancel a running crawl/batch job' without detailing effects (e.g., irreversibility, cleanup actions, or error states) beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but lacks necessary context. While concise, it sacrifices clarity on usage and behavior.
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 one-parameter tool with no output schema, the description is minimally adequate but could be improved with more behavioral and usage context to match the tool's action.
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 has no descriptions for parameters (0% coverage). The tool description adds no semantic detail about the required 'job_id' parameter beyond its name and type.
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 action 'Cancel' and the resource 'running crawl/batch job', distinguishing it from sibling tools like scrape_crawl (starting) and scrape_job_status (checking status).
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 on when to use or not use this tool, no alternatives mentioned, and no prerequisites or conditions 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?
The description mentions that the tool 'Returns a fresh AI snapshot', which adds insight beyond the name. However, with no annotations present, it fails to disclose critical behaviors such as whether it requires an active session, what happens if no forward history exists, or side effects on the browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), which is generally good. It front-loads the action. However, it omits necessary details, but for conciseness, it is not wasteful—just incomplete.
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 tool's simplicity and the presence of many sibling browser tools, the description lacks completeness. It does not explain the required precondition (previous back navigation), session handling, or the relationship with other navigation tools, making it insufficient for correct autonomous use.
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 input schema has one parameter (session_id) with no description, and the tool description does not explain its purpose, format, or default behavior. With 0% schema coverage, the description should compensate but does not add any meaning beyond the parameter name.
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 action ('Go forward') and the resource ('history'), making the tool's function immediately obvious. It distinguishes from sibling tools like 'browser_navigate_back' and 'browser_navigate' by specifying forward history movement.
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 on when to use this tool versus alternatives such as 'browser_navigate_back' or 'browser_navigate'. There is no mention of prerequisites (e.g., needing a history entry ahead) or contextual use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose key behaviors such as whether it replaces or appends selections, error handling for invalid values, or any side effects. The description is too minimal.
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 a single short sentence, front-loaded with the key action. However, it is too terse, sacrificing useful detail for brevity. It could be more informative while remaining concise.
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 tool's complexity (browser dropdown selection) and the absence of an output schema and parameter descriptions, the description is incomplete. It fails to mention prerequisites (e.g., page must contain the <select>), behavior on multiple values, or return type.
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?
With 0% schema description coverage, the description must compensate but only mentions 'ref'. It does not explain the 'element' parameter (distinguishing multiple selects), 'values' (expected format), or 'session_id'. Users have to guess parameter details from names 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 clearly states the action ('Select'), the resource ('one or more options in a <select>'), and the identifier ('by `ref`'). It distinguishes itself from sibling tools like browser_click or browser_fill_form by specifying the exact UI element type.
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 for selecting options in dropdowns, but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, which is a gap given the many browser siblings.
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 fully disclose behavior. It mentions that the click uses the latest snapshot and returns a fresh one, but it does not explain error handling (e.g., missing ref), whether the element is scrolled into view, or if there are side effects like page navigation. This leaves significant 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?
The description is extremely concise—two sentences that front-load the action and return value. There is no redundancy or unnecessary detail; every word contributes value.
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 point-and-click tool with no output schema, the description covers the core mechanism and return type. However, it lacks details on optional parameters and error behavior, and does not contextualize the tool within the broader set of browser interaction siblings. It is minimally viable but not thorough.
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 explains `ref` (element identifier from latest snapshot) and `element` (diagnostic label), but provides no information on `session_id`, `double`, or `button`. The agent cannot infer the purpose of these optional parameters, limiting usability.
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 that the tool clicks an element identified by `ref` from the latest snapshot, and returns a fresh snapshot. This is a specific verb-resource pair that distinguishes it from sibling browser interaction tools like hover or 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 guidance is given on when to use this tool versus alternatives (e.g., browser_hover, browser_press_key). There is no mention of prerequisites, such as needing a snapshot first, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It implies read-only operation but does not state that explicitly, nor does it cover possible outcomes like empty result sets, pagination, or side effects.
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, concise sentence that conveys the essential function without extraneous words. It is well-structured and front-loaded.
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 the tool has no parameters and no output schema, the description tells the basic function but leaves out details about the output format, what constitutes 'active', and potential edge cases. It is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so the description does not need to add parameter information. Baseline score of 4 is appropriate as there is no gap to compensate for.
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 action (list) and resource (active provisioned browser sessions), distinguishing it from siblings like browser_provision and browser_release. It lacks detail on what information is returned, but the core purpose is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 browser_provision for creating sessions or browser_release for releasing them. No usage context or exclusions are mentioned.
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?
Discloses behavior for clear and submit flags, and mentions return of an AI snapshot. However, since no annotations are provided, the description must cover all behavioral traits. It does not mention failure modes or side effects (e.g., page navigation after submit), limiting transparency.
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 very concise with three short, front-loaded sentences. Each sentence adds value without redundancy, though it could be slightly more structured (e.g., listing parameters).
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 6 parameters (3 required) and no output schema, the description leaves significant gaps: the 'element' parameter is unexplained, 'session_id' usage is unclear, and there is no mention of error handling or page state after typing. A more complete description is needed for reliable tool selection.
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?
With 0% schema description coverage, the description must compensate. It explains ref, clear, and submit, but omits the required 'element' parameter and optional 'session_id'. 'text' is implied but not explicitly described, leaving ambiguity.
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 explicitly states 'Type text into the field identified by ref', specifying a clear verb and resource. It distinguishes from sibling tools like browser_click or browser_fill_form by focusing on single-field text input.
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 on when to use this tool versus alternatives such as browser_fill_form for multiple fields or browser_press_key for keystrokes. The description lacks context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions async behavior (returns immediately with job_id) but lacks details on side effects, permissions, limits, or cancellability. It does not describe what happens to the URLs or error handling.
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 extremely concise with two sentences. It front-loads the purpose and action, with no unnecessary words.
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 5 parameters and async behavior, the description is too minimal. It omits parameter explanations, output details (job_id type), error handling, and how batch differs from crawl. Incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It does not explain any parameter: format options, concurrency meaning, main_content, timeout_ms. Only 'many URLs' vaguely references the urls parameter.
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 verb 'Start', the resource 'batch scrape', and the scope 'over many URLs'. It distinguishes from siblings like scrape_page (single page) and scrape_crawl (crawl). The return of a job_id and polling instruction are also clear.
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 explains the immediate return of job_id and directs the user to poll with scrape_job_status. It implies usage for batch jobs, but does not explicitly say when not to use it or compare to 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 are provided, so the description must disclose behavior. It mentions async return and polling, but omits details on resource consumption, cancellation, error handling, or whether the tool is non-destructive. Minimal but acceptable for a crawl initiation.
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 concise at 3 sentences, front-loaded with the core action. It could be slightly more structured (e.g., listing key parameters) but avoids fluff.
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 9 parameters, no output schema, and no annotations, the description is incomplete. It doesn't cover return format (only that it returns job_id), error cases, or meaningful parameter values. An agent would need external knowledge to use the tool fully.
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 coverage is 0% (no parameter descriptions in input schema). The description only explains include_patterns and exclude_patterns, leaving 7 other parameters (format, max_depth, max_pages, concurrency, main_content, timeout_ms) undocumented. This forces the agent to infer their meaning from names 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 clearly states it starts a crawl job from a seed URL and immediately returns a job_id, distinguishing it from sibling tools like scrape_page (single page) and scrape_batch (batch of pages) by highlighting its async nature and polling mechanism.
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 provides clear usage context: when to start a crawl job, how to poll progress via scrape_job_status, and hints on using include/exclude patterns. However, it lacks explicit comparison to alternatives like scrape_batch for batch crawling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that the function's return value is JSON-serializable, but does not specify whether the function runs synchronously, has side effects, or requires a loaded page. Safety implications are absent.
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 extremely concise—two sentences with an inline example—providing essential information without wasted words. It is front-loaded with the core purpose and parameter details.
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 covers core functionality well (evaluation, return value, parameter examples), but omits explanation for `session_id` and lacks broader behavioral context (e.g., execution environment, error handling). Given the complexity of a JS execution tool, it is adequate but not fully comprehensive.
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 coverage is 0%, so the description compensates by explaining the `function` parameter as a JS function expression with examples, and the `ref` parameter for element selection. However, the `session_id` parameter is left entirely undocumented, leaving a 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 clearly states the tool evaluates a JavaScript function and returns a JSON-serializable result, with specific examples of function expressions. It distinguishes from sibling browser action tools (e.g., browser_click, browser_navigate) by focusing on evaluation rather than interaction.
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 provides context for when to use the `ref` parameter (receiving an element), but gives no explicit guidance on when to use this tool versus alternatives like `browser_get_text` or `browser_wait_for`. Usage context is implied but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that 'list' returns the tab list and that 'new/select/close' return a fresh AI snapshot of the active tab. This provides useful behavioral context beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences front-loading the purpose and key behaviors. Every sentence adds value.
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 the multi-action nature and 4 parameters with no annotations, the description covers basic actions and outputs but lacks details on session_id, error cases, or prerequisites.
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?
With 0% schema description coverage, the description should compensate but only mentions 'optional url' for new and 'select by index'. It does not explain session_id or other parameter roles.
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 manages browser tabs with actions like list, open, close, and select by index. This distinguishes it from sibling tools like browser_navigate or browser_click.
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 for tab management but does not explicitly state when to use this tool versus alternatives, nor does it mention 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 carries full burden. It usefully notes 'Returns a fresh AI snapshot' but omits details like whether the form is submitted, validation behavior, or session requirements. The behavioral disclosure is partial.
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?
Excellent conciseness: two sentences, front-loaded with the core purpose, followed by a structured definition of the main parameter. No wasted words.
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 output schema, no annotations, and two parameters, the description provides the essential purpose and fields format but lacks context on session_id, prerequisites, and when to use this vs. sibling tools. It meets minimum completeness but has clear gaps.
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 description must compensate. It explains the fields parameter format with a specific structure (`{"element": desc, "ref": ref, "value": value}`), adding meaning beyond the schema. However, the session_id parameter is not explained.
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's action ('Fill multiple form fields') and its batch nature ('in one call'). It distinguishes itself from siblings like browser_type (single field) and browser_click (clicking) by specifying multiple fields at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for efficiency ('in one call') but does not explicitly state when to prefer this over browser_type or any prerequisites. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It accurately describes the tool as a read-only snapshot (non-destructive) returning an ARIA tree. It does not disclose prerequisites (e.g., existing session) or error conditions, but covers the core behavioral trait of returning structural data for interaction.
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 extremely concise: two sentences that front-load the primary purpose and immediately explain how the output is used. Every word serves a purpose, with no redundancy or fluff.
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?
Given the tool's low complexity (one optional parameter, no output schema), the description adequately explains the return value and how to use it. It falls slightly short by not covering session_id behavior or potential errors, but overall provides sufficient context 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the description does not mention the single optional parameter session_id, thus adding no meaning beyond the schema. The agent is left to infer its purpose from the parameter name alone, which is a significant 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 clearly states the tool captures an AI accessibility snapshot of the active page, returning an ARIA tree with ref markers. This distinctively differentiates it from sibling tools like browser_take_screenshot (visual) and browser_click (action), making its purpose specific 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is the primary way to 'see' the page for interaction, and that refs are used with browser_click/browser_type, providing clear context. However, it does not explicitly exclude cases where browser_take_screenshot or scrape_page might be preferred, lacking when-not 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 are provided, so the description carries full burden. It states the tool waits for specified conditions and returns a fresh AI snapshot. However, it does not disclose timeout behavior or what happens if no condition is provided or if the condition never occurs, which are relevant behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 sentences) and front-loaded with the main purpose. Every sentence adds value: the first states general purpose, the second gives usage rules, and the third states return value. No wasted words.
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?
Given the tool has 4 parameters (all optional) and no output schema, the description explains the key parameters and usage constraint. It mentions the return type (fresh AI snapshot). It lacks details on timeout or error behavior, but for a simple wait action, this is largely sufficient.
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 must compensate. It explains that `text` means wait for text to appear, `text_gone` for it to disappear, and `time_ms` for a fixed time. It also clarifies only one should be provided. The `session_id` parameter is not explained but is likely common across tools. This provides significant added meaning beyond the schema.
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 waits for one of three conditions: text to appear, text to disappear, or a fixed time. This is a specific verb+resource combination that distinguishes it from sibling browser actions like click or navigate.
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 explicitly says 'Provide exactly one of `text`, `text_gone`, or `time_ms`.' This gives clear usage guidance. It does not mention when not to use the tool, but the instruction on mutual exclusivity is strong.
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 full burden. It discloses the return values (minute/token consumption, limits, active plan) but does not mention potential caching, error states, or whether the data is instantaneous.
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?
Two sentences, each serving a purpose. The purpose is stated first, followed by the return value explanation. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description completely covers the return values and the intended use case (quota reasoning). No gaps.
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 no parameters, so schema coverage is 100%. The description adds value by explaining the output structure (consumption, limits, plan), which is not in the schema. Baseline 4 is appropriate for zero parameters.
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 'Get the current account usage and tariff plan', providing a specific verb and resource. It distinguishes itself from the sibling tools, which are all browser or scraping actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using the tool to check remaining quota before running expensive operations, giving clear context. It does not explicitly list when not to use or mention alternatives, but the guidance is sufficient for this simple tool.
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 carries full burden. It explains the action and return values, but does not disclose potential costs, resource limits, or side effects of provisioning a browser.
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?
Concise, well-structured with Args section; every sentence is necessary and front-loaded with the main action.
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?
Covers purpose, parameters, and return values. Does not specify browser lifecycle or error scenarios, but for a provisioning tool this is adequate given sibling tools handle release.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning for both parameters—proxy URL format and geo formats (city slug or coordinates) with examples.
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?
'Provision a remote stealth Chromium and connect to it' uses a specific verb and resource, and clearly distinguishes from sibling browser tools that operate on an existing session.
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?
Explicitly states that the returned session_id should be passed to other browser_* tools, implying this is used first. However, no explicit when-not-to-use or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: it returns status and pages, the wait parameter blocks until completion, and wait_timeout limits waiting. However, it does not cover error cases (e.g., invalid job_id) or confirm idempotency. Overall, it provides adequate transparency for a status-check 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 very concise: a single sentence for purpose followed by a clean args list. No unnecessary words. Front-loaded with the main action. Structure supports quick scanning.
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?
The tool has low complexity (3 parameters, no output schema). The description covers purpose, parameters, and blocking behavior. It does not detail output format or error handling, but these are minor omissions. Overall, it is sufficiently complete 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so thoroughly: job_id is linked to previous crawl/batch jobs, wait blocks on 'running', wait_timeout sets max wait. This adds significant meaning beyond the schema's type and default values.
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 retrieves status and completed pages of a crawl/batch job. The verb 'Get' and resource 'status (and any completed pages) of a crawl/batch job' are specific. It distinguishes from siblings like scrape_crawl or scrape_batch, which initiate jobs, and scrape_cancel_job, which cancels.
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 explains when to use the tool (after starting a crawl/batch job) and describes the parameters including their roles. It does not explicitly state alternatives or when not to use, but the context is clear enough for an agent to infer appropriate usage.
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 full burden. It explains extraction behavior, format options, content stripping, link inclusion, render modes, and timeout. It does not cover side effects or error conditions, but the core behavior is well disclosed.
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 multi-line docstring with an Args block. It is well-structured and front-loaded with the purpose. While it is somewhat verbose for 6 params, each sentence is necessary, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers all aspects: what the tool does, each parameter's purpose and default, and return type. It is complete for an agent to select and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully explains all 6 parameters: url, format with default, main_content, include_links, render with options (auto/http/browser), and timeout_ms. Each parameter's role is clear, adding meaning beyond the schema.
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 action ('scrape a single URL'), the resource ('URL'), and the output ('return extracted content'). It also notes 'no browser session needed', distinguishing it from browser-based tools like browser_navigate.
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 (single page, no browser) and provides render options ('http' cheapest, 'browser' full render) to guide choice. However, it does not explicitly state when not to use or point to specific sibling 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 carries the full burden. It discloses that the tool takes a screenshot, can capture a single element or full page, but does not mention return format (e.g., base64) or potential side effects. Adequate but could be more detailed.
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 three sentences, each earning its place: first defines purpose, second gives usage guidance, third explains parameters. Front-loaded and no redundant text.
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?
The tool is simple with few parameters. The description covers purpose and parameter usage, but lacks explanation of the output (e.g., screenshot data format). Given no output schema, this is a minor 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?
Schema description coverage is 0%, so the description must compensate. It explains how to use 'ref' for single element and 'full_page' for scrollable page, but does not mention 'session_id'. The description adds significant value for two key parameters.
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 states the tool takes a PNG screenshot for visual verification, distinguishing it from browser_snapshot which is for acting on elements. The verb 'take' and resource 'screenshot' are specific, and sibling differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs browser_snapshot: 'To act on elements use browser_snapshot (not this); screenshots are for visually confirming what the page looks like.' It also explains parameters for single element or full 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:
Score Badge
Copy to your README.md:
shields.io Endpoint
For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/dawgswarm/dawg-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server