Gemini Web Automation MCP

by vincenthopf

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct and clear purpose with no overlap. browse_web and start_web_task handle synchronous vs. asynchronous browsing, check_web_task monitors progress, get_web_screenshots retrieves visual data, list_web_tasks provides an overview, stop_web_task cancels tasks, and wait manages timing. The descriptions explicitly differentiate their roles, eliminating confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., browse_web, check_web_task, get_web_screenshots). The pattern is uniform across all seven tools, with clear and descriptive names that align with their functions, making them predictable and easy to understand.
Tool Count5/5
With 7 tools, the count is well-scoped for web automation. It covers core operations like starting, monitoring, and stopping tasks, plus utilities like screenshots and waiting, without being excessive. Each tool serves a specific role, ensuring a balanced and functional set for the domain.
Completeness5/5
The toolset provides complete coverage for web automation workflows. It includes task initiation (browse_web, start_web_task), monitoring (check_web_task, list_web_tasks), management (stop_web_task), data retrieval (get_web_screenshots), and timing control (wait). There are no obvious gaps, supporting both synchronous and asynchronous operations effectively.
Average 4.6/5 across 7 of 7 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format in detail, including specific keys like 'ok,' 'tasks,' 'count,' and 'active_count,' which adds value beyond basic listing. However, it doesn't mention potential limitations such as rate limits, session dependencies, or error handling, leaving some behavioral aspects unclear.
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 and front-loaded with the core purpose. It uses bullet points for the return values and includes a note and example, which are helpful. However, some sentences could be more concise, such as 'Shows a summary of all tasks in the current session,' which slightly repeats the initial statement, but overall it's efficient and informative.
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 low complexity (0 parameters) and the presence of an output schema (implied by the detailed return description), the description is quite complete. It explains the purpose, usage, return format, and provides an example and alternative tool. The only minor gap is the lack of explicit behavioral constraints like error cases, but this is mitigated by the output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Since there are no parameters, the baseline is 4, as the description doesn't need to compensate for any gaps and focuses on output semantics instead.
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's purpose: 'List all web browsing tasks, including active and completed ones.' It specifies the verb ('List') and resource ('web browsing tasks'), and distinguishes it from siblings by mentioning 'compact task summaries' versus 'check_web_task(task_id) for details.' However, it doesn't explicitly differentiate from other list-like siblings if any existed, but since none are present, it's 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'Shows a summary of all tasks in the current session. Useful for tracking multiple concurrent browsing operations.' It also gives an explicit alternative: 'Use check_web_task(task_id) for details.' However, it lacks explicit exclusions or comparisons to other siblings like 'browse_web' or 'start_web_task,' which could be helpful but isn't critical here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves saved screenshots and returns a dictionary with specific fields, including error handling for 'session not found.' However, it lacks details on permissions, rate limits, or whether the operation is read-only or has side effects, which are important for a tool interacting with session data.
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 a clear purpose statement, usage context, parameter details, return values, and an example. It is appropriately sized, but the example could be integrated more seamlessly, and some sentences like 'Each browsing session saves screenshots...' slightly extend beyond strict necessity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema (implied by the Returns section), the description is mostly complete. It covers purpose, usage, parameters, and return values. However, it lacks details on behavioral aspects like error conditions beyond 'session not found' or performance considerations, leaving minor gaps.
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 description coverage is 0%, so the description must compensate. It explicitly documents the single parameter: 'session_id: Session ID returned from browse_web or check_web_task,' adding crucial meaning by specifying the source of the session_id and its purpose, which the schema alone does not provide.
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: 'Retrieve screenshots captured during a web browsing session.' It specifies the verb ('retrieve'), resource ('screenshots'), and context ('web browsing session'), distinguishing it from siblings like browse_web or check_web_task by focusing on post-session retrieval rather than active browsing or task management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Each browsing session saves screenshots... Use this to review what the AI agent saw and did during task execution.' It implies usage after a session has ended, but does not explicitly state when not to use it or name alternatives, such as checking if a session exists first.
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 effectively describes key traits: the task runs asynchronously in the background, returns immediately, requires monitoring with check_web_task, and has a default URL. However, it doesn't mention potential errors, timeouts, or resource limits, leaving some behavioral aspects uncovered.
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 and appropriately sized, with clear sections (purpose, args, returns, examples, next steps). Every sentence adds value, such as explaining asynchronous behavior, providing usage examples, and outlining follow-up steps, with no redundant or wasted content.
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 (asynchronous operation with 2 parameters) and the presence of an output schema (which covers return values), the description is complete. It explains the tool's purpose, usage, parameters, and next steps adequately, compensating for the lack of annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful context for both parameters: 'task' is described as 'What you want to accomplish on the web' with examples, and 'url' is clarified as the 'Starting webpage (defaults to Google)'. This goes beyond the basic schema types, though it could provide more detail on URL formatting or task constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start a web browsing task in the background') and resource ('web browsing task'), distinguishing it from siblings like browse_web (likely synchronous) and check_web_task (monitoring). It explicitly mentions returning immediately and running asynchronously, which differentiates 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('for tasks that might take a while (30+ seconds)'), when not to use it (implied for shorter tasks), and alternatives (check_web_task for monitoring progress). It also specifies prerequisites like waiting 5 seconds between checks, making usage context 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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: immediate halting of execution, cleanup of browser resources, and constraints on stopping completed/failed tasks. However, it doesn't mention potential side effects like data loss or error handling details beyond the return structure.
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 and front-loaded with the core purpose, followed by usage guidelines, parameter details, return values, examples, and constraints. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 (a destructive operation with one parameter), no annotations, and the presence of an output schema (which covers return values), the description is complete. It explains purpose, usage, parameters, returns, examples, and constraints, leaving no significant gaps 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides clear semantics for the single parameter (task_id from start_web_task()) and includes an example. While it doesn't detail format constraints beyond the example, it adds meaningful context 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 clearly states the specific action ('stop', 'halts', 'cancels') and resource ('web browsing task'), distinguishing it from siblings like check_web_task, list_web_tasks, or wait. It explicitly mentions the tool stops a 'running' task, which differentiates it from tools that might handle completed or failed tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when you need to cancel a long-running task that's no longer needed') and when not to use it ('Cannot stop tasks that are already completed or failed'). It also implies alternatives by referencing start_web_task and other siblings for different operations.
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 clearly describes that the tool runs synchronously, returns when the task is complete, and can perform human-like interactions. However, it doesn't mention rate limits, authentication requirements, or potential destructive actions beyond what's implied by 'interact with web pages.'
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 with clear sections (purpose, behavior, args, returns, examples, note). Every sentence adds value, and it's appropriately sized for a complex tool with multiple parameters and return values.
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 (web automation with 2 parameters), no annotations, and the presence of an output schema, the description provides excellent context. It explains the tool's behavior, parameters, return structure, usage guidelines, and includes examples, making it complete enough for an agent to use effectively.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains the 'task' parameter with examples and clarifies that 'url' defaults to Google. 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 clearly states the tool's purpose as 'browse the web to complete a task using AI-powered browser automation' with specific verbs (navigate, click, fill, search, interact) and distinguishes it from sibling tools by mentioning it runs synchronously and returns when complete. It explicitly differentiates from start_web_task for long-running tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for synchronous web browsing tasks) and when not to use it (for long-running tasks, consider using start_web_task instead). It also provides three concrete examples of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains the tool's polling behavior (3-5 second intervals), context management strategy (compact format to avoid bloat), return format variations based on parameters, and provides practical guidance about using the wait() tool for delays.
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 (purpose, args, returns, examples, best practice, workflow) but could be slightly more concise. The 'Best Practice' and 'Recommended workflow' sections contain some redundancy about polling intervals. Every sentence adds value, but some information is repeated.
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 (polling behavior, output variations) and the presence of an output schema, the description provides excellent contextual completeness. It explains the tool's role in the workflow, behavioral constraints, parameter effects, and practical usage patterns while appropriately deferring detailed return structure to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters in detail. It clarifies that task_id comes from start_web_task(), and explains the compact parameter's effect on output format (summary vs full details) with clear examples showing both 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 purpose with specific verbs ('check progress', 'returns a summary') and distinguishes it from siblings by explicitly mentioning it works with tasks created by 'start_web_task()'. It identifies the exact resource being operated on (background web browsing tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (after starting a task with start_web_task, with 3-5 second intervals between checks) and includes a complete recommended workflow. It also distinguishes this from other tools by showing its role in the task lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's behavior, including the wait duration range (1-60 seconds), the return structure (dictionary with ok, waited_seconds, message), and practical constraints like timeout prevention. This goes beyond what the input schema alone provides.
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 and front-loaded, starting with the core purpose, followed by usage guidelines, parameter details, returns, examples, and best practices. Every section adds value without redundancy, and the length is appropriate for a tool with behavioral complexity and no annotations.
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 behavioral complexity (timing, constraints), lack of annotations, and the presence of an output schema, the description is complete. It covers purpose, usage, parameters, returns (though output schema exists, it adds clarification), examples, and best practices, leaving no gaps for an AI 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.
Parameters5/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 fully compensate. It adds significant meaning by explaining the 'seconds' parameter as 'Number of seconds to wait (1-60)', providing the semantic context, valid range, and examples (wait(5), wait(10)), which are not present in the schema's minimal title and type definition.
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 with a specific verb ('wait') and resource ('specified number of seconds'), distinguishing it from sibling tools like check_web_task or start_web_task. It explicitly defines the action of pausing execution, which is distinct from the web-related operations of its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool, listing specific scenarios (e.g., avoiding rapid polling, rate limiting, waiting for external processes) and naming an alternative (check_web_task) in the 'Best Practice' section. It also includes when-not-to-use guidance by specifying a maximum wait time to prevent timeouts.
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:

[![computer-use-mcp MCP server](https://glama.ai/mcp/servers/vincenthopf/computer-use-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vincenthopf/computer-use-mcp)

Score Badge

Copy to your README.md:

[![computer-use-mcp MCP server](https://glama.ai/mcp/servers/vincenthopf/computer-use-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vincenthopf/computer-use-mcp)

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/vincenthopf/computer-use-mcp'

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