periscope-mcp
Server Quality Checklist
Latest release: v0.10.4
- Disambiguation4/5
Most tools have distinct purposes, but there is slight overlap between fill_form and auto_fill_form, and between find_element and get_page_elements. However, descriptions clarify differences, so overall disambiguation is good.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern with underscores, no mixing of conventions. Even longer names like test_keyboard_navigation are consistent.
Tool Count2/566 tools is very high for a server. While each tool serves a purpose, the sheer number suggests potential bloat and could overwhelm users.
Completeness5/5The tool set covers a vast range of web testing needs: session management, element interaction, form handling, network mocking, performance audits, accessibility checks, visual regression, and more. It is extremely comprehensive.
Average 4.3/5 across 66 of 66 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 72 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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.
This repository includes a glama.json configuration file.
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.
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?
No annotations provided, so the description must fully disclose behavior. It mentions force bypass but does not explain error handling or what happens if selectors are invalid or submission fails.
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: first states purpose, second provides key usage tip. No redundancy, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and many sibling tools, the description lacks completeness. Missing: error behavior, handling of missing fields, comparison to 'auto_fill_form', and details about the 'observe' parameter's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds only incremental value beyond schema descriptions. The tip about 'force=true' provides practical guidance, but does not significantly enhance understanding of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fills form fields in a session page with optional submission. It uses a specific verb and resource, but does not differentiate from the sibling 'auto_fill_form' which may handle automatic filling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage tip for 'force=true' to bypass actionability checks, but lacks guidance on when to use this tool over siblings like 'auto_fill_form' or alternatives for form interaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions session handling and lists actions but omits important behavioral traits such as destructive potential, authentication needs (which are in the schema but not the description), rate limits, or error behavior. The description is insufficient for such a complex 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: two sentences that front-load the purpose and list actions. Every part is essential and there is no wasted text.
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 (25 actions, 8 parameters, no output schema), the description is too brief. It does not explain how steps are structured, error handling, return values, or common usage patterns. While the schema provides parameter details, the description lacks high-level workflow context needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed descriptions for all parameters. The main description adds a high-level list of actions but does not deepen parameter understanding beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.
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 is a multi-step interaction workflow and lists all 25 supported actions, making the purpose very specific. It also distinguishes from sibling tools that are single-action (e.g., click_element) by explicitly mentioning the multi-step nature and session handling.
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 multi-step scenarios versus single-action siblings, but it does not explicitly state when to use this tool versus alternatives. It mentions working with existing sessions or ephemeral pages, which provides some context, but lacks clear guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that external links are skipped by default and that a broken-link summary is returned, but it does not mention potential performance impacts, redirect handling, or error states beyond 404s. With no annotations, more detail would be beneficial.
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 three sentences covering purpose, behavior, and return. It is front-loaded with the core function. Slightly verbose first sentence could be trimmed without loss.
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 5 parameters and no output schema, the description partially covers return format (per-link results and summary). However, it lacks details on pagination, limits, error handling, and how results are structured. Additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented. The tool description adds slight value by repeating the relationship between url and session_id, but does not significantly enhance understanding 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's function: crawling all links on a page and reporting status. It distinguishes from sibling tools by specifying it checks links on a page, not just a single URL like test_url.
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 basic usage conditions (external links skipped unless check_external=true, works on session or URL) but lacks explicit guidance on when to use this tool versus alternatives like test_url or web_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does describe the return format ({passed, actual, expected}) and the deterministic nature ('hard pass/fail'). However, it omits details about error handling, timeouts, prerequisites, or side effects, leaving some behavioral ambiguity.
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 (two sentences) and front-loaded with the core purpose. It efficiently conveys key information, though the listing of assertion types is somewhat redundant with the schema enum.
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?
Despite having no output schema, the description mentions the return structure. However, it lacks information on session prerequisites, behavior when the page isn't ready, or error scenarios, leaving some gaps for an agent to fully understand usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all parameters (100% coverage). The description adds minimal extra semantics beyond listing the assertion types and mentioning that 'expected' is a string, which is already in 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's purpose: asserting a condition on the current page and returning a pass/fail result plus the actual value. It explicitly distinguishes itself from screenshot-based verification with the phrase 'no screenshot to interpret' and lists all supported assertion types.
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 context for when to use this tool, calling it 'the verification primitive' and recommending it over screenshot comparison. However, it does not explicitly state when not to use it or describe alternative tools beyond screenshots.
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 discloses the tool returns structured JSON and accepts an optional category filter. However, it does not mention side effects, auth needs, or rate limits. The description covers basic behavioral traits but lacks depth expected without annotations.
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 three sentences, but the second sentence ('Returns the guide as structured JSON') is redundant with the first sentence's 'Return a structured catalog...'. Could be more concise by combining or removing redundant information.
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 simplicity (one optional param, no output schema), the description adequately covers purpose, filtering, and usage guidance. It mentions workflow examples and tips, which is helpful. Minor gap: no mention of the output structure being self-documenting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'category' is fully described in the schema (100% coverage), so the description adds minimal value. It mentions 'optionally filtered to one category' which reinforces the schema but does not explain category meanings beyond the enum.
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 returns a structured catalog of Periscope's tools grouped by category, with parameters, workflow examples, and tips. It explicitly mentions optional filtering by category and directs new users to call it first, making its purpose distinct from sibling action 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends calling this tool first when new to the server to plan a testing workflow. While it doesn't state when not to use or list alternatives, the context implies it's a meta-tool with no direct siblings, so the guidance is clear but could be more complete.
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?
Adds behavioral info: 'Persists across navigations until reset' and 'Returns {success}'. With no annotations, this partially fulfills disclosure, but missing details like side effects on existing requests or required permissions.
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, front-loaded with action and presets, followed by use cases. No extraneous 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?
Covers core purpose, presets, persistence, and return value. Without output schema, it clarifies the return format. Could mention behavior on in-progress requests, but overall adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for both parameters. Description adds no new semantic value beyond schema, so baseline 3 is appropriate.
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?
Clearly states the tool throttles network to a preset. Lists the four presets. Does not explicitly differentiate from siblings like intercept_network or wait_for_network, but purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions use cases: testing loading spinners, skeleton states, offline fallbacks, timeout handling. Provides context for when to use, though no exclusions or alternatives 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?
With no annotations, the description carries full burden. It discloses screenshots, optional checks, and custom viewports, but omits side effects: does it navigate the current session? Does it close after? Does it clear state? The project parameter explains shared vs isolated context, but overall behavioral details (e.g., does it modify cookies?) are missing.
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?
Four concise sentences, each adding unique value: action, return value, core benefit, customization. No redundant or extraneous text. Leads with the primary function.
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 and four parameters, the description covers all parameters and the return type. However, it lacks integration context (does it open a new session? Is it a standalone test?) and details about how checks are performed or how results are structured. Could be more thorough for a complex multi-step tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: lists default viewports, explains project's shared/isolated context, and describes run_checks allowed values. This enriches the schema's minimal descriptions, especially for 'project' and 'viewports'.
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 loads a URL at multiple viewports, screenshots each, and optionally runs checks. It distinguishes from siblings like 'get_screenshot' (single viewport) and 'set_viewport' (only sets viewport) by emphasizing testing across breakpoints in one call. The verb 'test' implies a testing action beyond just taking screenshots.
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 responsive layout testing ('catches layout breakage across breakpoints') but does not explicitly state when to use this tool versus alternatives like 'get_screenshot' for a single viewport or 'run_checks_on_session' for existing sessions. No exclusions or alternative references are provided.
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 states the tool removes mocks and returns {success}, but does not disclose potential side effects (e.g., irreversibility, impact on other sessions) or prerequisites (e.g., mocks must exist). The description is honest but lacks depth.
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 two sentences long, front-loaded with the primary purpose, and no unnecessary words. Every sentence adds value: the first states what it does, the second gives usage context.
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 simplicity (2 parameters, no output schema), the description is mostly complete. It covers purpose, usage context, and return value. Missing details about error states (e.g., no mocks to clear) but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what the schema already provides. It clarifies that url_pattern uses exact matching and is optional, but this is also stated in the schema description. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes network mocks created by intercept_network, with an option to filter by URL pattern. It uses a specific verb ('remove') and resource ('network mocks'), and the distinction from the sibling tool intercept_network (which creates) is implied.
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 a clear use case: 'Use to restore real backend responses after testing mocked states.' This gives context for when to use the tool, but does not explicitly mention when not to use or list alternatives. However, the context is sufficient for most scenarios.
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, description carries full burden. It discloses that it writes a diff image and returns percentage, and mentions threshold behavior. However, it does not state whether it modifies original files, requires permissions, or other 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?
Two sentences: first defines action and outputs, second gives usage and parameter detail. No wasted words, front-loaded.
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?
No output schema, but description explains return values (percentage and diff image path). Covers threshold parameter and usage context. Does not address error cases or file format requirements, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds meaning by explaining that threshold sets per-channel color tolerance, which aligns with schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it pixel-diffs two screenshots, returns a percentage, and writes a diff image. It distinguishes from sibling tools like screenshot_session (capture) and get_screenshot (capture).
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 tells when to use (for visual-regression checks after capturing with test_url/screenshot_session). Does not list exclusions or alternatives, but provides workflow context.
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 states the return format {success, project} and lists retrieved fields, but does not explicitly confirm it is read-only or mention any side effects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded purpose and usage guidance, containing no unnecessary 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?
For a simple tool with one parameter and no output schema or annotations, the description adequately explains the return content and provides usage context, though it omits error handling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage (the only parameter 'name' is described as 'Project name'), the description adds context about what configuration is retrieved but does not enhance parameter 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 'Get one project's saved configuration' and lists specific fields (base URL, max_pages/max_depth, screenshot directory, auth), distinguishing it from sibling tools like create_project or list_projects.
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 advises to 'Use it to confirm setup before crawling, testing, or logging in', providing clear context for when to use the tool, though it does not mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ({headers, rows, total_rows}) and mapping behavior. However, it does not mention potential errors, limitations (e.g., only first table), or performance characteristics.
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 two concise sentences with no extraneous information. It front-loads the main purpose and adds value with usage guidance, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides return structure and usage context. With only 3 parameters (all documented), no output schema, and no annotations, it covers the essential aspects. A slight improvement would be to clarify if it handles multiple tables or only the first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds default values (max_rows:100, selector:'table') which are already in the schema. It provides no additional meaning beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Parse') and resource ('HTML table into structured data'), clearly distinguishing it from sibling tools like get_page_elements or get_page_html by focusing on tabular content parsing.
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 states when to use the tool ('Use instead of scraping table markup by hand when verifying tabular content'), providing clear context. However, it lacks explicit when-not-to-use guidance or alternatives, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains the three actions but does not disclose potential side effects (e.g., restore will navigate the page, possibly losing current state) or error conditions (e.g., what happens if the snapshot name doesn't exist). The description is moderately transparent but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the concept ('Named page-state checkpoints') and then detailing the actions and use case. Every sentence adds value, 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 absence of an output schema and the presence of enums, the description adequately explains the tool's functionality. However, it could be more complete by mentioning error handling (e.g., missing snapshot) or the format of diff output. Overall, it provides sufficient context for an AI agent to use the tool effectively.
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 covers all three parameters with 100% coverage, including enum descriptions. The description adds meaningful context beyond the schema by elaborating what each action does in detail (e.g., 'snapshot saves URL + cookies + storage + DOM signature'). This extra info justifies a score above the baseline of 3.
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 manages named page-state checkpoints with three distinct actions (snapshot, restore, diff). It specifies exactly what each action does (saves URL/cookies/storage/DOM signature, navigates back, compares DOM), distinguishing it from sibling tools that perform individual operations like get_cookies or get_page_elements.
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 a use case: 'Enables testing multiple paths from the same starting point.' However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., using separate tools for cookies, storage, and DOM), and does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the action is scroll-only and returns {success}, which is sufficient for a simple non-destructive action. But it does not disclose edge cases like element not found or already in view.
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 concise sentences: one stating the core function, the other providing usage examples. No unnecessary words, front-loaded key information.
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 simplicity and no output schema, the description is fairly complete: it states the return value and typical use cases. It could be slightly improved by noting what happens if the selector fails, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters adequately. The description adds no extra detail about parameters, so a 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scroll an element into the viewport') and distinguishes it from clicking. It also provides specific use cases (lazy-loaded content, scrolling before screenshotting), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contexts for use (trigger lazy load, before screenshot), which helps the agent decide when to apply this tool. However, it does not explicitly state when not to use it or mention any alternatives among siblings.
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 bears full burden. Discloses auto-detection, menu opening for custom dropdowns, and Playwright syntax limitation. But omits error handling (e.g., option not found), prerequisites (element visible), and safety implications.
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?
Four sentences with no wasted words. Front-loaded with purpose and method, then key behaviors. Efficient and well-organized.
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 most aspects: how to specify option, targeting multiple elements, observe parameter, and selector limitation. Missing clarifications on exclusive usage of option parameters and detailed return structure. Adequate for a tool with 7 params and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context for selector (no '>>' syntax) and element_index (use for attribute-less selects). For option parameters, it only restates what schema says, adding minimal value.
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?
Clearly states the verb 'select', resource 'option from a native <select> or custom dropdown', and specifies methods: by value, label, or index. Distinguishes from sibling tools like click_element by emphasizing it handles both native and custom dropdowns.
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 says to use this tool rather than click+click for custom dropdowns, and advises using element_index when multiple attribute-less <select> elements exist. However, lacks explicit exclusions or alternatives for other scenarios.
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 key behaviors (persistence, screenshot return) but lacks details about potential side effects, limitations, or required browser support. For a simple emulation tool, the disclosure is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the action and output, the second provides usage context and persistence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description covers the essential details: purpose, return value, and persistence. However, it omits specifics about the screenshot format (e.g., base64, file) and potential limitations. Still, it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (mode enum, session_id). The description adds context by stating 'on a session' and explaining the mode purpose, but does not add significant new information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Emulate' and 'screenshot') and clearly identifies the resource ('prefers-color-scheme (dark or light)'). It distinguishes this tool from siblings like set_viewport or check_color_contrast by specifying the exact color scheme emulation.
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 states when to use the tool ('to verify a site's dark/light theming without touching OS settings') and notes that emulation persists for later actions. It implies context but does not explicitly mention when not to use it or 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?
Given no annotations, the description discloses that matching is a plain substring test (not regex), explains miss behavior, and clarifies that bodies are automatically captured. It does not mention potential performance or size limits, but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each serving a purpose: purpose, matching rule, miss behavior, and use case. No extraneous text; front-loaded with the core function.
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 description covers the core functionality, matching semantics, and error recovery. It lacks details about return format (though implied) and does not mention session prerequisites, but these are reasonable omissions given the tool's simplicity.
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?
All three parameters are described in the schema (100% coverage). The description adds valuable context beyond schema: url_pattern is not regex, includes examples, and explains method is optional. This enhances understanding.
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 returns captured response body text given a URL substring and optional method filter. It distinguishes from siblings by noting it's the fastest way to diagnose 400/500 errors with no setup, but does not explicitly differentiate from get_network_log or similar 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for debugging HTTP errors and provides guidance on adjusting patterns when a miss occurs. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that results include titles, URLs, snippets, and are limited by 'max_results,' but omits behavioral traits like rate limits, authentication, or error handling. Adequate but minimal.
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 concise sentences front-load the action and add use-case context. Every word earns its place; no redundancy.
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 two parameters, no output schema, and straightforward behavior, the description covers purpose, input, output, and use cases. Complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'query' and 'max_results' are described). The description adds 'up to max_results,' which reiterates schema default. No new parameter semantics beyond what schema provides.
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 search engine (DuckDuckGo), the returned fields (titles, URLs, snippets), and a parameter (max_results). It distinguishes from sibling tools by being the only general web search tool.
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?
Provides explicit use cases: 'look up documentation, verify external facts, or research during a testing workflow.' While it doesn't mention when not to use or alternatives, it offers clear context for 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 burden. It mentions return behavior ('Returns which fields were filled and with what') but does not disclose potential side effects like actual form submission after filling, or limitations (e.g., dynamic forms).
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 concise at three sentences, front-loaded with core purpose and benefit, followed by return value and usage hints. No unnecessary 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 no output schema and no annotations, the description covers purpose, parameters with examples, and return value. It lacks details on error handling, prerequisites (session context), or limitations, but is adequate for typical use.
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 100%, so baseline is 3. The description adds value by providing usage examples for overrides and submit, clarifying their purpose beyond schema descriptions. However, no extra info for session_id or form_selector.
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 identifies the tool as auto-detecting form fields, inferring types, filling test data, and optionally submitting. It distinguishes from sibling tools by emphasizing automation and efficiency ('one call replacing 5-10').
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 explicit usage guidance for overrides and submit parameters. It implies the tool is for form testing but does not explicitly state when not to use or mention alternatives among siblings like 'fill_form'.
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?
Description discloses side effects (freeing resources) and error cases (idle-expired, evicted, crashed). No annotations, so description carries full burden; it's sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. First covers action and return, second adds usage guidance and error behavior. Front-loaded with key 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?
Simple tool with one parameter and no output schema. Description adequately covers purpose, return, resource freeing, and error handling. Implicit prerequisites are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with schema description 'Session ID to close'. Tool description doesn't add meaning beyond schema; baseline 3 due to 100% coverage.
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 'close' with specific resource 'browser session'. Mentions freeing resources and return value. Distinguishes from sibling tools by specifying it's for finishing a 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 'Call it when finished' and describes error behavior for closed/expired IDs. Provides good context on when to use, though lacks explicit exclusions.
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, the description fully discloses irreversible deletion, name reuse, and that screenshots/reports on disk are not removed. This is comprehensive for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: action, return value, irreversibility, name reuse, and what is not deleted. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description covers return value, irreversibility, and side effects. Lacks error handling information but is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter 'name'. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 permanently deletes a project and its configuration/auth, distinguishing it from other project-related tools. It specifies exactly what is and isn't deleted (e.g., screenshots not removed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you want permanent deletion) but does not explicitly state when not to use or provide alternatives. No guidance for soft-delete or archive scenarios.
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 explains the return structure ({cookies, total} with details) and frames it as a read operation. However, it omits potential behaviors like error handling when the session is invalid or no cookies 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action and return type; the second gives a concrete use case. Well-structured and efficient.
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 simplicity (2 parameters, no output schema), the description covers the core functionality, return format, and a primary use case. It does not discuss edge cases or limits, but is sufficient for an agent to understand and invoke the tool correctly.
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 100%, but the description adds value by explaining the domain_filter as 'optionally filtered by domain' and indicates the output structure. The session_id parameter is minimally described, but the overall semantic gain is positive.
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 reads cookies from a session's browser context, with optional domain filtering. This distinguishes it from sibling 'set_cookies' and other tools, as it is explicitly a read operation.
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 specifies it is 'Essential for debugging auth/session issues' and mentions confirming cookie presence and scoping. While it does not explicitly exclude alternatives or state when not to use, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions saving a JSON or CSV file and returning percentile stats, but does not clarify where files are saved (e.g., local vs. server) or whether there are side effects like file system writes. The phrase 'Periscope drove' may be unclear to external agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose and then provides details. It is relatively concise given the complexity, though some sentences (e.g., 'Saves a JSON ... and returns percentile stats') could be more direct. Still, it avoids unnecessary fluff.
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?
There is no output schema, so the description should explain return values. It mentions returning percentile stats but does not specify their structure (e.g., keys like p50, p75). It also lacks prerequisites (e.g., session must exist) and error handling. The file-saving behavior is ambiguous (side effect or not?).
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 100%, so baseline is 3. The description adds value by explaining the 'clear' parameter as 'Reset the recorded interactions after exporting' and specifying 'JSON is easiest to graph; CSV for spreadsheets' for format, which goes beyond schema enums.
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 exports the real INP time series for a session, one record per interaction, with latency, event type, target, timestamp, and URL. It distinguishes from Lighthouse and mentions use after driving interactions, making the purpose specific and differentiated from siblings.
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 says 'Use after driving interactions (interact_and_test, click_element, fill_form…) and contrasts with Lighthouse, which cannot measure INP in lab mode. It also specifies ideal context: 'long interactive test where you want to see all INP times, not just the worst.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly implies a read-only operation via 'Read' and states the return format ('Returns the key/value pairs as an object'). However, it does not disclose error behavior (e.g., invalid session ID, missing keys) or confirm non-destructiveness explicitly.
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 three sentences long and front-loaded with the core action. It is fairly concise, though the second and third sentences could be merged for slightly better efficiency. No unnecessary 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's simplicity (3 parameters, no output schema), the description adequately covers the return format and use case. Missing details like error handling or behavior for missing keys are minor gaps in an otherwise complete description.
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 100%, but the description adds significant value: it clarifies that 'keys' is optional, mentions the default storage type ('local'), and explains the return format as an object. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read'), identifies the exact resource ('a session page's localStorage (or sessionStorage)'), and clarifies scope ('all entries, or specific keys'). It clearly distinguishes from siblings like set_local_storage and get_cookies.
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 states when to use the tool ('when debugging' and 'to inspect client-side state'), providing clear context. However, it does not explicitly mention when not to use it or suggest alternative tools for related 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 full burden. It describes the return format ({success, report}) and the contents, but does not disclose error behavior, authentication needs, or potential side effects. It is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded and efficient: first sentence covers purpose and return, second provides usage guidance. No unnecessary 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?
For a simple read tool with one parameter and no output schema, the description sufficiently covers purpose, return structure, and source of valid input. Could optionally mention error handling, but not essential.
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 100% and the description adds value by connecting the parameter to list_reports, telling the agent where to obtain valid paths. This goes beyond the schema's basic 'Path to the report file'.
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 clearly states the verb 'Load' and resource 'saved test report', and details what contents are returned (per-page issues, site-wide findings, run metadata). It distinguishes from the sibling tool list_reports by indicating that get_report returns the full contents, not just paths.
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 tells the agent to 'Get valid paths from list_reports', providing clear context for when to use this tool. No when-not conditions are stated, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool checks common patterns and returns messages, but does not explicitly state it is read-only or clarify if any page interaction occurs (e.g., scrolling). The description is adequate but could be more explicit about non-destructiveness.
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 two sentences. The first sentence states the core action and approach, the second explains a parameter and use case. It is front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 3 parameters and no output schema, the description covers purpose, approach, parameter guidance, and a use case. It says 'Returns the messages found', which is minimal but sufficient. Could mention failure cases or empty results, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The description adds context beyond the schema by explaining when to use wait_ms (animate in) and that selector overrides defaults. This provides practical value for parameter usage.
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 toast/notification/alert text, lists common patterns, and gives a specific use case (verify success/error notifications). This distinguishes it from sibling tools like get_page_elements or get_screenshot.
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 says 'Use to verify success/error notifications after an action', providing clear context. It also explains the wait_ms parameter for toasts that animate in. However, it does not explicitly state when not to use 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?
Discloses one-shot nature, return format, and timing requirement. Lacks info on multiple calls or no-dialog scenario, but no annotations to contradict.
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 concise sentences, front-loaded with core action. Every sentence adds value without redundancy.
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, usage timing, and return. Minor gaps on edge cases (e.g., handler expiration, no dialog) but acceptable given tool simplicity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds context on prompt_text purpose but no new parameter-level details beyond 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?
Description clearly states it arms a one-shot handler for JavaScript dialogs, specifying actions (accept/dismiss) and optional prompt text. Unique among 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states must be called BEFORE the dialog-triggering action, with a consequence if not. Does not specify alternatives, but no sibling tools handle dialogs.
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 fully explains behavior: opens visible browser, requires human input, requires display, and session capture via save_login. Could mention consequences if display not set.
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 concise sentences with no wasted words. Front-loaded with action verb and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, usage flow, prerequisite, and follow-up action. Could mention error handling or timeout, but overall complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with descriptions. Description adds minimal extra meaning beyond schema (e.g., project must exist, login_url defaults to configured). Baseline 3 is appropriate.
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 clearly states the tool opens a visible browser window for manual login, specifying exact use cases (2FA, MFA, SSO, CAPTCHA, magic links, device confirmation), and distinguishes it from automated login methods.
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 says when to use (non-automated auth flows) and directs to call save_login afterwards. Does not provide explicit 'do not use' conditions but implies automated alternatives. Also mentions system requirement (DISPLAY set).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns new URL/title and a screenshot, and describes behavioral intent (testing). However, it does not mention side effects, prerequisites (e.g., session must be active), or potential error conditions.
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 core function and return values, then add behavioral context. Every sentence earns its place with no unnecessary 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 absence of an output schema, the description adequately explains return values (new URL/title and screenshot) and provides use cases. It is largely complete for a tool of this complexity, though it could mention prerequisites or error handling.
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 100%, providing descriptions for all three parameters. The description adds value by explaining the purpose of each action (reload for persistence, back/forward for SPA history), enhancing the agent's understanding beyond the enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool handles browser history actions: back, forward, and reload. It specifies the return values (new URL/title and screenshot) and distinguishes from sibling navigation tools by focusing on history/reload operations on a 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?
The description provides explicit context for when to use each action: reload for testing state persistence and caching, back/forward for testing SPA history. It does not mention alternative tools or explicitly state when not to use, but the guidance is clear enough.
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 mentions the tool does not open a new page but does not explicitly state whether the operation is read-only or has side effects. While auditing is typically non-destructive, the lack of affirmative safety disclosure is a gap, though the description's emphasis on 'audit' implies no mutation.
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 two sentences, front-loading the core purpose and then adding usage context. No redundant words; every sentence adds value. It is structured for quick comprehension.
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 absence of an output schema and annotations, the description covers the essential aspects: what the tool does, when to use it, what checks are available, and the return structure (referencing test_url). It could be more self-contained by detailing the return format, but referencing a sibling tool is acceptable. Error conditions are not mentioned, but the description is otherwise complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description lists the check types (visual, accessibility, etc.) similarly to the schema's enum, and notes the default is all checks. It does not add new meaning beyond what the schema provides, though it reinforces the expected 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 runs audit checks (visual/accessibility/functionality/seo/performance/geo) against the current page in a session, distinguishing itself from the sibling tool test_url by noting it does not open a new page. The verb 'run' and resource 'audit checks on a session's current page' are 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'after your interactions' and 'to audit a state you reached by clicking/filling.' It also contrasts with test_url, telling the agent not to use this tool when a new page needs to be opened. This provides clear context and exclusions.
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 fully discloses that the tool launches its own headless Chrome, ignores session/auth state, and handles Node.js detection along with failure recovery commands. Since no annotations are provided, this transparency is critical and well-covered.
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 highly concise, front-loads the main purpose, and each sentence adds value—covering behavior, prerequisites, return values, and error handling without redundancy.
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 complexity of running Lighthouse (Node.js, Chrome), the description covers essential context: return values, metrics, Chrome isolation, and setup requirements. The lack of an output schema is compensated by detailing what is returned (scores, metrics, failed audits, saved report).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have clear descriptions in the input schema (100% coverage). The description adds context about the tool's outputs but does not augment the meaning of individual parameters 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a real Google Lighthouse audit against a URL, returning scores, Core Web Vitals, and saving a full JSON report. It has no clear sibling duplicates; among many session/tool/test tools, this one is uniquely identified.
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 prerequisite (Node.js) and behavior (headless Chrome, no session/auth), as well as auto-detection and error recovery. It does not explicitly state when to avoid use, but the context is sufficient for correct invocation.
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?
Describes core behavior (write, optionally clear, return {success}) and a reload caveat. With no annotations, description carries full burden. Minor omissions: does not clarify overwrite vs merge behavior for existing keys, nor specify allowed value types in entries.
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 concise sentences. First sentence states action; second provides use context and a caveat. No redundant information, well front-loaded.
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 4 parameters and no output schema or annotations, description covers purpose, usage, and a behavioral note. Lacks explicit overwrite semantics and session context, but is sufficient for most testing use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions already present. Description adds marginal value: mentions return value and use case, but does not elaborate on parameter details beyond what schema provides. Baseline adjusted to 3.
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 clearly states 'Write key/value entries to a session page's localStorage (or sessionStorage)' with a specific verb and resource. It distinguishes from sibling get_local_storage by focusing on write behavior.
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 says 'Use to seed client state... reload if the app reads storage only at load time', providing clear context for when to use. Lacks explicit exclusions or references to alternative tools like set_cookies, but the guidance is adequate for typical testing 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?
With no annotations, the description fully covers behavior: locate forms, list required fields, collect messages, and return details. It implies read-only audit without 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?
Three sentences front-load the purpose, action, return, and use case. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately describes return type and usage. It could be more complete with error handling, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and includes detailed parameter explanations. The tool description adds no new parameter semantics 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 audits form validation, lists required fields, and collects error messages. It distinguishes itself from sibling tools like auto_fill_form and fill_form by focusing on audit rather than filling.
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 says 'Use to verify client-side validation behaves as intended,' providing clear context. However, it does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the process (tabs from top, records focus order, flags issues) and the return values (total_tab_stops, focus_order, issues). However, it does not state whether the tool is read-only or if it has side effects on the session, which would be helpful for a test 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 concise with three clear sentences. The first sentence immediately states the main action, followed by return values and a brief note on usage. No redundant information.
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 no output schema, the description adequately explains return values (total_tab_stops, focus_order, issues). It covers the tool's purpose and input options. However, it could mention prerequisites or expected behavior when no focusable elements are present.
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 100%, so baseline is 3. The description adds meaningful context beyond the schema by explaining the 'project' parameter's impact on authentication context and clarifying that 'url' or 'session_id' can be used. This helps the agent understand parameter choices better.
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 specific action ('Tab through a page from the top and record the focus order, flagging any stop with no visible focus indicator') and identifies the resource (keyboard navigability audit). It distinguishes from siblings by mentioning it works on a session or URL and focusing on keyboard operability, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('works on a session or a URL') but does not provide explicit exclusions or alternative tools. Sibling tools like 'test_responsive' or 'check_color_contrast' have different purposes, but no guidance is given on choosing between this and other accessibility tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds context by mentioning the return value {success} and the requirement for absolute paths that exist on the server. It doesn't fully disclose error behavior or side effects, but it covers essential 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 two sentences, each adding unique value: the first states the main purpose, the second provides a specific usage tip. No waste or repetition.
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 absence of an output schema and annotations, the description adequately covers the tool's behavior, return value, and a key precondition. Missing details about failure modes but sufficient for typical use.
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 schema already describes the parameters (100% coverage), but the description adds meaningful guidance like 'Provide absolute paths that exist on the server' for files and 'target the underlying file input's selector' for selector, enhancing understanding 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 verb 'Set file(s)' and the resource '<input type="file"> element by path', distinguishing it from siblings like click_element. It uniquely focuses on uploading without the OS file picker.
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 mentions using absolute paths and targeting the underlying file input's selector for pickers opened by buttons, providing clear guidance on when to use this tool. However, it doesn't explicitly state when not to use it or suggest 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?
With no annotations, the description discloses key behaviors: set replaces baselines, check returns a verdict with diff image, default threshold (0.5%), and storage per project+name. It does not detail error handling or authentication, but covers the core workflow 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense paragraph that covers purpose, actions, defaults, and best practices without unnecessary words. It is well-structured for quick reading, though splitting into bullet points could improve scanability.
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 complexity (7 parameters, no output schema), the description lacks details on the return format for 'check' and error cases (e.g., missing baseline). It covers the main workflow but could be more complete for a tool without structured output documentation.
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 100%, and the description adds value by explaining the role of each action, default values (e.g., threshold, max_diff_percent), and the recommendation for selector usage. This goes beyond the schema's parameter descriptions.
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 purpose: managing named visual-regression baselines with two actions (set and check). It distinguishes itself from sibling tools like compare_screenshots by focusing on baseline management rather than one-off comparisons.
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 practical guidance: re-baseline on intended changes, and prefer selector-scoped over full-page baselines to avoid flakiness. It does not explicitly list when to use alternative tools, but the advice is sufficient for the primary use case.
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 discloses the return format {success, session_copied} and explains that session_copied is false when only config/cookies transfer. This is good for a simple copy 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 two sentences long, front-loaded with the core action and then details. Every sentence adds value with no wasted 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?
The description explains the return format despite no output schema, covers both possible outcomes, and the tool is simple with only two parameters. No additional context needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described individually. The tool description reiterates the directionality but adds no extra semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 copies auth configuration and the live login session (cookies + localStorage) between projects on the same domain. This specific verb+resource distinguishes it from sibling tools like set_cookies, set_local_storage, save_login, and login_project.
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 states 'Use to reuse a login across related projects,' providing clear guidance on when to use. It does not include explicit when-not-to-use or alternative tools, but the context is clear.
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 carry behavioral details. It states the tool works on a session or URL, lists default returned attributes, and mentions the 80-char text preview and options for full text/extra attributes. It does not disclose behavior for no matches or error conditions, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose. The second sentence is moderately long but packed with useful detail. Could be split for readability, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a clear schema, the description covers the key output and parameter options. It does not mention the default 'max_results' of 50 or pagination, but these are in the schema. The description is sufficient 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining how to use the 'attributes' and 'full_text' parameters beyond the schema definitions. It also clarifies the mutual exclusivity of 'url' and 'session_id' (implicitly).
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 'List elements matching a CSS selector with their attributes', using a specific verb and resource. It distinguishes from sibling tools like 'find_element' (single element) and 'click_element' (action).
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 notes that only standard CSS selectors are supported and Playwright pseudo-classes are not, which helps avoid misuse. It also explains how to get extra attributes and full text, but does not explicitly contrast with alternatives like 'find_element' or 'get_page_html'.
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 truncation behavior and return of HTML string(s). However, lacks details on performance impact, error handling, or behavior if selector matches many elements. No annotations provided.
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?
Three concise sentences covering functionality, usage examples, and selector constraint. No extraneous 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?
Does not specify return format clearly ('HTML string(s)' ambiguous; single vs array). Also lacks error handling or edge case details. Output schema absent, so description carries more burden.
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?
Adds value beyond schema by clarifying that selector is optional and returns full page HTML when omitted, and specifies 'Standard CSS selectors only.' Schema coverage is 100%, baseline 3, elevated by added context.
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 specifies returning raw outerHTML of matching elements or full page HTML if no selector, truncated to max_length. Distinguishes from siblings like get_page_elements and web_fetch.
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?
Provides clear use cases (inspect component/markup structure, SEO meta tags, widget DOM) but does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description discloses listing behavior and output ordering but lacks details on authorization, rate limits, or behavior when no reports exist. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words, front-loaded with purpose. Highly concise.
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?
Covers all essential aspects: what it lists, output format, ordering, and link to reading with get_report. Complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes parameter with 100% coverage; description adds little beyond 'for one or all projects', which aligns with 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?
Clearly states verb 'List' and resource 'saved test reports' with scoping (one/all projects) and output format (path, timestamp, newest first). Distinguishes from sibling get_report.
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?
Explicitly tells when to use (list reports) and provides alternative get_report for reading a specific report.
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 implies a read-only operation but does not explicitly state it's non-destructive or safe. With no annotations, the burden was on the description to disclose behavior; it could be more explicit about 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?
Two concise sentences front-load the purpose and add usage context without any waste. Every sentence adds value.
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 the tool's simplicity (no parameters, simple output), the description fully covers return format and use cases. 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?
There are zero parameters, so baseline is 4. No additional parameter meaning is needed, and schema coverage is 100%.
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 lists active browser sessions with specific fields (session_id, URL, idle time) and distinguishes from sibling tools like close_session or open_session by its listing nature.
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?
It provides explicit use cases: recovering a session ID or spotting idle-timeout/concurrency cap issues. Although it doesn't mention when not to use or alternatives, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains persistence of session, return of success details, and re-run behavior. Missing minor details like potential side effects (e.g., overwriting existing session), but covers essential 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?
Three sentences front-loaded with action, prerequisites, and return value. No unnecessary words, each sentence contributes essential information.
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 tool with one parameter, no annotations, and no output schema, the description provides sufficient context: what it does, prerequisites, return value, and a re-use scenario. Completeness is high relative to complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'project' described as 'Project name'. The description adds no extra meaning beyond that baseline. Baseline of 3 is appropriate as the schema already documents the parameter adequately.
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 'Execute' and the resource 'project's configured login', specifying methods (form, Basic Auth, cookies) and the key outcome of persisting the session. It distinguishes from siblings by mentioning prerequisites (set_* tools) and re-run on expiry.
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 prerequisites ('Requires set_form_login / set_basic_auth / set_cookies first') and a specific use case ('Re-run it when auth expires mid-test'). Lacks explicit when-not-to-use comparisons with alternatives like interactive_login, but overall guidance is clear.
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 bears disclosure. It reveals key behaviors: saving cookies and localStorage, closing the visible window, enabling headless authenticated sessions, and the need to re-run interactive_login on expiration. It does not detail failure modes or overwrite behavior, but is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence encapsulates the core actions (capture, save, close), and the second provides the outcome and lifecycle. Every sentence earns its place.
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 one parameter and no output schema, the description gives a complete picture: what it does, how it affects the session, and the follow-up action. It is thorough enough for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a clear description. The tool description reinforces that the project must have an interactive_login in progress, which adds context but does not substantially exceed the schema's information. Baseline 3 with slight added value.
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 cookies and localStorage from an in-progress interactive_login, saves it, and closes the window – a specific verb+resource action. It distinguishes from sibling tools like interactive_login (initiates login) and close_session (only closes without saving).
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 says to use it when there is an in-progress interactive_login and mentions re-running interactive_login when the session expires, providing clear usage context. It does not explicitly exclude alternatives, but the sibling set implies close_session for just closing.
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 behavior: generates HTML and PDF, includes screenshots, redacts secrets, resets journal with clear, and notes appear at top. It also mentions that the journal records automatically from server start. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 4 sentences, front-loaded with purpose. It is concise and includes necessary details without redundancy. Could benefit from slight structuring, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 5 parameters and no output schema, the description explains the output format (HTML+PDF) and content (verdicts, timings, errors, screenshots). It also covers the clearing mechanism. It is complete enough for an agent to understand the tool's behavior and expectations.
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 100%, and the description adds significant meaning beyond the schema: explains overall purpose, that notes appear top, that clear resets journal, and that screenshots are embedded thumbnails. The schema descriptions are already clear, but the description integrates them into the tool's context.
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 generates a human-readable dossier of everything done in the server run, including tool calls, arguments redacted, verdicts, timings, errors, and screenshot thumbnails. It distinguishes itself from siblings like get_report by specifying it covers all calls and produces HTML+PDF.
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 it is for handing to the user to review the whole session and suggests adding findings via notes. It also explains the clear=true usage 'between test rounds'. However, it does not explicitly state when not to use it vs alternatives like get_report, but the context makes it clear.
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?
Describes automatic fallback for portal overlays, flagging click_method='js_dispatch', and the use of force=true to bypass actionability checks. No annotations exist, so description carries full burden and does it well.
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?
Three sentences, front-loaded with main action, no filler. Every sentence adds critical information.
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 return values and observe options well despite no output schema. Could mention prerequisites like session open, but not critical. Sufficient for the tool's complexity.
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 100%, but description adds value for force (use case) and observe (explains options). Also clarifies return values (screenshot, URL/title, click_method). Adds beyond 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 'Click an element in a session page' and distinguishes behaviors like automatic fallback for overlays and the force parameter. No other sibling tool has such specificity.
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?
Provides clear guidance on when to use force=true and explains the automatic fallback mechanism. Does not explicitly exclude other tools but context is sufficient.
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, the description fully discloses behavior: BFS crawling, determinism, sitemap seeding, return format with pages_not_crawled, authenticated context, and parameter effects like max_pages=0 unbounded up to 2000. No contradictions.
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 dense but slightly long. It front-loads the core purpose. Could be slightly more concise, but every sentence adds value.
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 the complexity of 7 parameters and no output schema, the description explains return values, edge cases (max_pages=0, safety ceiling), behavior highlights, and provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 7 parameters. The description adds minimal new information about parameters beyond the schema, so baseline 3 is appropriate.
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 discovers a project's pages via breadth-first crawling from its base URL, with bounds. It distinguishes from sibling tools like test_project by noting that test_project is for full audits.
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 advises using test_project for full audits, providing a clear alternative. It does not explicitly state when not to use this tool, but gives context for alternatives.
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 key behavioral traits beyond schema: download waiter is armed before click to catch fast downloads, uses overlay-fallback for Radix menus, returns file path, size, sha256, source URL, and text preview. Specifies save location data/downloads/. No annotations present, so description fully covers transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single paragraph of five sentences, each serving a purpose: first states main function, second details operational mechanism, third lists return values, fourth specifies location. No redundancy or unnecessary 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?
Covers return values in detail despite no output schema, explains file location and download triggering. However, lacks information on error handling (e.g., timeout scenarios, no download triggered).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. Description adds some context (e.g., pre-arming for fast downloads) but does not significantly enhance meaning beyond the schema's descriptions.
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 files from downloads triggered by clicking an element, specifying file types like CSV, PDF, and invoices. It distinguishes itself among siblings like click_element and upload_file by focusing on export verification.
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?
Provides context for use: verifying exports via download capture. Mentions mechanism (pre-arming waiter, overlay-fallback) but does not explicitly state when not to use it or compare with alternatives like web_fetch.
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 states that elements are 'ranked by match quality' and returns both a found flag and elements with best CSS selectors. It implies a read-only operation but does not elaborate on error cases or non-matching scenarios.
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, first defines functionality, second provides usage rationale. Every word earns its place. 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 has 6 parameters and no output schema, the description covers the main purpose, return structure, and usage guidance. It lacks details on ranking order or max_results default, but is sufficient for basic use.
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 100%, but the description adds value beyond schema by explaining that results are ranked and the best CSS selector is returned. It integrates the parameters into the purpose, adding context not present in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Find' and resource 'elements' with criteria (text, tag, ARIA role, proximity). It distinguishes from sibling tools by focusing on selector generation from visible attributes, stating 'use it to get a reliable selector from what you can see'.
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 says to use this tool when you have visible cues like button text to avoid guessing selectors. It provides clear context but does not explicitly say when not to use it or mention alternatives among siblings.
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 discloses key behaviors: flows persist across sessions and server restarts, the tool is 'deliberately minimal' regarding verification, and steps must use interact_and_test's exact format. It does not cover error handling or overwrite behavior, but the main traits are well 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no redundant sentences. It opens with the core purpose, enumerates actions, provides guidance on verification, and mentions persistence. Every sentence contributes essential information without filler.
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 moderate complexity (6 params, no output schema, no annotations), the description covers the main functionality, persistence, and relation to siblings. It could mention overwrite behavior on save, but overall it 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are described in the schema (100% coverage). The description adds value by explaining the action enum options, specifying that steps must be in interact_and_test's format for save, and noting the default for continue_on_error. This goes beyond the schema's basic descriptions.
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 purpose: saving and replaying named step sequences. It explicitly lists the four actions (save, run, list, delete) and distinguishes itself from siblings by referencing interact_and_test as the underlying engine for execution, making its unique value 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 when to use each action (e.g., 'action='save' stores steps', 'action='run' executes a saved flow') and provides guidance on verification: 'verify outcomes by following a run with assert_all or visual_check'. It lacks explicit exclusions or alternatives, but the context is clear.
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?
Describes return format (per-element property→value maps) and scope. Lacks details on edge cases (no matches, errors) but no annotations exist, so description does reasonable job. Could mention safety/read-only nature.
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 concise sentences: first defines operation, second provides usage guidance. 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?
Describes output format sufficiently for a simple read tool. Could mention default max_results or handling of multiple elements, but overall adequate given parameter count and schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description does not add extra parameter-level detail beyond schema, but reinforces purpose. Baseline 3 justified.
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?
Clearly states it reads computed CSS values (rendered), specifying verb 'Read', resource 'CSS values', and context 'after stylesheets and inheritance'. No sibling offers this, so it's well-differentiated.
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?
Explicitly says to use for programmatic verification of colors, fonts, spacing, display, opacity instead of screenshots. Provides clear use case and alternatives (screenshot tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that clearing the buffer is the default behavior and that entries are captured passively. Without annotations, this description adequately informs the agent of key behaviors, though additional details (e.g., auth, rate limits) are missing.
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?
Three concise sentences that front-load the primary purpose, include key behavioral details, and provide usage guidance. Every sentence adds value with no redundancy.
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 the tool's purpose, behavior, and usage context effectively given the simple parameter set and missing output schema. Could mention the output format (e.g., array of errors) to be fully complete, but this is not critical.
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 has 100% coverage with descriptions for both parameters. The description adds meaning by explaining the 'clear' parameter's default and the operational context ('since last read'), providing value 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?
Clearly states the tool returns browser console output including errors, warnings, and logs. Specifies passive capture and default clearing behavior. Positions it as the first debugging step, distinguishing its purpose from other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends it as the first stop when debugging a broken page and notes no steps are required. Does not mention when to avoid it or alternatives, but the context is clear for common debugging 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 return format: array of project configs (empty if none exist). Since no annotations, the description provides necessary transparency about read-only nature and possible empty result.
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 with no waste. Front-loaded with purpose, then returns format, then usage hint. Every sentence adds value.
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?
Simple tool with no parameters and no output schema, but description sufficiently explains return value and fields. Could mention if list is paginated, but likely not needed.
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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but baseline for 0 params is 4. No additional meaning needed.
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?
Clearly states verb (List), resource (saved testing projects), and data included (base URL, crawl limits, auth type). Differentiates from siblings like get_project (single project) and create_project/delete_project.
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 says 'Use it to discover the project names the other project/auth/testing tools expect.' Provides clear usage context but does not mention when not to use or alternative tools like get_project for single projects.
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 full burden. It discloses persistence, idle timeout, shared vs. isolated context, and the need to close. It does not mention potential side effects like display requirement for headed mode (described in schema) or rate limits, but overall provides good 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 four sentences, front-loaded with the primary action and return value. Every sentence adds essential information: purpose, persistence, parameter guidance, and cleanup. No redundant or filler content.
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 complexity (session management) and no output schema, the description covers key aspects: return format, persistence, sharing, headed mode, timeout, and cleanup. It does not detail post-session navigation or log retrieval, but these are covered by sibling tools. It is sufficiently complete for an agent to understand and use correctly.
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 100%, so baseline is 3. The description adds value by explaining the effect of 'project' (shared authenticated context) and 'headed' (visible window), which enriches the schema's basic descriptions. 'url' is straightforward, but the added context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('persistent browser session') and clearly states the return values. It distinguishes from sibling tools by emphasizing that the page stays alive for multi-step workflows, which is unique among the sibling list (e.g., close_session, navigate_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?
The description provides clear context: use for multi-step workflows, pass 'project' for shared authenticated context, use 'headed' for visible windows, and close_session when done. It implies when to use but does not explicitly state when not to use or name alternatives, though the sibling tools cover single-step actions.
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, so description carries full burden. Discloses blocking behavior, timeout, and return value {success}. Does not detail error handling on timeout, but sufficient for a simple wait 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?
Two sentences: first states purpose and behavior, second gives usage examples. No wasted words, front-loaded with key info.
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?
Simple tool with 3 parameters and no output schema. Description covers main behavior and return. Could mention timeout result, but adequate given tool simplicity.
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 100%, so parameters are well documented. Description adds value by specifying timeout default and that selector is for disappearance, reinforcing schema meaning.
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 blocks until an element disappears, either removed or hidden. It specifies resources (element) and action (wait for gone), distinguishing it from siblings like wait_for_network.
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?
Explicit use cases are given: 'wait for a modal/dialog to close or a loading spinner to vanish before the next step.' No when-not-to-use or alternatives, but clear context.
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 sampling strategy (one per unique style), explains output fields ('checked' vs 'elements_represented'), and reports against AA/AAA thresholds. No annotations to contradict.
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, front-loaded with purpose, every sentence provides necessary detail without redundancy.
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?
No output schema, but description explains return information (failures per level, counts of checked groups and elements). Sufficient for a tool with 4 parameters and clear behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context about sampling but doesn't detail each parameter beyond 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?
States specific action ('Check WCAG color contrast ratios') and resource ('text elements'). Distinguishes from sibling accessibility tools by focusing on contrast ratios.
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?
Clear context for use (checking contrast against WCAG thresholds) but no explicit when-not-to-use or alternatives mentioned.
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 discloses that clear=true empties the log, which is important, and describes filtering behavior. It doesn't cover rate limits or auth, but for a read operation, this is sufficient.
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?
Three sentences, front-loaded with purpose. Each sentence adds information: what is returned, optional parameters, and usage context. 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 no output schema and no annotations, the description covers the key aspects: return structure, optional filters, clearing behavior, and usage. It is complete for a simple read tool.
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 100%, but the description adds value beyond schema by explaining url_filter is a plain-substring filter (not regex) and that clear=true empties the log. This clarifies usage beyond what the schema provides.
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 specifies the verb (return), resource (network requests on a session), and details what fields are included (URL, HTTP method, status, resource type, size). It distinguishes from siblings like get_interaction_log by focusing on network requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description ends with 'Use to see which API calls fired and their status when debugging,' providing clear context. It doesn't explicitly exclude alternatives, but the sibling tools like wait_for_network or intercept_network have different purposes; the description implies debugging use.
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 the description carries full responsibility. It discloses that console/network recording attaches instantly but notes a limitation about early traffic. It also mentions the return structure. It does not cover permissions or error conditions, but the key behaviors are explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph that front-loads the primary action. Every sentence adds information, including a technical limitation. No redundancy.
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 no output schema, the description specifies return values (session_id, url, title). It covers behavior, usage, and a limitation, making it complete for a tool of moderate complexity.
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 100%, but the description adds useful context beyond schema: for the index parameter, it explains 'call without index to list them first'. This aids proper usage.
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 purpose: 'Adopt a popup or new tab... as a NEW session id you can drive with every normal tool'. It distinguishes itself from sibling tools like open_session and navigate_session by specifying it handles popups and new tabs, which is unique.
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?
Provides clear context for when to use: when a popup or new tab is opened. It instructs to call without index to list multiple popups. It does not explicitly state when not to use, but the purpose is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It discloses that a throwaway page is used and closed, and that never-idle pages are flagged (wait_downgraded) not errors. It also explains authentication context differences with/without project. Could mention failure modes but overall well-transparent.
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 multi-sentence but each sentence adds value. It is well-structured: core function first, then behavior, return format, parameter usage, and alternatives. Not overly verbose, but could be slightly more concise.
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 no output schema, description explains return structure (status, title, screenshot path, issues with details). It also covers edge cases like never-idle flags. However, it omits potential error conditions (invalid URLs, timeouts). Overall adequate for the tool's complexity.
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 100%, so description adds value beyond schema. It elaborates on checks types and explains the project parameter's effect on authentication context, enhancing understanding beyond the schema's terse descriptions.
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 purpose: screenshot and audit a single URL in one shot, opening and closing a throwaway page. It specifies the verb (screenshot and audit), resource (URL), and distinguishes from siblings like run_checks_on_session by emphasizing the one-shot nature.
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 provides explicit guidance: use for a single URL with optional checks, pass project for authenticated pages, and for multi-step flows or repeated checks use a session instead. This clearly differentiates from alternatives.
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, the description carries full burden and excels: it explains default readability extraction, static vs headless rendering, TLS verification, contains filtering mode, save behavior, and aliases. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is front-loaded with the main purpose. Every sentence adds value, though it is somewhat long. Could be slightly more structured, but remains reasonably concise for the complexity.
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?
Although there is no output schema, the description covers many aspects: conditional return with contains, saved_path from save, and format options. It lacks an explicit return structure, but is fairly complete given the tool's complexity.
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 100%, but the description adds significant value by explaining parameter contexts (e.g., 'Slower than static' for render, 'contains_mode any|all', alias for raw_html). It enriches understanding beyond the schema 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 tool fetches a URL and returns clean readable content, with Markdown as default. It distinguishes from siblings by mentioning token savings and the ability to render SPAs, and contrasts with raw text or HTML via format options.
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?
Provides clear guidance on when to use various parameters like render for SPAs, format for output type, contains for filtering, and project for authenticated pages. However, it lacks explicit 'when not to use this tool' guidance compared to siblings like get_page_html.
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?
Describes key behaviors: no early abort, complete pass/fail picture, and per-assertion results with actual values. Since no annotations exist, this transparency is valuable, though it could mention error handling or session impact.
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 and a recommendation. It front-loads the core purpose and adds no redundant information, earning every sentence.
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 no output schema, the description provides sufficient output details (overall passed, failed_count, per-assertion results). It could be more complete by noting return format or limitations, but it's adequate for a batch assertion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds that each item takes the same fields as assert_condition, linking the input structure to a known sibling. This goes beyond the schema's standalone descriptions.
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 is for batch assertions, evaluating many conditions in one call and returning every verdict. It contrasts with the sibling tool assert_condition, making its purpose distinct and specific.
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?
Explicitly recommends preferring this tool over sequential assert_condition calls when verifying a state with 2+ expectations. This provides clear guidance on when to use it versus the sibling.
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?
Describes core behavior (mock responses via URL substring, once option) and return value, but omits details like intercept lifetime (until cleared or session ends) and behavior when multiple intercepts match. No annotations provided, so description carries full burden.
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: first defines purpose, second provides usage guidelines and parameter note. Every sentence is essential and well-structured.
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, usage, key parameter, and return value. Lacks discussion of error cases or behavior with multiple matches, but sufficient for a mocking tool. No output schema or annotations to supplement.
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 100%, so baseline is 3. Description adds value by clarifying url_pattern is a plain substring (not regex), explaining the 'once' parameter's effect, and noting defaults.
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 mocks API responses by intercepting network requests matching a URL substring, specifying customizable status, body, and content-type. It distinguishes from siblings like clear_intercepts and emulate_network.
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?
Explicit guidance on when to use (forcing error/loading states), ordering (call before triggering action), and cleanup (clear_intercepts). Also documents the 'once' parameter's purpose.
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 are provided, so the description carries full burden. It thoroughly describes behavior: 'status' and 'agents_md' are read-only, 'update' is dry-run by default, apply=true runs updater but new code loads only after restart, and managed installs refuse update with guidance. No contradictions.
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 fairly long but well-structured: a summary sentence followed by bullet points for each action. It is front-loaded and contains no unnecessary details. Slightly verbose but efficient.
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 no output schema, the description compensates by explaining return values for 'status' (version, capabilities, etc.) and 'agents_md', and the behavior for 'update'. It covers all three parameters and is complete for a system maintenance tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds value by explaining each action's behavior and the context for 'apply' and 'force' parameters. For example, it clarifies that 'apply' defaults to false and 'force' is for auto-stashing modifications.
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 is a self-maintenance tool for install status, self-update, and fetching the agent guide. It lists three distinct actions ('status', 'agents_md', 'update') each with specific details, making it distinct from sibling tools which are all about testing and web interaction.
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 usage for maintenance tasks such as checking version, updating, or refreshing the agent guide. It does not explicitly state when not to use or compare to alternatives, but the context of sibling tools makes the use case clear.
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, description bears burden. It explains recording video, return format, and step compatibility. Could mention session management or side effects, but overall 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: first states purpose, second clarifies steps format, third provides usage guidance. No unnecessary 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?
Covers output, steps format, project behavior. Lacks potential limits like max recording length or error handling, but adequate given schema coverage.
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 covers all 3 params with descriptions. Description adds value by clarifying steps format (same as interact_and_test) and project parameter behavior (shared vs isolated context).
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 clearly states the tool runs steps while recording a video and returns .webm file path. It distinguishes from interact_and_test by specifying that it's for visual artifact/repro, not assertions.
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?
Explicitly says to use for visual artifact/repro and to use interact_and_test for assertions/checks, providing direct contrast and 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?
Without annotations, the description carries full burden and discloses key behaviors: it returns a new session ID, the parent session remains active, and the returned session must be closed. It does not mention error cases (e.g., iframe not found, nested iframes), but overall it provides sufficient transparency for typical use.
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 concise (three sentences) and front-loaded with the main action. Every sentence adds value: the first explains what the tool does, the second gives usage instructions, and the third explains the necessity. 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's moderate complexity and the absence of an output schema, the description covers purpose, usage, return value, cleanup, and rationale. It lacks error handling details but is complete enough for an agent to use correctly. The presence of many sibling session tools makes the distinction valuable.
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 100% with both parameters described. The description adds meaning by clarifying that session_id is the parent session ID and that the tool returns a new session ID for the iframe. Though it does not explicitly reiterate schema fields, it integrates parameter roles into the narrative, providing context 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's purpose: switching into an iframe and returning a new session ID scoped to that iframe's content. It uses specific verbs and resources, and distinguishes itself from sibling tools like open_session or navigate_session by explaining the iframe-scoping behavior.
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 provides explicit guidance: use the returned session for elements inside the iframe, keep the parent session for page-level actions, and close the returned session when done. It also explains why this tool is necessary (cross-frame content unreachable via parent selectors), helping the agent decide when to use it over 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. Description discloses that credentials are stored not executed, and requires a separate call to login_project. It also specifies the return value. This is transparent, though could mention overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with the core purpose, followed by important usage notes and distinctions. Every sentence provides value.
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 simplicity (3 params, no output schema) and the sibling tools, the description covers key aspects: storage vs execution, return type, and usage distinction. Missing details like overwrite behavior are minor.
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 100%, so baseline is 3. Description adds context that the browser sends credentials on every request in the project's context, which enhances understanding beyond the schema descriptions.
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 clearly states the verb 'Configure' and resource 'HTTP Basic Auth credentials for a project'. It distinguishes itself from set_form_login, which handles HTML login forms, providing clear differentiation.
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?
Explicitly states when to use: for browser Basic-Auth prompts. Clearly indicates what not to use for: HTML login forms, directing to set_form_login. Also instructs to call login_project to apply credentials.
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 burden. It discloses that config is stored not executed, returns {success}, and selectors are auto-detected but overridable. Lacks mention of error conditions.
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?
Three sentences, front-loaded with purpose, no superfluous text. Each sentence adds value.
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, usage order, and alternatives. No output schema, but return value is simple. Could mention prerequisites like project existence, but adequate given complexity.
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 has 100% coverage with descriptions, but description adds context about auto-detection and overriding of selectors, going beyond 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 it configures username/password form login, distinguishes from 'interactive_login' and 'login_project', and specifies stored not executed.
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?
Explicitly says use for standard HTML login forms, tells to call 'login_project' afterwards, and suggests 'interactive_login' for 2FA/SSO/CAPTCHA.
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 full burden. It discloses that the project is persistent (saved to disk) and returns the stored config. It doesn't mention behavior on duplicate names or error conditions, but the core behavior is well-covered.
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: the first is front-loaded with the core purpose and key details, the second provides immediate action guidance. Every word earns its place; no repetition or fluff.
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 5 parameters, no output schema, and no annotations, the description provides a complete picture: what the tool creates, how it's used in the workflow, and what it returns. It explains the lifecycle and integration with sibling tools thoroughly.
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 100%, so baseline is 3. The description adds value by explaining the parameter purpose in context (e.g., 'crawl limits' for max_depth/max_pages, 'reused by crawl_project, test_project' for the project concept). This goes beyond the schema's individual field descriptions.
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 creates a persistent testing project for a website/web-app target, specifying it's saved to disk and reused by other tools. It distinguishes itself from siblings like crawl_project and test_project by emphasizing its role as the initial setup step.
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?
Explicitly says 'Create this first, then attach auth... and run tests', providing clear sequential guidance. It also lists specific sibling tools for subsequent steps (set_form_login, set_basic_auth, set_cookies), helping the agent understand when to use this tool versus 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?
With no annotations provided, the description carries full burden. It clearly states the tool does not capture a new image (read-only retrieval), specifies the return format including success, url, and screenshot_path. It lacks details on error conditions or path existence, but the core behavioral traits are 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return, second gives usage guidance and disambiguation. Every word is informative and necessary. No filler or redundancy.
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 2 parameters and no output schema, the description covers purpose, return structure, usage context (must be previously tested), and disambiguation. It is fully adequate for an agent to select and invoke the tool correctly.
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 100%, so the schema already provides basic descriptions. The description adds value by relating parameters to the prerequisite test_url/test_project process, providing context beyond the schema. This helps the agent understand that the URL must have been tested previously.
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 gets the saved screenshot file path for a previously tested URL in a project. It uses a specific verb 'Get' and resource 'saved screenshot file path', and distinguishes itself from sibling tool screenshot_session by explicitly noting it does not capture a new 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use this after test_url/test_project to retrieve the screenshot, and use screenshot_session instead for capturing a new image. This clearly tells when and when not to use the tool, and names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses return values (elapsed_ms, measures, interaction_to_next_paint_ms) and explains three modes and their behaviors, including a warning about fast responses. However, it does not explicitly mention side effects of the click or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is well-structured with three modes listed, informative but not overly concise; it could be slightly more terse.
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 no output schema, the description explains return values. It covers three modes thoroughly, handles complexity of timing, and is complete for a tool with 4 params (2 required).
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 100%. The description adds context to parameters: for wait_for it says 'measure until it appears', and for wait_for_network it explains the timing mechanics and arms before click. This adds meaning beyond schema descriptions.
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 clicks an element and measures time until result settles, and distinguishes three modes. It is specific and distinct from sibling tools like click_element, wait_for_network, etc.
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 tells when to use each mode: 'use this for buttons whose handler fires a request asynchronously', 'measure until it appears', and 'default measures to the first network-idle window'. It also contrasts with plain network-idle.
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, but description discloses that cookies are stored, not injected, and that Playwright requires domain+path pair. This adds 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?
Two sentences, front-loaded with purpose, then key details. No wasted 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?
Despite no output schema, description mentions return {success}. Covers purpose, parameters, behavior, and distinguishes from many sibling tools. Complete for the task.
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 100%, but description adds meaning: default path '/', each cookie needs name+value+domain, and Playwright requirement. This enhances 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?
Description uses specific verb 'seed' and resource 'project with session cookies', clearly stating its purpose to skip interactive login. It distinguishes from siblings like get_cookies or login_project by stating it stores cookies for later injection via login_project.
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?
Explicitly says 'Stored, not executed: call login_project to inject them', providing clear when-to-use and alternative. Also gives context: cookies copied from a logged-in browser.
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 the description carries the full burden. It discloses that the resize persists for later actions and returns the new size and screenshot. It lacks details on potential side effects (e.g., invalid parameters), but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence states the core action and outcome, the second provides usage context and sibling differentiation. Every sentence is essential.
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 no output schema, the description explains the return (new size, screenshot). It also covers persistence. With 5 parameters, it provides enough context for an agent to use the tool effectively.
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 100%, baseline 3. The description adds value by explaining device presets with dimensions and elaborating on the observe parameter options (screenshot, none, map, checks), which goes beyond the schema's enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resizes a viewport and takes a screenshot. It distinguishes itself from sibling tool 'test_responsive' by noting that this resizes an ongoing session while the sibling opens throwaway pages.
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 says to use this to test responsive layouts inside an ongoing session and contrasts it with test_responsive, which opens throwaway pages, providing clear when-to-use and alternative.
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?
Details deterministic crawling, sitemap-seeding, return values including edge cases like auth_lost and pages_not_tested, and safety ceiling for max_pages=0.
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 that front-load purpose and each sentence adds critical information without waste.
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?
Comprehensive for a tool with no output schema; covers purpose, parameters, return types, edge cases, and mentions related tool for reloading.
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 100%, so baseline 3; description adds value by explaining behavior like auth_lost and deterministic crawl, raising to 4.
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?
Clearly states 'Full-site audit' with specific verb 'crawl' and 'run checks', distinguishing from siblings like 'crawl_project' by emphasizing saving a report and deterministic behavior.
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?
Provides context for reliable before/after comparisons, but does not explicitly state when not to use or list alternatives beyond mentioning get_report.
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 provided, but the description fully discloses behavior: returns only truthy state fields, flags unnamed elements, caps output at max_nodes with a truncated flag. It describes the compact output format and the fact that it is read-only.
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?
Well-structured and front-loaded with the main purpose. The description is slightly verbose but each sentence adds necessary detail. Could be trimmed slightly but overall efficient.
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?
No output schema, but the description fully explains the return format: ensures agent knows what data is returned (ARIA role, accessible name, live state, CSS selector), how it's organized (document order), special flags (unnamed, hidden, truncated). Complete for agent to understand the tool's output.
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 100% with good descriptions, but the description adds value: explains that max_nodes acts as a cap and that 'total' reports how many exist, and clarifies include_hidden's effect (flagged hidden). These enrich 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 it returns a semantic page map of interactive elements, landmarks, and headings in document order, with ARIA roles and accessible names. It distinguishes itself from get_page_elements by being a single call, and from find_element by providing a comprehensive map.
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?
Explicitly states when to use: 'use it to orient before clicking instead of multiple get_page_elements calls.' Provides clear context for its role as a fast orientation tool.
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?
Without annotations, the description fully discloses behavior: it prepares captures by neutralizing sticky headers, disabling animations, emulating reduced motion, forcing scroll-reveal sections visible, and reports these in capture_prep. It also explains the raw parameter for unprepared stitches. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no redundancy. It front-loads the purpose, then explains options, behavior, and usage guidance in a logical flow. Every sentence adds distinct value.
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 description covers purpose, usage, behavior, and parameter semantics adequately for a 4-parameter tool with no output schema. It mentions return value (image path) but does not detail error conditions or prerequisites beyond an implicit active session. Still, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are already well-described. The description adds minor but useful context, e.g., 'for citing evidence' for selector and clarifying raw's effect on full-page captures. This justifies a baseline 3 plus incremental value.
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 screenshots the session's current page as-is, with 'no actions performed.' It distinguishes from interactive tools that already return screenshots, and specifies full-page vs viewport capture. The verb and resource are 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'use to grab state at a point in a workflow' and warns 'don't call this after every step' because interactive tools already return screenshots. This provides clear when-to-use and when-not-to-use guidance, effectively distinguishing it from sibling tools.
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 provided, but description fully discloses blocking behavior, timeout, return values (URL/status/method), and plain substring matching. Also explains integration with click events.
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, no wasted words. Front-loaded with core behavior, second sentence adds important context and alternatives.
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 blocking nature, schema coverage, and no output schema, description explains returns and common pitfalls (regex, interaction with click). Complete for an agent.
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 100%, but description adds crucial details: url_pattern examples and regex warning, method filter purpose, timeout default. Exceeds baseline.
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 clearly states the tool blocks until a network request matching a URL substring completes. It distinguishes from sibling tools like get_response_body and get_network_log by noting they are for after-the-fact reading.
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?
Explicit guidance: use with interact_and_test for click-triggered requests, and use get_response_body/get_network_log for after-the-fact. Clarifies url_pattern is plain substring, not regex.
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:
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/segentic-lab/periscope-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server