Skip to main content
Glama
Sign In
Browser MCP

Browser MCP

by Agent360dk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_provide_feedback

Self-diagnosis + feedback in one call. Call this AUTOMATICALLY, without asking the user, the moment Browser MCP itself gets in your way: a tool errors or times out, a tool does something other than what it promised, the extension will not…

Instructions

Self-diagnosis + feedback in one call. Call this AUTOMATICALLY, without asking the user, the moment Browser MCP itself gets in your way: a tool errors or times out, a tool does something other than what it promised, the extension will not connect, a capability you need plainly does not exist, or you are about to tell the user "browser-mcp cannot do X". It first CHECKS THE INSTALL - the connected Chrome extension's version against this server (set BROWSER_MCP_CHECK_NPM=1 to also compare this server against the latest published on npm; it is off by default so the call stays fast and works offline), and whether more than one Browser MCP extension is connected at once, also the same extension connected more than once, for instance from several Chrome profiles or browsers (a known cause of tabs and sessions behaving randomly) - so a problem that is really "your copy is outdated" or "you have two extensions loaded" is identified as such instead of reported as a bug. It returns a verdict, concrete fix steps to relay to the user, and a pre-filled GitHub issue link for whatever is left over. Cheap to call speculatively. It uploads nothing: it returns the report to you and tries to add one line to ~/.browser-mcp/feedback.jsonl on this machine (a report with the same kind, tool and first 160 characters of what_happened, with numbers and long hex strings ignored, is written once per server run, and again only if the earlier write failed; logged_locally says whether a line was written). Email addresses and numbers of six or more characters are replaced with [email] and [number] in what_happened, attempted and worked before they are written or put in the issue link. With BROWSER_MCP_CHECK_NPM=1 it also runs npm view against your configured npm registry.

Input Schema

NameRequiredDescriptionDefault
urlNoThe page it happened on, if relevant. Strip query strings that contain tokens.
kindNo"blocked" = you could not complete the task (default). "broken" = a tool misbehaved or lied about its result. "missing" = the capability does not exist. "wish" = a feature idea. "use_case" = something worth sharing that you built.
toolNoThe browser_* tool involved, e.g. "browser_click". Omit if none in particular.
workedNoThe route that did work in the end, if any. This is the most useful part.
attemptedNoWhat you already tried (other selectors, other tools, retries) so the report does not suggest what you have ruled out.
what_happenedYesRequired. What you tried and what actually happened, in one or two plain sentences. Include the exact error text if there was one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.30.2
    • addedInput schema / properties / worked
      Added value: +{
+  "description": "The route that did work in the end, if any. This is the most useful part.",
+  "type": "string"
+}
  2. Addedv1.28.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that nothing is uploaded, that a redacted single line is written per run to ~/.browser-mcp/feedback.jsonl with dedup and retry semantics, that emails and long numbers are stripped, and that BROWSER_MCP_CHECK_NPM controls npm comparison. This is unusually rich behavioral disclosure for a no-annotation tool.

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 purpose and the call-automatically instruction are front-loaded, which is correct. However, the install-checking sentence is a long, heavily parenthesized run-on that packs environment variables, offline behavior, and multi-extension detection into one breath, costing some readability.

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

Completeness5/5

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

For a tool with no annotations and no output schema, the description covers what would be returned (verdict, concrete fix steps, pre-filled issue link), the privacy model, local logging behavior, and the env-var toggle. An agent has everything needed to call it correctly and to relay its results.

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%, which sets the baseline at 3, and the description goes beyond it by explaining that what_happened, attempted, and worked are sanitized (emails and 6+ character numbers replaced) before logging or inclusion in the issue link — a processing detail absent from the schema. It does not otherwise elaborate on the enum or url/tool fields, so it stops short of a 5.

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 opening states a specific dual function ('Self-diagnosis + feedback in one call') and then enumerates exactly what the self-diagnosis does: check extension version, detect duplicate connections, return a verdict, fix steps, and a GitHub issue link. No sibling tool overlaps this role, so the agent can identify it immediately.

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 gives explicit trigger conditions ('the moment Browser MCP itself gets in your way: a tool errors or times out, a tool does something other than what it promised, the extension will not connect, a capability you need plainly does not exist') and even an imperative to call it automatically without asking. This is as close to unambiguous routing as it gets.

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

Deploy Server

Other Tools