web-speed-agent

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation5/5
Each tool targets a distinct function: browser setup, navigation, interaction, page reading, waiting, workspace-specific actions, and JavaScript evaluation. Potential overlaps like get_page_info vs. read_page are clearly differentiated by purpose, and workspace_write vs. fill_field explicitly address different editor types.
Naming Consistency4/5
Most tools follow a snake_case verb_noun pattern (store_credential, setup_browser, open_browser, read_page, fill_field, close_browser). Minor deviations include 'account_info' (noun_phrase), 'workspace_write' (reversed verb_noun), and 'workspace_new_slide' (noun_adjective_noun), but these remain clear and readable.
Tool Count4/5
With 17 tools, the set is slightly on the heavier side but each tool serves a specific need for a browser automation agent. The count feels reasonable for the breadth of capabilities offered, including credential storage, setup, navigation, interaction, waiting, and specialized workspace support.
Completeness4/5
The toolset covers the core lifecycle of browser automation: opening, navigating, interacting, extracting data, and closing. It also includes helpful utilities like waiting and JavaScript evaluation. Minor gaps such as screenshot capture or direct dropdown selection are missing but can be worked around with existing tools.
Average 4.4/5 across 17 of 17 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the 1 Web Speed credit cost, the WEBSPEED_API_KEY requirement, and the type-aware JSON return format. It doesn't explicitly state that it's read-only, but 'extract' implies non-destructive, which adds context beyond typical minimal descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with the primary action, uses a clear bulleted list for output types, and ends with cost/auth requirements. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool with an output schema, the description is quite complete: it explains the API source, return format, cost, and auth. The only notable gap is the lack of page_type parameter explanation, but the optional nature and default 'auto' mitigate this. Overall, it's nearly comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'page_type' parameter at all. The output types (article, product, etc.) hint at possible values, but there is no explicit mapping or guidance on how page_type affects the extraction, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts structured data from the current page, with specific output types. It is a clear, specific verb+resource, but it doesn't explicitly distinguish itself from sibling tools like get_page_info or evaluate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need structured data from a page—but doesn't provide explicit when-to-use/when-not-to-use guidance or mention alternatives. The output type examples give some context, but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. The verb 'Check' suggests a read-only operation, but it does not explicitly state that it is non-destructive or whether it consumes API credits. No side effects or authentication requirements are mentioned, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. Every word adds value, and there is no fluff or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an existing output schema, the description is complete. It states what the tool does without needing to explain return values. The simplicity of the tool means no additional context is required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any. The baseline for 0 params is 4, and the description adds no irrelevant parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly identifies the resource: 'Web Speed API credit balance and account status.' It distinguishes this tool from all siblings, which are browser automation tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it does, but it does not explicitly say when to use it or mention alternatives. Since no sibling tool serves a similar function, explicit exclusion is unnecessary, but context like 'before making API calls' is missing.
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 behavioral burden. It explains credential sources and selector auto-detection, but omits important traits like side effects (e.g., navigation after submission), error handling, or what happens if both credential modes are provided. It's adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then credential options, selector behavior, and a navigation prerequisite. Every sentence is informatively dense with no fluff, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, 0 required, no schema descriptions) and no annotations, the description covers essential aspects: credential modes, selector fallback, and navigation prerequisite. The output schema exists, so return values are covered elsewhere. Minor gaps like conflict resolution remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the two credential modes (site vs username/password) and the selector auto-detection logic. It adds meaning to the parameters without listing each one, but effectively ties them to usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fill a login form and submit it.' It specifies the resource (login form) and the action (fill and submit), distinguishing it from generic fill_field or submit_form tools by focusing on login-specific behavior and credential handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit context: 'Use navigate() to go to the login page first' and explains credential options (site OR username/password). It doesn't name alternatives explicitly but implies the tool is for login forms, which is sufficient guidance given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds critical context that credentials are stored locally and never sent to a server, which is a key behavioral trait. Nevertheless, it does not disclose behavior for duplicate site entries or overwrites, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, and every sentence adds value: local storage claim, security guarantee, and parameter guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter keychain storage tool, the description effectively covers the main context—what it saves, where it saves it, and how to identify the site. The presence of an output schema reduces the need to explain return values, but the description could still clarify behavior for existing credentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides a clear example for the 'site' parameter ('indiehackers', 'twitter', 'gmail') and ties the parameters together as 'login credentials.' However, it leaves 'username' and 'password' entirely to their self-explanatory names, offering no additional constraints or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Save login credentials to the system keychain.' It also distinguishes itself from sibling browser automation tools by specifying a local system keychain, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool—for securely storing credentials locally—and emphasizes that credentials are never sent to a server, which indirectly advises against use for server-side storage. However, it does not explicitly mention alternative tools or exclusions, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that Chrome connects to an existing window if debug port is active, otherwise returns a helpful message, and that Firefox imports cookies read-only. However, Edge behavior is not described, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line purpose and uses sections for readability. It is somewhat lengthy with decorative dividers, but every section contributes useful information about browser behavior and overrides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameter semantics are strong, the description omits Edge-specific behavior despite listing 'edge' as a valid browser, and it doesn't clarify whether Chrome falls back to a fresh Playwright session when the debug port is unavailable. The output schema exists, so return values need not be explained, but these gaps prevent full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full semantic meaning for every parameter in the Args section, including defaults (headless=False, cdp_url=localhost:9222) and special values (browser options, profile_path='auto'). This far exceeds the schema's bare structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Open a browser for automation,' a specific verb+resource statement. It clearly explains browser types and distinguishes itself from siblings like navigate and close_browser by focusing on the browser lifecycle and connection 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides thorough context on when to use different modes: CDP for Chrome, fresh Playwright for Firefox, and manual overrides for custom profiles and CDP URLs. It does not explicitly exclude alternatives like setup_browser, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool returns once the URL matches or the timeout expires, which is useful. However, it does not disclose what happens on timeout (e.g., throws an error, returns false) or other details like case sensitivity, leaving some ambiguity for a simple wait operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core functionality, the second provides usage context, and the arguments are listed clearly. Every sentence earns its place, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple scope (2 parameters, 1 required) and an output schema exists, so return value details are not needed. The description covers usage scenario, parameters, and termination behavior. A minor gap is that timeout failure behavior is not specified, but overall the description is sufficiently complete for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only titles with no descriptions, giving 0% schema description coverage. The description fully compensates by explaining both parameters: url_contains as the substring the URL must contain with examples, and timeout_ms as the maximum wait time in milliseconds with the default value. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to wait for the page URL to contain a given substring. It specifies the resource (page URL), the condition (contains substring), and the action (wait). This distinguishes it from sibling tools like wait_for_element, which waits for a DOM element, and navigate, which changes the URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use after clicking an SPA navigation link where the URL changes client-side without a full page reload. This provides clear context for when to use it. It implicitly excludes full-page reload scenarios but does not explicitly name an alternative tool or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It clearly states the outputs (URL, title, visible text snippet) and implicitly signals a read-only, non-mutating operation. While it does not explicitly mention side effects or prerequisites, the purpose-oriented language ('confirm where the browser is') adds useful behavioral context beyond a bare description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. The first sentence states the action and outputs, the second provides usage guidance. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is nearly complete. It states what is returned and when to use it. It could mention that an active browser session is required, but the phrase 'current page' implies this. Overall, it is sufficient 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema description coverage is effectively 100%. Per the rubric, 0 params warrants a baseline score of 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' with concrete resources (URL, title, visible text snippet), making the tool's function clear. It also distinguishes from siblings like navigate (changes location) and read_page (likely extracts more detailed content) by framing it as an orientation helper to confirm the browser's current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful for orientation — call this to confirm where the browser is.' It explains when to use the tool but does not explicitly state when not to use it or mention alternative tools. This fits 'clear context, no exclusions' (score 4).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the behavior of returning title and final URL, and importantly explains the 'spa_redirect' warning for redirects. It does not mention error handling or side effects, but the disclosed behavior is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a clear usage note and parameter list. Every sentence contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema means return values need not be described. The main behavior and redirect handling are covered, making the tool usable. Minor gaps like error scenarios remain, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions, so the description compensates by explaining both 'url' and 'expect_url_contains'. The 'expect_url_contains' explanation adds detailed context about redirects and warnings, which is valuable beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Navigate to a URL and return the page title and final URL.' This specifies the verb (navigate), the resource (URL), and the outputs, distinguishing it from siblings like open_browser or read_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Always call this before interacting with a new page' provides explicit contextual guidance. It does not name alternative tools for exclusion, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the two execution paths (clicking submit or pressing Enter) and the fallback behavior when selector is omitted. While it does not mention side effects like page navigation, the described actions are specific and unambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-sentence purpose followed by an explicitly labeled argument explanation. No redundant information is present; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core action and parameter semantics fully. An output schema is present, so return values need not be explained. It could optionally mention prerequisites (e.g., a form must be present), but the tool is straightforward and adequate as is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies 'selector' as a nullable string with a default null. The description's Args section adds essential semantics: it defines the selector as targeting a submit button or form and describes the fallback to pressing Enter when omitted. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Submit' targeting a form resource, clearly distinguishing it from sibling tools like 'click' and 'fill_field'. It states the action and the two mechanisms (clicking submit button or pressing Enter), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly defines the context for use (submitting a form) and details the behavior with and without a selector. It does not explicitly contrast with alternative tools like 'click' or mention when not to use, but the context is clear enough for an agent to choose this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the return behavior ('Returns ok once the condition is met') and defines all four possible states with their semantics. It does not mention timeout error behavior, but for a simple wait operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro sentence and a clear Args list. It is somewhat verbose but every detail (state definitions, timeout default) is useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to explain return values. It covers when to use, all parameter semantics, and state behaviors. For a moderately simple wait tool, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: selector, timeout_ms including default, and state with all allowed values and their meanings. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Wait for an element to reach a given state') on a specific resource (page element). It clearly differentiates from sibling tool 'wait_for_url' by focusing on element state rather than URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Useful after an action that triggers async loading, modal opening, or element removal.' It does not explicitly mention alternatives or exclusions, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, this operational detail—dropping the pointer-events lock, clicking the toolbar button, settling—discloses what the tool does beyond a mere 'adds a slide,' giving the agent context about side effects like lock state and UI interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the main purpose front-loaded and the implementation details in one concise second sentence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description fully explains the action, the behavioral prerequisites, and the recommended follow-up. It's sufficient for an agent to invoke and integrate into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description doesn't need to explain any. It also references the parameter for the subsequent workspace_write call, providing additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Add a new slide in Google Slides,' and also provides the keyboard shortcut equivalent (Ctrl+M), which uniquely identifies the tool's scope among generic browser automation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on the operational sequence—dropping the pointer-events lock, clicking the button, and settling—and explicitly directs the caller to use workspace_write afterwards. However, it doesn't state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It reveals important timing behaviors: wait_for_navigation defaults to True, wait_for waits up to 5 seconds for an element to appear, and wait_ms adds extra delay for SPA hydration. It does not mention error handling (e.g., element not found), but the disclosed timing semantics are valuable and not obvious from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary followed by a tagged list of arguments. Each parameter explanation is concise and directly useful, with no fluff. The format is scannable and front-loads the core purpose before diving into details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, one required), the description covers all key aspects: what the tool does, when to use different waiting strategies, and how to handle async UI changes. It provides enough context for an agent to invoke the tool correctly in common scenarios. The presence of an output schema means return values do not need to be described here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage — parameters only have titles and defaults. The tool description compensates fully by explaining each parameter in detail: selector (the CSS selector), wait_for_navigation (with guidance on when to set False), wait_for (with its 5-second timeout), and wait_ms (with use cases like SPA hydration). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Click an element by CSS selector.' This identifies both the action (click) and the resource (element by CSS selector), distinguishing it from sibling tools like fill_field, submit_form, and navigate. There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance on parameter usage, such as setting wait_for_navigation to False for 'clicks that trigger in-page UI changes like modals, dropdowns, or expanding sections' and using wait_for when 'the click opens a modal or triggers async UI rendering.' It does not explicitly name alternative tools, but the context for when to use this tool is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the return value is JSON-serialised and included in the response, and that the JS runs in page context. However, it does not mention whether promises are awaited or if there are timeouts, so it's not fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose sentence, a bulleted list of example uses, and an Args section. It's longer than necessary but every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations but an output schema, the description covers purpose, usage, and parameter semantics well. The output schema likely details the return structure, so the description's note about JSON-serialised results is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says js is a string. The description explains it is a 'JavaScript expression to evaluate', notes the return value is JSON-serialised, and advises simplicity. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: 'Run JavaScript in the page context and return the result.' It also lists concrete use cases (Shadow DOM, iframes, hidden data) that distinguish it from sibling automation tools like click and fill_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames when to use this tool: 'Use this to handle situations standard selectors can't reach' and gives examples. It also advises to keep expressions simple, implying that complex logic should be split into multiple calls.
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 side effects: in CDP mode it closes the tab and disconnects but leaves Chrome running; in standard mode it saves the session (if named) and closes the browser. This is transparent and goes beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, presenting the core action first, then breaking down behavior by mode. Every sentence provides valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is complete: it explains the outcome in both operating modes, addresses session persistence, and clarifies that only the agent's tab is closed. The existence of an output schema means the return value does not need to be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no semantics to explain. The description provides necessary mode-related context that the schema (empty) cannot convey. Baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Close the tab and disconnect from the browser.' It distinguishes between CDP and standard modes, making the scope explicit (closes only the tab the agent opened) and differentiating it from siblings like open_browser and navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains behavioral context by describing what happens in each mode (CDP vs standard), which implicitly tells the user when this tool is appropriate. It does not explicitly mention alternatives, but for a cleanup/teardown tool the usage is clear from the name and 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?
With no annotations, the description carries full behavioral burden—and it excels. It details the simulated keystroke event sequence (keydown→keypress→input→keyup), explains that \n is stripped and a trailing \n acts as Tab, and clarifies delay_ms for sites checking typing cadence. It also reveals why keyboard mode is needed for frameworks that ignore programmatic value changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and bullet lists. It is moderately long but every sentence carries useful information; the X/Twitter-specific recipe is somewhat niche but relevant. No wasted words, and the layout aids scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, five parameters), the description is thorough. It covers behavioral edge cases (\n handling, Tab emulation), parameter semantics, and concrete use cases for modern frameworks. Since an output schema is present, not detailing return values is acceptable. An agent has everything needed to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section compensates fully. Each parameter (selector, value, press_tab, use_keyboard, delay_ms) is explained with functional meaning and edge-case behavior. For example, it notes that a trailing \n in value is treated as Tab, and recommends delay_ms 30–80 for cadence checks—details the schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: 'Type a value into a form field.' It then differentiates standard mode from keyboard mode, specifying that keyboard mode is for contenteditable divs and React/Vue inputs. This establishes the tool's unique role among siblings like click and submit_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong conditional guidance: standard mode for plain inputs/textareas, keyboard mode for contenteditable/React/Vue/trusted-event checks. It even gives a specific recipe for X/Twitter. However, it does not explicitly name alternative tools to use instead, nor does it state when *not* to use this tool, so it lacks full exclusionary guidance.
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?
The description discloses all significant side effects: creation of a non-default user data directory, copying cookies, installing shell aliases or .bat files, and modifying .zshrc. It also warns that the browser must be closed, which is critical behavioral context. No annotations are present, so the description carries the full burden and does so comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence earns its place. It is well-structured with clear sections: purpose, step-by-step actions, post-setup usage, re-run instructions, and argument explanation. Information is front-loaded with the core purpose and key requirement (browser closed).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (setup with side effects), the description covers prerequisites, exact steps, post-conditions, re-run scenarios, and the parameter. It also references the subsequent open_browser call, tying it into the broader workflow. An output schema exists, so the lack of return value discussion is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does add meaning by stating the allowed values and default: 'browser: "chrome" (default) or "edge"'. However, it does not explain any behavioral differences between the two options, leaving some nuance undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Set up Chrome or Edge for agent use (macOS and Windows)'. It clearly distinguishes this setup tool from siblings like open_browser and navigate by explaining it creates a dedicated profile and copies cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Run this ONCE (with your browser closed)' and 'Re-run setup_browser() any time you want to sync fresh cookies'. It also instructs the agent to use open_browser afterward with specific parameters, effectively indicating when this tool is a prerequisite.
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 the full burden. It discloses that the tool dismisses side panels, removes onboarding modals, focuses the editor, types with real keystrokes, sends newlines as Enter, and verifies the text. This goes beyond a simple 'types text' and explains underlying behavior and 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with platform-specific subsections and a compact Args list. Every sentence adds value, covering rationale, behavior, and parameters without redundancy. It's detailed yet efficient, front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers why the tool exists, how it works across Docs and Slides, parameter semantics, and when to use alternatives. An output schema exists, so return values are already documented. No important context is missing for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that explains each parameter (text, target, verify, placeholder) with platform-specific detail, e.g., placeholder=N for Slides and verify as best-effort Docs-only. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Type text into a Google Workspace editor (Docs or Slides) reliably.' It distinguishes itself from fill_field/click by explaining they can't place text on canvas, making the tool's niche crystal clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says fill_field/click can't place text on canvas and execCommand is deprecated/flaky, so this tool is the reliable alternative. Also references workspace_new_slide() for adding slides, providing clear when-to-use guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![web-speed-agent MCP server](https://glama.ai/mcp/servers/Dominic-Pi-Sunyer/web-speed-agent/badges/card.svg)](https://glama.ai/mcp/servers/Dominic-Pi-Sunyer/web-speed-agent)

Score Badge

Copy to your README.md:

[![web-speed-agent MCP server](https://glama.ai/mcp/servers/Dominic-Pi-Sunyer/web-speed-agent/badges/score.svg)](https://glama.ai/mcp/servers/Dominic-Pi-Sunyer/web-speed-agent)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dominic-Pi-Sunyer/web-speed-agent'

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