browser-compat-mcp-server

Browsercompat Compare Support

browsercompat_compare_support

Read-onlyIdempotent

Compute whether a set of web features clears an explicit browserslist target query. Returns a per-feature verdict, the target browser and version that fails, the share of tracked traffic the targets cover, and unchecked_targets for every resolved target browser with no compatibility data. A feature is never reported as clearing a target the server could not evaluate.

Input Schema

TableJSON Schema

Name	Required	Description
`resolve`	No	When true, fall back to the search index and accept its single unambiguous top hit for each entry. Off by default so a typo returns a miss you can correct rather than a confident answer about the wrong feature.
`targets`	Yes	A browserslist query, for example "defaults" or "> 0.5%, last 2 versions", 1 to 500 characters. Required: with no query browserslist would read config from the process working directory rather than from your project.
`features`	Yes	Up to 20 entries, each a browser-compat-data key such as css.selectors.has or a web-features id such as has, 1 to 200 characters. An empty or longer entry is rejected against this schema; a whitespace-only entry returns invalid_feature_input. Call browsercompat_search_features first for any entry whose key you do not already know.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`results`	No	Per-feature verdicts against the resolved targets.
`all_clear`	No	True only when every feature clears and unchecked_targets is empty.
`query_echo`	No	The targets query as the server parsed it.
`totalCount`	No	Number of feature results returned.
`attribution`	No	Required attribution for the caniuse-derived coverage figures in this response.
`data_version`	No	Vintage of each bundled dataset behind this answer.
`uncheckedNotice`	No	Names the target agents that were not evaluated and their combined usage share.
`targets_resolved`	No	Every browserslist token that was evaluated.
`unchecked_targets`	No	Every target the server declined to claim a verdict for, with the reason.
`target_coverage_percent`	No	Share of tracked global traffic the evaluated targets cover.
`unchecked_coverage_percent`	No	Share of tracked global traffic the unevaluated targets cover.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 20, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses non-obvious behavior: per-feature verdicts, the failing target browser and version, traffic-share coverage, unchecked_targets for resolved browsers without data, and the guarantee that unevaluable targets are never reported as cleared. This is exactly the behavioral context an agent needs.

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?

Three dense sentences: action first, then return value highlights, then a one-sentence safety caveat. There is no filler, and the most important scoping information is front-loaded.

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 a rich input schema, annotations, and an output schema, the description adds the critical caveat about unevaluable targets and summarizes the return shape. An agent has everything needed to invoke the tool correctly.

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 the baseline is 3. The description reinforces the meaning of targets ('explicit browserslist target query') and features ('set of web features'), but it does not add parameter format or syntax details beyond what the input schema already documents.

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 opens with a specific verb and resource: it 'compute[s] whether a set of web features clears an explicit browserslist target query'. This clearly identifies the tool as an evaluation/verdict tool, though it never names sibling tools such as browsercompat_check_baseline to make the boundary explicit.

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?

Usage context is implied by the focus on an explicit browserslist query and the required targets parameter, but the description gives no direct when-to-use/when-not-to-use guidance or alternative tool names. An agent comparing against sibling tools must infer when this tool is the right choice.

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

All browser-compat-mcp-server tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.