jev-mcp

browser_task

Operate a website autonomously in your logged-in Chrome: provide a start URL and plain-language goals, and the agent performs clicks, selections, and keystrokes within a domain-bound safeguard.

Instructions

Operate a website autonomously in the user's real, logged-in Chrome: open url, then pursue goals written as plain sentences, deciding every click, selection and keystroke without asking. Right for multi-step work on one site: filling a form, walking to a page that is only reachable by clicking, searching inside a site, reading something behind a session the user already has. Wrong for reading one page (use browser_read), for public pages that need no login (use a web fetch or search tool), and for logging in, paying, ordering or submitting anything on a banking or payment site. Never put credentials into goals: the goals and every typed value come back in the result. The run stays on the registrable domain of url and stops when a step would leave it; widen that with allow_domains. Bounded by max_actions (default 25, values above 60 are rejected) and time_budget_s (default 120 s, values above 900 s are rejected); the call blocks until the run ends, and only one run can be in flight at a time, including any run still finishing after its budget ran out. Set dry_run to get the first planned step without executing anything. The underlying agent cannot see into iframes or shadow DOM, cannot do file uploads, cannot follow pop-up tabs, and only observes the visible viewport, so it scrolls but never reads what is not rendered. The result reports the status, the final URL, every executed step and the reason it stopped.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`goals`	Yes
`dry_run`	No
`max_actions`	No
`allow_domains`	No
`time_budget_s`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 21, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden, and it does so thoroughly. It discloses that the call blocks until the run ends, that only one run may be in flight, that the tool runs in the user's real logged-in Chrome, that credentials surface in results, and that the agent cannot see iframes, shadow DOM, pop-ups, or off-screen content. It also states the stop behavior, domain confinement, and result contents.

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 long, but every sentence earns its place for a high-risk autonomous browser tool. It front-loads the core behavior and use cases, then sequences security warnings, constraints, limitations, and result reporting. There is no redundant or filler 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?

For a tool with six parameters, no annotations, an output schema, and substantial side effects, the description is remarkably complete. It covers usage, constraints, concurrency, blocking, security risks, technical limitations, and return-value contents. An agent has everything needed to decide whether to invoke it and how to set its parameters correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameters, and it explains all six. It defines `url`, `goals` as plain sentences with a security warning, `allow_domains` as domain widening, `max_actions` and `time_budget_s` with defaults and rejected bounds, and `dry_run` as planning without execution. No parameter is left to guesswork.

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 specific verb-resource pairing: 'Operate a website autonomously in the user's real, logged-in Chrome,' then names the core inputs `url` and `goals`. It clearly differentiates from sibling tools by naming browser_read as the wrong choice for reading a single page. An agent can understand exactly what this tool does and what distinguishes it from nearby alternatives.

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 gives explicit positive use cases ('multi-step work on one site: filling a form, walking to a page that is only reachable by clicking') and explicit wrong-use cases with named alternatives ('use browser_read', 'use a web fetch or search tool'). It also adds hard exclusions for logging in, paying, or ordering on banking/payment sites and warns against putting credentials into `goals`. This is exemplary routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server