How do I use Playwright MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Playwright MCP Go to example.com and tell me the main heading" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Playwright MCP

by 1000carlospena-prog

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Playwright MCP on Render

Deploy Playwright MCP on Render in one click. Get a hosted, headless-Chromium MCP server your AI tools can drive over HTTP — no local browser install, no npx on every machine.

https://github.com/user-attachments/assets/0f31c279-f2e0-431f-a854-50677bd800c5

What it does

Playwright MCP is a Model Context Protocol server that lets an LLM open a real browser, navigate, click, type, and read pages through structured accessibility snapshots (not screenshots). It normally runs locally via npx @playwright/mcp. This template runs it as a single Render web service instead, so any MCP client can connect to a shared HTTPS URL.

It's a thin wrapper over the official mcr.microsoft.com/playwright/mcp image (headless Chromium already baked in) — no source changes. The wrapper adds the flags Render needs (--headless, --no-sandbox, plus --port and --allowed-hosts from the environment) and a small bearer-token gate in front of the server, because Playwright MCP has no authentication of its own.

Authenticated by default. Playwright MCP has no auth in HTTP mode and ships an RCE-equivalent tool, so this template does not publish it directly: requests must carry Authorization: Bearer $MCP_TOKEN, and Render generates that token for you at deploy time. Read Security to understand what that does and does not protect.

For the full tool list, config options, and client setup, see the upstream README.

Related MCP server: Browseagent MCP

Architecture

One Render web service runs the official Playwright MCP image behind a bearer-token gate. An MCP client speaks Streamable HTTP to /mcp over Render's TLS-terminating edge; the gate checks the token and forwards to the MCP server on loopback, which drives a headless Chromium in the same container and returns accessibility snapshots.

┌─────────────┐   HTTPS /mcp    ┌────────────────────────────────────────────────┐
│  MCP client │ ──────────────► │ Render web service  (Docker, standard plan)    │
│ (Claude,    │  + Bearer       │                                                │
│  Cursor, …) │    token        │  render-entrypoint.sh                          │
│             │                 │    │ reads PORT, allowed hosts                 │
│             │  Streamable     │    ▼                                           │
│             │ ◄────────────── │  render-auth-proxy.mjs   :$PORT  (public)      │
└─────────────┘   snapshots     │    │ 401 unless the Bearer token matches       │
                                │    ▼                                           │
                                │  node /app/cli.js  127.0.0.1:8931  (loopback)  │
                                │    │                                           │
                                │    ▼                                           │
                                │  headless Chromium  (baked into base image)    │
                                └────────────────────────────────────────────────┘

How a deploy is assembled:

File	Role
`render.yaml`	Blueprint. Declares the single Docker web service, its plan/region, the `PORT` env var, and the generated `MCP_TOKEN`. This is what the Deploy button reads.
`Dockerfile.render`	Thin wrapper over `mcr.microsoft.com/playwright/mcp` (headless Chromium pre-baked). Adds only the entrypoint and the auth gate — no browser download, no source build.
`render-entrypoint.sh`	Reads `PORT`, resolves the allowed-hosts value, then `exec`s the auth gate with the MCP server (bound to loopback) as its argument.
`render-auth-proxy.mjs`	PID 1. Stdlib-only Node, no dependencies: rejects any request without `Authorization: Bearer $MCP_TOKEN` and rate-limits repeated guessing, forwards the rest to `127.0.0.1:8931`, supervises the MCP server, holds the public port closed until that server accepts, and forwards `SIGTERM`.
`render-auth-limiter.mjs`	The gate's rate limit, kept separate because it is the one piece with state worth testing on its own: a fixed-window cap on failed authentications, counted across all clients. Imported by the proxy, so `Dockerfile.render` has to copy it too.
`render-smoke-test.sh`	Builds the image and checks the wrapper end to end: fails closed without `MCP_TOKEN`, `401` without the header, `429` after repeated bad ones, a handshake and a real browser tool call with the right one, clean `SIGTERM`. CI runs this on every PR.
`.env.example`	Documents the same knobs for running the container locally.

Key properties:

Thin wrapper, no fork of the tool. The Playwright MCP version is pinned by the base-image tag in Dockerfile.render; upgrades are a one-line tag bump (see Rolling Playwright MCP).
No database, no disk, nothing to fill in. The one secret, MCP_TOKEN, is generated by Render at deploy time. The browser keeps upstream's default persistent profile, so logins carry across requests for the life of the instance — convenient for a server that's yours alone, which is what this template assumes (see Configuration).
Authenticated, and fails closed. The gate is added by this template, not upstream. If MCP_TOKEN is unset the container refuses to start, so there is no configuration in which the server is exposed anonymously (see Security).

Prerequisites

To deploy, you need:

A Render account — free to create; the service itself runs on the paid standard instance type (see Deploy).
A GitHub account, to fork this repo (the Deploy button reads render.yaml from a repo you own).

No API keys or third-party accounts are required. The one secret, MCP_TOKEN, is generated for you at deploy time — you only need to copy it into your MCP client (see Deploy).

To also run it locally (optional — see Run locally):

Docker with BuildKit (Docker Desktop 4.x+, or Docker Engine 23+). Dockerfile.render uses a # syntax= directive and COPY --chmod, both BuildKit features.
An MCP client to point at it (e.g. Claude Code, Cursor), or just curl.

You do not need Node.js, Playwright, or a local Chromium — the base image bakes all of that in.

Deploy

Click Deploy to Render above (or fork this repo and create a new Blueprint from it).
Render reads render.yaml and provisions one Docker web service (playwright-mcp) on the standard plan.
Wait for the deploy to go live. Your server is at https://<your-service>.onrender.com/mcp.
Copy MCP_TOKEN from the service's Environment page in the Render Dashboard — Render generated it for you. Your MCP client must send it as Authorization: Bearer <token> (see Using the app); without it every request gets a 401.
Read Security before pointing anything sensitive at it. The token is the only thing standing between the internet and code execution in this container, so treat it like a password — and tighten further if you can.

Plan sizing: headless Chromium OOMs on the free/starter tier (512 MB), so the Blueprint defaults to standard (2 GB). Downgrade only if you've confirmed your workload fits in less.

Using the app

Point any MCP client at your service's /mcp endpoint, sending MCP_TOKEN as a bearer token. For example, with Claude Code:

claude mcp add --transport http playwright https://<your-service>.onrender.com/mcp \
  --header "Authorization: Bearer <your-MCP_TOKEN>"

Or add it to a client config directly:

{
  "mcpServers": {
    "playwright": {
      "url": "https://<your-service>.onrender.com/mcp",
      "headers": {
        "Authorization": "Bearer <your-MCP_TOKEN>"
      }
    }
  }
}

If the client reports a 401, the header is missing or the token doesn't match the current value in the Dashboard.

Then ask your assistant to browse — e.g. "Open example.com and give me the page title and the main heading." It will call the Playwright MCP tools against your hosted browser and return the result.

Run locally

Optional — the deploy path above needs none of this. Useful if you want to change render-entrypoint.sh and see the effect before pushing.

git clone https://github.com/render-examples/playwright-mcp-render.git
cd playwright-mcp-render
cp .env.example .env          # then set MCP_TOKEN, e.g. to `openssl rand -hex 32`
docker build -f Dockerfile.render -t playwright-mcp-render .
docker run --rm --env-file .env -p 10000:10000 playwright-mcp-render

Once ready, the container prints upstream's own Listening on … and then the gate's [auth] Bearer-token gate listening … — in that order, because the gate holds the public port closed until the server behind it accepts, so the last line is the one that means the service is reachable. (The [startup] line above it prints an https:// URL — that scheme is for the deployed service; locally, use http.) Verify the server with an MCP handshake — export the same token you put in .env first, so the header below resolves:

curl -sS -X POST http://localhost:10000/mcp \
  -H "Authorization: Bearer $MCP_TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'

You should get back a serverInfo block naming Playwright; drop the Authorization header and you should get 401 Unauthorized. Point a client at http://localhost:10000/mcp the same way you would the deployed URL.

MCP_TOKEN is the one variable you must supply — the container exits immediately without it. The rest of .env is convenience: outside Render there's no RENDER_EXTERNAL_HOSTNAME, so the entrypoint already falls back to PORT=10000 and --allowed-hosts *.

Prefer to skip Docker entirely? Upstream runs the same server directly: npx @playwright/mcp@latest --port 10000 — note that resolves to whatever npm publishes, not the image tag this template pins, and it has no auth gate (that's this template's addition). That path is also not what Render deploys, so verify changes in the container before you push.

Configuration

Everything is set in render.yaml; .env.example documents the same knobs for running locally.

Env var	Default	What it's for
`PORT`	`10000`	Port the auth gate binds to; Render routes to it.
`MCP_TOKEN`	generated by Render	Required. Bearer token every request must present. The container refuses to start without it. Rotate by editing the value (or clicking Generate again) in the Dashboard and updating your clients.
`UPSTREAM_PORT`	`8931`	Loopback port the MCP server listens on behind the gate. Change only if it collides with something inside the container.

.env.example also lists PLAYWRIGHT_MCP_HOST, PLAYWRIGHT_MCP_HEADLESS, and PLAYWRIGHT_MCP_NO_SANDBOX. These matter only when you run the server directly (outside this image) — on Render, render-entrypoint.sh always passes the equivalent CLI flags, and CLI flags win, so setting them in the Render dashboard has no effect. The one exception is PLAYWRIGHT_MCP_ALLOWED_HOSTS, which the entrypoint does honor.

The entrypoint scopes the server's host check to your service's own onrender.com hostname automatically via Render's RENDER_EXTERNAL_HOSTNAME. If you add a custom domain, requests to it will be rejected by the host check until you set PLAYWRIGHT_MCP_ALLOWED_HOSTS (comma-separated, e.g. myapp.com,myapp.onrender.com; * disables the check).

Browser profile state

The entrypoint passes no profile flags, so you get Playwright MCP's default: a persistent profile on the container's filesystem (~/.cache/ms-playwright/mcp-*). Two consequences worth knowing:

Logins survive between calls — usually what you want. Authenticate once through the hosted browser and later sessions reuse the session. Every client pointed at the URL shares that one profile, so this assumes the service is yours (see Security). No Disk is attached, so the profile is wiped on restart or redeploy.
Concurrent clients can conflict. Upstream notes a persistent profile "can only be used by one browser instance at a time, so concurrent MCP clients sharing the same workspace will conflict" — so two editors on one URL may collide. Scaling past one instance also gives each instance its own profile.

To change either, edit render-entrypoint.sh:

Want	Add
A fresh in-memory profile per session, discarded on close	`--isolated`
A profile that survives redeploys (saved logins)	a Render Disk plus `--user-data-dir <mount-path>`

Security

What you're actually running

Playwright MCP exposes browser_run_code_unsafe, described upstream as: "Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent." On the pinned version it is listed under Core automation, not one of the opt-in capabilities, and --caps only enables additional capabilities (vision, pdf, devtools) — so it cannot drop this tool, and no flag excludes individual tools. Whoever can call this server can run code in your container as the container user, and reach your other Render services over the private network.

Upstream ships no authentication in HTTP mode, which is defensible when the server is npx on your laptop's loopback. On Render it gets a public URL, so this template adds the missing door.

What the template does about it

render-auth-proxy.mjs is the only thing listening on $PORT. It answers 401 to any request without Authorization: Bearer $MCP_TOKEN and forwards the rest to the MCP server, which binds to 127.0.0.1 and is never published. Specifically:

Fails closed. No MCP_TOKEN, no start — there is deliberately no flag to disable the check, so no misconfiguration leaves the server anonymous.
Generated secret, not a default. render.yaml uses generateValue: true, so each service gets its own token — generated once when the service is created and stable across redeploys, so clients keep working — and there is no shared credential in this repo to leak.
Constant-time comparison of SHA-256 digests, so the check doesn't leak the token a byte at a time, and a token prefix is not accepted.
Never logs the token. Rejections log method, path, and 401 — nothing presented by the client.
Rate-limits guessing. Failed attempts share one global budget: 10 in a minute and the rest of that window gets 429 with a Retry-After, plus one log line rather than one per attempt. The budget is spent only by requests that were going to be refused anyway, so a valid token is never subject to it — the lockout can't be aimed at you, and you can always get back in while an attacker is locked out. It's deliberately not per client: this gate fronts a single shared secret, so what's worth guaranteeing is a ceiling on the total guess rate, and a per-address limit doesn't provide one — an attacker rotating source addresses just gets a fresh budget each time.
Stops the token at the door. The Authorization header is not forwarded to the MCP server, along with the hop-by-hop headers a proxy is required to drop. Connection upgrades (WebSocket and the like) are answered 501 rather than proxied, since the MCP transport never needs one.

What it does not do

This is one door, not defense in depth. It does not sandbox the RCE, cap what an authenticated caller can do, or give you per-client identity — everyone who has the token is the same principal, and the rate limit above slows guessing, not misuse of a token that already leaked. If you can, layer something stronger on top:

Restrict who can reach the service at all. Inbound IP rules scoped to your known addresses (Scale and Enterprise plans) mean a stolen token isn't usable from anywhere else.
Don't expose it publicly at all. If your MCP client is another Render service, change type: web to type: pserv in render.yaml to make it a private service — no public URL, strictly safer, and the token still applies. Note it gets no RENDER_EXTERNAL_HOSTNAME, so the host check falls back to * and the startup banner prints a localhost URL; reach it over the private network.
Treat the token as a password. Keep it out of shared configs and issue trackers, rotate it in the Dashboard if it may have leaked (a redeploy picks up the new value), and suspend or delete the service when you're done with it.
Watch it. The service's logs and metrics are how you'd notice use you didn't initiate; 401 lines mean someone is knocking.

One consequence of that shared budget is worth knowing before you debug against it: while someone is exhausting it, a request carrying the wrong token gets 429 rather than 401. Anyone can hold it empty indefinitely — ten refused requests a minute is all it takes — so on a service that attracts background scanning this may be the normal state rather than an unusual one. If you're testing with a token that turns out to be stale (rotated in the Dashboard, or copied from an older service), the status code won't tell you that, and the fix is to check the token rather than to wait out the Retry-After. A request with the right token is unaffected either way, which is the reason this trade is acceptable: the budget can be emptied by anyone, but the lockout it produces can't be aimed at you.

The host check the entrypoint sets up (see Configuration) is a Host-header check against DNS rebinding — not access control. It does nothing to stop a direct request carrying a valid token.

Rolling Playwright MCP

The version is pinned in exactly one place: the base-image tag in Dockerfile.render. To bump, change that tag, commit, and redeploy. (runtime: docker images don't auto-deploy when a tag moves — a fresh deploy pulls the new base.)

Then re-check the two claims in Security against the new tag's upstream README: whether browser_run_code_unsafe is still a non-opt-in Core automation tool, and whether --caps still only adds capabilities. Update that section's permalink to the new tag either way — it's the only other place a version literal appears, because a permalink has to carry one.

Then re-verify the gate, since it depends on upstream's HTTP surface. npm run test:wrapper covers the gate's own logic in seconds without Docker (the failure budget, and the proxy answering 401/429/200 over a stub upstream), and ./render-smoke-test.sh builds the new image and checks it end to end (401 without the header, 429 after repeated bad tokens, a handshake with the right one, a real tool call through the SSE path, clean shutdown). CI runs both on every PR, so opening one is equivalent. If upstream ever ships real authentication, prefer it and delete render-auth-proxy.mjs — this file exists only to fill that gap.

Not a version to keep in sync: the version field in package.json. This repo is a fork of microsoft/playwright-mcp, so that field is upstream's own npm release marker — and the deploy never uses it (Dockerfile.render copies only render-entrypoint.sh, render-auth-proxy.mjs, and render-auth-limiter.mjs). Expect it to differ from the image tag; leave it alone.

Based on microsoft/playwright-mcp · Deploys on Render.

Available Tools

23 tools

browser_clickB

Destructive

Perform click on a web page

ParametersJSON Schema

Name	Required	Description
`button`	No	Button to click, defaults to left
`target`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`element`	No	Human-readable element description used to obtain permission to interact with the element
`modifiers`	No	Modifier keys to press
`doubleClick`	No	Whether to perform a double click instead of a single click

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, indicating the tool mutates state and can be destructive. The description adds no further behavioral disclosure, such as possible navigation or permission requirements. It does not contradict annotations, but provides no value beyond them.

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 a single concise sentence with no filler. However, it is terse and omits useful context that could be added without bloat, such as the requirement for a snapshot target. It is appropriately sized but not front-loaded with any distinguishing information.

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?

Given the tool's moderate complexity (5 parameters, no output schema), the description alone is minimally sufficient because the schema fully describes parameters. However, it lacks context about return values, when to use click vs other actions, and potential side effects. The schema covers parameter semantics, so a score of 3 is appropriate.

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?

Schema description coverage is 100%, with every parameter documented (e.g., target is 'Exact target element reference from the page snapshot, or a unique element selector'). The description itself adds no additional parameter meaning, so the baseline of 3 applies.

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 action ('Perform click') and the resource ('web page'), which is specific enough. However, it does not differentiate from sibling interaction tools like browser_hover or browser_drag; the agent must infer that 'click' is a distinct action without additional context. It is unambiguous about the core operation but lacks detail on the target element requirement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as needing a page snapshot to obtain a valid target, nor does it contrast with browser_hover or browser_drag. An agent receives no context for tool selection.

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

browser_closeB

Destructive

Close the page

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

The annotation already indicates destructiveHint=true, so the agent knows the action is destructive. The description simply repeats that by saying 'close' without adding any extra context about side effects (e.g., whether it closes just the current tab, loses unsaved state, or affects other tabs). It does not contradict the annotation, but it adds no new behavioral information.

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, using only three words. It communicates the essential action and target without any fluff, making it easy to parse and understand quickly.

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?

Given the simplicity of the tool (no parameters, no output schema), the description is functional but lacks completeness. It leaves open the scope of 'close'—does it close the current page/tab, or the entire browser? In a context with sibling tools like browser_tabs, this ambiguity could be problematic. More detail would improve it.

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?

There are no parameters, so the schema coverage is trivially complete at 100%. The description does not need to explain any parameter semantics, and the baseline score of 3 applies.

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 'Close the page' clearly states the action (close) and the resource (page), making it unambiguous. It is distinct from sibling tools like browser_navigate or browser_snapshot, so an agent can easily identify it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention potential alternatives (e.g., using browser_tabs to manage multiple pages) or any conditions that would make closing appropriate. The context is minimal and leaves the decision entirely to the agent.

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

browser_console_messagesB

Read-only

Returns all console messages

ParametersJSON Schema

Name	Required	Description	Default
`all`	No	Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false.
`level`	Yes	Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info".	info
`filename`	No	Filename to save the console messages to. If not provided, messages are returned as text.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint true and destructiveHint false, so the description adds no conflicting side-effect information. It does not elaborate on behavior such as saving to a file, but that is covered by parameter 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 a single clear sentence with no redundancy, front-loading the verb and object.

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?

For a simple read-only tool with full schema coverage, the description is adequate, though it omits explicit use-case guidance and output format details beyond what the schema provides.

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?

Schema coverage is 100% with detailed parameter descriptions, so the tool description itself does not add meaning beyond the schema, but no parameter meaning is missing.

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?

Description uses a specific verb 'Returns' and identifies the resource 'console messages' with scope 'all', making the tool's purpose clear and distinct from sibling tools such as network request retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like browser_network_requests or browser_snapshot, nor does it mention filtering or filename-saving scenarios.

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

browser_dragA

Destructive

Perform drag and drop between two elements

ParametersJSON Schema

Name	Required	Description
`endTarget`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`endElement`	No	Human-readable target element description used to obtain the permission to interact with the element
`startTarget`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`startElement`	No	Human-readable source element description used to obtain the permission to interact with the element

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no extra behavioral context such as side effects on the DOM or event firing, but it does not contradict the annotations.

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 front-loads the action and provides the core information without any irrelevant detail.

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 action with well-described parameters and no output schema, the description is mostly complete. It does not mention any return values or wait behavior, but the lack of output schema makes this acceptable. It could have added a note about the order of start and end parameters, but the parameter names and descriptions handle that.

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?

Schema description coverage is 100% with all four parameters described. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 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 clearly states the action (perform drag and drop) and the resource (between two elements), distinguishing it from sibling tools like browser_click, browser_hover, and browser_drop. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions such as needing to move an element or triggering drag-and-drop events, nor does it reference sibling tools like browser_drop or browser_click.

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

browser_dropA

Destructive

Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.

ParametersJSON Schema

Name	Required	Description
`data`	No	Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}).
`paths`	No	Absolute paths to files to drop onto the element.
`target`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`element`	No	Human-readable element description used to obtain permission to interact with the element

TDQS

A4/5.0

Behavior3/5

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

Annotations already convey destructive and non-read-only behavior, so the description does not need to repeat that. The description adds useful semantic context about simulating an external drag, but does not disclose any side effects beyond the basic drop action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that concisely explains both the action and the key parameter requirement. No filler 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 description, combined with the detailed schema and annotations, provides enough information to invoke the tool correctly. There is no output schema, so return-value details are not required, and the parameter permission explanation is handled by the 'element' field description.

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?

All parameters have clear schema descriptions. The tool description adds an important cross-parameter constraint that at least one of 'paths' or 'data' must be provided, which is not otherwise expressed in 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 action: dropping files or MIME-typed data onto an element. It uses a specific verb and resource, and distinguishes itself from in-page drag operations by specifying 'as if dragged from outside the page'.

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 gives a useful usage constraint ('At least one of paths or data must be provided') and hints at external drag context, but it does not explicitly name sibling tools or state when to prefer this over browser_file_upload or browser_drag.

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

browser_evaluateB

Destructive

Evaluate JavaScript expression on page or element

ParametersJSON Schema

Name	Required	Description
`target`	No	Exact target element reference from the page snapshot, or a unique element selector
`element`	No	Human-readable element description used to obtain permission to interact with the element
`filename`	No	Filename to save the result to. If not provided, result is returned as text.
`function`	Yes	() => { /* code / } or (element) => { / code */ } when element is provided

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the agent knows this can modify state. The description adds minimal context beyond that—it mentions 'on page or element' but doesn't warn about the power of arbitrary JS execution or potential side effects. Since the annotation covers the destructive nature, the description's lack of extra detail keeps it at a baseline 3.

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?

A single, clear sentence with no redundant words. The action is front-loaded and easy to parse. This is appropriately concise for a tool whose parameter details are already in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this tool executes arbitrary JavaScript with destructive potential, the description is too sparse. It doesn't mention that the function can modify the page, that results can be saved to a file (though schema covers it), or that there is a separate unsafe variant (browser_run_code_unsafe) that might be more appropriate for certain tasks. The description lacks the context an agent needs to safely and correctly use this tool, especially when annotations already warn about destructiveness but the description provides no additional guidance.

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?

Schema description coverage is 100%, so all four parameters are documented in the schema itself. The description does not add any meaning beyond what the schema provides—it doesn't elaborate on the function syntax, target usage, or filename behavior. With high schema coverage, the baseline is 3, and the description contributes nothing extra.

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 verb 'Evaluate' and the resource 'JavaScript expression on page or element', making the core purpose obvious. However, it doesn't distinguish from the sibling browser_run_code_unsafe, which might also execute code, so it loses a point for not differentiating between similar tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like browser_run_code_unsafe or when to avoid it. No context about prerequisites (e.g., page must be loaded) or scenarios that favor this tool over others. The description simply states the action without any usage direction.

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

browser_file_uploadB

Destructive

Upload one or multiple files

ParametersJSON Schema

Name	Required	Description	Default
`paths`	No	The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled.

TDQS

B3.4/5.0

Behavior3/5

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

The annotations already indicate destructive behavior and non-read-only semantics, so the description does not need to restate those. However, the description does not mention side effects beyond uploading, such as navigating away, opening or cancelling a file chooser, or potential overwrite behavior, though the parameter description partially covers the cancellation case.

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 and free of filler. Every word contributes meaning, and the parameter description adds necessary details without redundancy.

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?

For a simple one-parameter tool with no output schema, the description and parameter comment cover the essential input and basic behavior. However, it does not describe what happens after the upload, what success or failure looks like, or how this fits into the broader browser automation workflow, leaving some practical context missing.

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 only defines an array of strings, but the parameter description adds important meaning: paths must be absolute, multiple files are allowed, and omitting the parameter cancels the file chooser. This goes beyond the raw schema and helps an agent use the parameter correctly.

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 action ('Upload') and the resource ('files'), and specifies 'one or multiple'. It does not explicitly state the destination or context, but the tool name and sibling set make the browser file-upload intent sufficiently clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives such as browser_drop or other browser interaction tools. It also does not mention prerequisites like whether the file chooser must already be open or how paths should be formatted beyond 'absolute'.

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

browser_fill_formB

Destructive

Fill multiple form fields

ParametersJSON Schema

Name	Required	Description	Default
`fields`	Yes	Fields to fill in

TDQS

B3.2/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=false and destructiveHint=true, so the write and potentially destructive nature is covered. The description adds the 'multiple form fields' detail but does not disclose additional behavior such as overwriting values or submitting the form.

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 a single clear sentence with no redundant words or boilerplate. It is appropriately short and easy to parse, though it sacrifices deeper context for brevity.

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 rich schema fully documents the nested field objects, including target references, type-specific value behavior, and permission-related element descriptions. Combined with the read-only and destructive annotations, the description is sufficient for correct invocation; only alternative-selection guidance is missing.

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?

Schema coverage is 100%: the fields array and its nested target, name, type, value, and element properties all have descriptive text. The description itself does not add parameter-level meaning beyond what the schema already provides.

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 'Fill multiple form fields' clearly identifies the action and resource, and the word 'multiple' helps distinguish it from single-field tools like browser_type. It does not explicitly contrast with sibling tools, but the core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided for when to use this tool instead of alternatives such as browser_type, browser_select_option, or browser_click. The term 'multiple' implies batch usage, but there is no explicit when-to-use or exclusion context.

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

browser_handle_dialogC

Destructive

Handle a dialog

ParametersJSON Schema

Name	Required	Description	Default
`accept`	Yes	Whether to accept the dialog.
`promptText`	No	The text of the prompt in case of a prompt dialog.

TDQS

C2.2/5.0

Behavior2/5

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

The annotations indicate readOnlyHint=false and destructiveHint=true, covering the main safety aspect. However, the description adds no detail about side effects, such as submitting a form or canceling a prompt, beyond what the parameter names imply. It does not clearly disclose the consequences of accepting or rejecting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short and lacks necessary detail, making it under-specified. It is terse but not informative enough to guide an agent effectively, similar to a placeholder like 'Process'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or additional context is provided. The description does not explain what happens after handling the dialog, how the parameters interact, or any post-conditions. This is insufficient for an agent to fully understand the tool's behavior.

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?

Schema coverage is 100% with clear descriptions for both 'accept' (boolean) and 'promptText' (string for prompt dialogs). The description does not add extra meaning, but the schema already provides adequate parameter semantics, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Handle a dialog' identifies the action and resource but is vague. It does not specify the type of dialog (alert, confirm, prompt) or the precise effect, though the 'accept' parameter implies accept/dismiss. It is distinct from sibling tools, but the purpose is under-specified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool, such as after a dialog appears or in contrast to other browser actions. The description gives no context for the appropriate situation.

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

browser_hoverA

Destructive

Hover over element on page

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`element`	No	Human-readable element description used to obtain permission to interact with the element

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=true, so the description doesn't need to re-state them. The description adds no extra behavioral detail about side effects (e.g., triggering JavaScript events, potential menu changes). With annotations present, the bar is lower, but there's still room for more transparency about outcomes.

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—six words, no redundancy, and perfectly focused on the action. It follows a clear verb-object structure with no extra fluff, making it easy to parse and understand.

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 interaction tool, the description, alongside the parameter schema and annotations, is adequate. It lacks details on return values (but no output schema exists) and does not mention any prerequisites or setup. Given the simplicity, it covers essential context without being overlong.

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?

Both parameters (target and element) have descriptions in the schema, achieving 100% coverage. The tool description does not add further meaning beyond the schema; it simply restates the action. Since schema coverage is complete, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (hover) and the target (element on page). It distinguishes itself from sibling tools like click, drag, and type by specifying the hover action. However, it lacks detail about what the hover does (e.g., showing tooltips or hover menus), but the core purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use hover versus other interactions. While it's intuitive that hover is for mouse-over actions, the description doesn't mention edge cases or alternative tools (e.g., use click for activating, hover for previews). It provides minimal implicit usage context.

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

browser_navigateC

Destructive

Navigate to a URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to navigate to

TDQS

C2.7/5.0

Behavior2/5

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

The description does not elaborate on side effects such as discarding the current page, waiting for load, or handling errors. While annotations indicate destructiveHint=true, the description adds no extra context about the navigation behavior beyond the literal action.

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 a single, direct sentence with no unnecessary words. It is appropriately sized for the simple action, though it could benefit from some additional context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks important context such as whether navigation waits for page load, how errors are reported, or the impact on the current browsing session. Given the tool modifies state (as indicated by destructiveHint), more context about the navigation behavior would be expected.

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 schema fully describes the only parameter 'url' with the same text as the description. Since schema coverage is 100%, the description adds no additional meaning or constraints (e.g., format, absolute vs. relative) beyond what is already in the schema.

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 action 'Navigate to a URL' with a specific resource. It distinguishes from sibling tools like browser_navigate_back by implying forward navigation to a new URL, though it could be more explicit about the effect on the current page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool over alternatives. It does not mention scenarios where browser_navigate is preferred over browser_navigate_back or other navigation methods, nor any prerequisites or exclusions.

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

browser_navigate_backA

Destructive

Go back to the previous page in the history

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

The description and annotations are consistent; destructiveHint is true, matching the navigation action which changes the current page. The description adds minimal behavioral context beyond the annotations, but does not contradict them. It does not mention potential side effects like what happens if there is no history or whether it affects new tabs.

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 with no redundant wording. It directly states the action and target without unnecessary detail, which is ideal for a tool with no parameters.

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, parameterless tool, the description is largely complete. It communicates the essential operation. It could be improved by noting the behavior when there is no previous history entry, but the given context is sufficient for most use cases.

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 parameter semantics. The empty input schema is fully covered by the lack of parameters, making this baseline appropriate.

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 action: 'Go back to the previous page in the history.' It identifies the resource (browser history) and the direction (back), making the core purpose unambiguous. It does not explicitly differentiate from sibling tools like browser_navigate or browser_tabs, but the meaning is clear enough in context.

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 when to use the tool: when the user wants to go back to the previous page in history. However, it provides no explicit guidance on when not to use it, such as when a direct URL navigation via browser_navigate would be more appropriate, or what to do if no prior history exists.

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

browser_network_requestA

Read-only

Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.

ParametersJSON Schema

Name	Required	Description
`part`	No	Return only this part of the request. Omit to return full details.
`index`	Yes	1-based index of the request, as printed by browser_network_requests.
`filename`	No	Filename to save the result to. If not provided, output is returned as text.

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns headers and body and can filter to a part, but does not elaborate on output structure or edge cases. Given annotation coverage, a 3 is appropriate.

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 no redundant wording. The main purpose is front-loaded, the part option is explained, and the source of the index is given. 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 read-only retrieval tool with full schema coverage and annotations, the description is sufficient. It explains the return type (full details or part) and the index source. It lacks explicit output format details, but the enum values for 'part' are self-explanatory.

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 100% with descriptions for all parameters, so the schema already documents them. The description adds critical value by explaining that 'index' comes from browser_network_requests, which is not in the schema, enhancing clarity.

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 returns full details of a single network request, with an optional 'part' parameter to narrow down. It distinguishes from the sibling tool browser_network_requests by referencing its index, 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 instruction 'Use the number from browser_network_requests' explicitly guides when to use this tool—after obtaining a listing. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide.

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

browser_network_requestsA

Read-only

Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.

ParametersJSON Schema

Name	Required	Description
`filter`	No	Only return requests whose URL matches this regexp (e.g. "/api/.*user").
`static`	Yes	Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.
`filename`	No	Filename to save the network requests to. If not provided, requests are returned as text.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context about the temporal scope ('since loading the page') and the numbered list format, which goes beyond annotations without contradicting them.

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 concise sentences with no redundancy. The primary action is front-loaded, and the companion tool reference is placed efficiently at the end. Every word 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?

The description tells the agent what the tool returns (a numbered list) and how to proceed for details. Since there is no output schema, this is essential. It does not describe potential error cases or edge scenarios, but for a read-only list tool with strong schema coverage, it is sufficiently complete.

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?

All three parameters have schema descriptions covering 100% of the input schema. The tool description does not add any additional meaning to the parameters themselves, so the baseline of 3 applies; it neither enhances nor detracts from what the schema already provides.

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 it returns a numbered list of network requests since page load, and explicitly differentiates from the sibling tool browser_network_request by instructing to use that tool for details. This is a specific verb+resource with a clear scope.

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 gives an explicit usage pattern: first call this tool to get a list, then use browser_network_request with the number for full details. This is clear guidance on when to use it versus its companion, though it does not mention any other alternatives or exclusions.

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

browser_press_keyB

Destructive

Press a key on the keyboard

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Name of the key to press or a character to generate, such as `ArrowLeft` or `a`

TDQS

B3.2/5.0

Behavior2/5

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

The description does not mention any side effects, such as triggering keyboard events or potential destructive behavior. The annotations indicate destructiveHint: true, but the description adds no additional behavioral context beyond that.

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 — a single sentence that directly conveys the action. No unnecessary information or repetition.

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 action with a single well-defined parameter, the description is adequate. It lacks mention of when to use this tool (e.g., for shortcuts or navigation keys) but is otherwise complete for basic invocation.

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 parameter 'key' is fully described in the schema with examples, and schema coverage is 100%. The description adds minimal extra meaning ('on the keyboard') but doesn't clarify key formats or special keys, which is already covered by the schema.

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 action (press) and the resource (key on the keyboard). It is distinct from broader actions like navigate or click, though it does not explicitly differentiate from browser_type (typing) or browser_click (clicking).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus its siblings (e.g., browser_type for text entry or browser_click for mouse actions). The description lacks any contextual cues for choosing this tool.

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

browser_resizeB

Destructive

Resize the browser window

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes	Width of the browser window
`height`	Yes	Height of the browser window

TDQS

B3.1/5.0

Behavior2/5

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

The description does not disclose any behavioral traits beyond the bare action. Annotations already indicate it is not read-only and is destructive, but the description adds no extra context about side effects like layout reflows or potential viewport changes.

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, short declarative sentence with no unnecessary words. It is perfectly concise and well-structured for the simple action it describes.

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?

For a simple tool, the description is adequate, but it lacks any extra context such as units (e.g., pixels), constraints, or when resizing might be appropriate. Given the simplicity and schema coverage, it is minimally complete but not rich.

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 already provides descriptions for both parameters (width and height), achieving 100% coverage. The description adds no additional meaning about the parameters, so it stays at the baseline of 3.

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 action (resize) and the resource (browser window), making it distinct from sibling tools like navigate or click. However, it lacks any nuance about whether it resizes the viewport or the entire window, but the core purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. It does not mention scenarios like adjusting viewport for responsive testing or any conditions that would make it preferable to other navigation tools.

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

browser_run_code_unsafeA

Destructive

Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.

ParametersJSON Schema

Name	Required	Description	Default
`code`	No	A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }`
`filename`	No	Load code from the specified file. If both code and filename are provided, code will be ignored.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's 'Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent' adds specific severity and mechanism beyond the generic flags. This enhances transparency without contradicting annotations, though it could also mention side effects or sandboxing if any.

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 sentence that packs purpose and a crucial warning. It front-loads the action and immediately follows with the risk, maximizing information density with zero filler. Excellent structure.

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?

Given the tool's complexity (arbitrary code execution) and the lack of an output schema, the description does not mention the return value or error behavior. The example in the code parameter shows a return, but that's in the schema. For an advanced tool, this is a notable gap, but the core purpose and danger are clear. A 3 reflects the missing return semantics and operational details.

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 covers 100% of parameters with detailed descriptions, including the precedence rule for code vs filename. The tool description adds no additional parameter meaning beyond the schema, so a baseline of 3 is appropriate. The schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Run a Playwright code snippet.' It specifies the resource (Playwright code) and immediately flags the critical distinction from siblings with 'Unsafe: executes arbitrary JavaScript ... RCE-equivalent.' This unambiguous verb+resource plus the danger label leaves no ambiguity about what the tool does and separates it from all other browser tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a strong warning about safety ('Unsafe', 'RCE-equivalent') but does not explicitly state when to use it versus alternatives. It implies it's for advanced custom logic, but there is no direct 'use this only if...' or mention of safer alternatives. The warning serves as a caution but not a full usage guide.

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

browser_select_optionB

Destructive

Select an option in a dropdown

ParametersJSON Schema

Name	Required	Description
`target`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`values`	Yes	Array of values to select in the dropdown. This can be a single value or multiple values.
`element`	No	Human-readable element description used to obtain permission to interact with the element

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already indicate destructive=true, so the description does not contradict that. But the description adds no further behavioral detail (e.g., side effects on the page). With annotations present, the bar is lower, and the description is neutral.

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 with no redundant words. It is well-structured and to the point.

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 is simple and the schema covers all parameters. The description is short but sufficient for a basic understanding. It does not specify whether values are labels or values, but that is a minor omission given the context.

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?

Schema coverage is 100% with clear parameter descriptions for target and values. The tool description itself does not explain parameters beyond what the schema already provides, so it adds no extra semantic value.

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 action (select) and the target (option in a dropdown), distinguishing it from more general actions like click or type. However, it does not explicitly contrast with sibling tools, so it misses a bit of distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention when selecting is appropriate or when other actions (e.g., click, type) might be preferred.

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

browser_snapshotB

Read-only

Capture accessibility snapshot of the current page, this is better than screenshot

ParametersJSON Schema

Name	Required	Description
`boxes`	No	Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect)
`depth`	No	Limit the depth of the snapshot tree
`target`	No	Exact target element reference from the page snapshot, or a unique element selector
`filename`	No	Save snapshot to markdown file instead of returning it in the response.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds 'capture' but no further behavioral detail beyond what annotations convey.

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 a single concise sentence. The phrase 'this is better than screenshot' adds some comparative value but could be considered slightly extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and the description does not explain what format the snapshot takes, how parameters like depth or target affect the result, or what kind of accessibility information is included. This leaves important context missing for an agent deciding whether and how to call the tool.

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?

Schema covers all 4 parameters with descriptions, so the baseline is 3. The description does not add any additional parameter meaning or usage notes beyond the schema.

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?

States a clear action ('capture') and object ('accessibility snapshot of the current page'), and distinguishes itself from screenshot with a comparative remark, though 'better than screenshot' is somewhat vague.

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?

Gives minimal guidance by saying 'better than screenshot', but does not explicitly state when to use this tool over alternatives like browser_evaluate or browser_console_messages, nor 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.

browser_tabsA

Destructive

List, create, close, or select a browser tab.

ParametersJSON Schema

Name	Required	Description
`url`	No	URL to navigate to in the new tab, used for new.
`index`	No	Tab index, used for close/select. If omitted for close, current tab is closed.
`action`	Yes	Operation to perform

TDQS

A3.5/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. However, the description adds no behavioral context beyond what the schema provides (e.g., index omission for close closes current tab is in schema). No mention of side effects like tab switching or browser-level changes.

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 sentence that efficiently lists all supported actions. It is front-loaded with verbs and avoids unnecessary words.

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?

The tool has multiple actions and a required action parameter. The description lists the actions but does not explain action-specific requirements (e.g., URL required for new, index for close/select) or edge cases like closing the last tab. Given the schema covers parameter details, the description is adequate but not rich. With no output schema, the agent must infer return values from the action.

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?

Schema description coverage is 100% with each parameter having a description (url, index, action with enum). The tool description adds no parameter-level detail, so it does not go beyond schema. Baseline 3 applies.

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 (list, create, close, select) and a specific resource (browser tab). It distinguishes from siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab) by focusing on tab operations.

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 through the list of actions but provides no explicit when-to-use guidance or exclusions. Given siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab), an agent might benefit from explicit differentiation, but the actions themselves are clear enough that usage is implied.

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

browser_take_screenshotA

Read-only

Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	Image format for the screenshot. Default is png.	png
`scale`	Yes	Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css.	css
`target`	No	Exact target element reference from the page snapshot, or a unique element selector
`element`	No	Human-readable element description used to obtain permission to interact with the element
`filename`	No	File name to save the screenshot to. Defaults to `page-{timestamp}.{png\|jpeg}` if not specified. Prefer relative file names to stay within the output directory.
`fullPage`	No	When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots.

TDQS

A4.4/5.0

Behavior4/5

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

The annotations already indicate read-only and non-destructive behavior. The description adds useful context beyond annotations by clarifying that screenshots are not suitable for interaction and that browser_snapshot should be used for actions. This is helpful but not extensive.

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: two sentences that front-load the core purpose and immediately follow with a crucial usage caveat. There is no unnecessary verbosity or repetition.

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 simple nature of the tool and the rich schema annotations, the description is largely complete. It could mention that screenshots are for visual inspection, but the title and schema fill most gaps. The explicit distinction from browser_snapshot adds important context.

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 schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter details, but the schema already provides clear explanations for each parameter, including enums, defaults, and 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 action: 'Take a screenshot of the current page.' It also distinguishes itself from browser_snapshot by explicitly noting that screenshots cannot be used for actions, which helps differentiate it from a key sibling tool.

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?

It provides explicit when-not-to-use guidance by stating 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This directly names the alternative tool and the condition for choosing it.

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

browser_typeB

Destructive

Type text into editable element

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to type into the element
`slowly`	No	Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once.
`submit`	No	Whether to submit entered text (press Enter after)
`target`	Yes	Exact target element reference from the page snapshot, or a unique element selector
`element`	No	Human-readable element description used to obtain permission to interact with the element

TDQS

B3/5.0

Behavior3/5

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

The annotation destructiveHint=true and readOnlyHint=false already signal that this tool can modify state, so the description does not contradict that. However, the main description adds no additional behavioral context beyond the annotations, such as whether typing overwrites existing content or triggers page events. The parameter descriptions do mention key-handler triggering and Enter submission, but the main description itself stays shallow.

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, focused sentence with no filler or repetition. It front-loads the verb and object, making the tool's primary purpose immediately obvious.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with several closely related siblings (fill_form, press_key, click), the description is too thin to fully orient an agent. It lacks any mention of when typing is appropriate, how the target is resolved, or what side effects to expect, so the agent must rely on parameter descriptions and external context to make a confident choice.

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?

Schema coverage is 100%, so the baseline is 3 because the input schema already documents all five parameters. The main description, 'Type text into editable element,' adds no meaning beyond the schema's parameter descriptions, which already define text, slowly, submit, target, and element clearly enough.

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 states a clear action ('Type text') and a clear target ('editable element'), which distinguishes it from many sibling tools at a high level. It is slightly vague about whether 'editable element' includes textareas, contenteditable regions, or only input fields, but the core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to prefer this tool over sibling tools such as browser_fill_form or browser_press_key. It does not mention exclusions, prerequisites, or scenarios where typing would be inappropriate, leaving the agent to infer usage from the tool name alone.

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

browser_wait_forA

Read-only

Wait for text to appear or disappear or a specified time to pass

ParametersJSON Schema

Name	Required	Description
`text`	No	The text to wait for
`time`	No	The time to wait in seconds
`textGone`	No	The text to wait for to disappear

TDQS

A3.9/5.0

Behavior4/5

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

The description adds behavioral detail beyond the readOnlyHint by explaining that it waits for text appearance/disappearance or a time delay. However, it does not specify what happens if multiple parameters are provided or if none are provided, so behavior 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 a single concise sentence that front-loads the core action and conditions. It contains no unnecessary words and is easy to parse.

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?

For a simple wait tool with no output schema, the description covers the main use cases, but it omits edge cases such as default behavior when no parameters are supplied, timeout behavior, or error conditions. These gaps make it only partially complete.

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 schema descriptions already cover each parameter individually, and the tool description mostly restates them. It does not clarify the relationship between text, textGone, and time (e.g., whether they are mutually exclusive or combinable), so minimal semantic value is added 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 waits for a condition: text to appear, text to disappear, or a specified time to pass. This distinguishes it from sibling tools like click, navigate, or type, and its purpose is immediately understandable.

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 when to use the tool (when waiting for page state or a delay), but it does not explicitly state when to prefer this over alternatives or how to choose among text, textGone, and time parameters. It provides functional guidance but lacks explicit usage conditions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

23 tool updatesv0.0.77Sep 8, 2026
- First observedbrowser_click
- First observedbrowser_close
- First observedbrowser_console_messages
- First observedbrowser_drag
- First observedbrowser_drop
- First observedbrowser_evaluate
- First observedbrowser_file_upload
- First observedbrowser_fill_form
- First observedbrowser_handle_dialog
- First observedbrowser_hover
- First observedbrowser_navigate
- First observedbrowser_navigate_back
- First observedbrowser_network_request
- First observedbrowser_network_requests
- First observedbrowser_press_key
- First observedbrowser_resize
- First observedbrowser_run_code_unsafe
- First observedbrowser_select_option
- First observedbrowser_snapshot
- First observedbrowser_tabs
- First observedbrowser_take_screenshot
- First observedbrowser_type
- First observedbrowser_wait_for

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-09-08 04:45 across 23 tools

Disambiguation5/5

Each tool has a clear, unique action (navigate, click, type, wait, screenshot, network, etc.) with no overlapping purposes. Even similar tools like type vs press_key vs fill_form are distinct in their behavior.

Naming Consistency5/5

All tools follow the consistent 'browser_' prefix with snake_case naming. The pattern is uniform across verbs and nouns, making it easy to predict tool names.

Tool Count4/5

23 tools is slightly above the typical 3-15 range, but justified for a comprehensive browser automation server. The number is not excessive and each tool contributes meaningful functionality.

Completeness4/5

The toolset covers core browser interactions (navigation, clicks, typing, waiting, screenshots, network, tabs, file upload) and also advanced features (JS evaluation, dialogs, drag-and-drop). Missing some niche actions like scrolling or cookie management, but these are often accessible via evaluate.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

render-mcp A
io.github.RodRomer
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Browser Automation Testing & QA Tools
61
browser-forest A
com.browserforest
Undetectable cloud browser sessions for AI agents and scrapers. Navigate, extract, click, captcha.
Browser Automation Web Scraping Agent Orchestration
91
sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
browser-mcp
io.github.Shreyas-Profile
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Browser Automation Web Scraping
2

Related MCP Servers

selenium-mcp
Browser Automation Web Scraping Testing & QA Tools
gaforov
A
license
A
quality
A
maintenance
Enables browser automation through the Model Context Protocol, allowing AI agents to control Chrome, Firefox, or Edge for tasks like navigation, clicking, typing, and screenshots.
Updated 9 days ago (2026-09-13 02:00 UTC)
41
267 npm
MIT
Browseagent MCPofficial
Browser Automation Autonomous Agents
browseagent
A
license
A
quality
D
maintenance
Enables AI agents to control web browsers through the Model Context Protocol, supporting navigation, clicking, typing, and screenshots.
Updated a year ago (2025-09-20 15:33 UTC)
12
2 npm
1
MIT
arthur
Browser Automation Agent Orchestration
sh7vansh
A
license
Not graded
quality
B
maintenance
Enables AI agents to control a headless Chromium browser through a persistent Python REPL, providing navigation, interaction, snapshotting, and media control via the Model Context Protocol.
Updated a month ago (2026-08-24 03:24 UTC)
MIT
Playwright MCP
Browser Automation Agent Orchestration
erlanov2023e
A
license
B
quality
C
maintenance
Enables AI assistants to remotely drive a hosted headless browser over HTTP, supporting navigation, clicking, typing, and structured page reading through the Model Context Protocol. It also provides bearer-token authentication for secure remote MCP access.
Updated a month ago (2026-08-25 17:06 UTC)
23
5,046,799 npm
Apache 2.0

Playwright MCP on Render

What it does

Architecture

Prerequisites

Deploy

Using the app

Run locally

Configuration

Browser profile state

Security

What you're actually running

What the template does about it

What it does not do

Rolling Playwright MCP

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Browseagent MCPofficial