browser-compat-mcp-server

Browsercompat Check Baseline

browsercompat_check_baseline

Read-onlyIdempotent

Check whether web features are safe to ship: Baseline state and the date it crossed, the browser and version that limits support, whether the feature is deprecated or discouraged, and the share of tracked global traffic that requiring it would exclude. Accepts up to 20 BCD keys or web-features ids in one call.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`resolve`	No	When true, an entry that is neither a key nor an id falls back to the search index, such as "Container queries (size)" or "Element.prototype.animate". Its best exact matches are accepted only when they name one feature: a single key resolves to that key, several keys of one web-features feature resolve to the feature with its feature-level Baseline and compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct.
`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	One result per requested feature. A miss is a result, not a failure.
`totalCount`	No	Number of results returned.
`attribution`	No	Required attribution for the caniuse-derived usage figures in this response.
`data_version`	No	Vintage of each bundled dataset behind this answer.
`unresolvedNotice`	No	Names the entries that did not resolve and how to find the right key.
`all_widely_available`	No	True only when every entry resolved and reports Baseline widely. A single miss forces false. Deprecation and discouragement do not enter this answer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 30, 2026

changedInput schema / properties / resolve / description

Previous value: -"When true, an entry that is neither a key nor an id falls back to the search index, such as \"Container queries\" or \"Element.prototype.animate\". Its best exact matches are accepted only when they name one feature: a single key resolves to that key, several keys of one web-features feature resolve to the feature with its feature-level Baseline and compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct."New value: +"When true, an entry that is neither a key nor an id falls back to the search index, such as \"Container queries (size)\" or \"Element.prototype.animate\". Its best exact matches are accepted only when they name one feature: a single key resolves to that key, several keys of one web-features feature resolve to the feature with its feature-level Baseline and compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct."

changedOutput schema / properties / results / items / properties / limiting_browser / description

Previous value: -"Among the Baseline core browsers, the one requiring the newest release."New value: +"Among the Baseline core browsers, the one requiring the newest release. Present only when every core browser has full, unprefixed, unflagged support at a resolvable added release."

changedOutput schema / properties / results / items / properties / usage_percent_excluded / description

Previous value: -"Share of tracked global traffic that requiring this feature would exclude. Absent when the feature reaches no caniuse id — never zero in that case."New value: +"Feature-level share of tracked traffic excluded. A resolved BCD key receives it only when it is the feature’s sole declared compat key. Absent without caniuse data — never zero in that case."

Changed2 schema fields changedSep 22, 2026

changedInput schema / properties / resolve / description

Previous value: -"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."New value: +"When true, an entry that is neither a key nor an id falls back to the search index, such as \"Container queries\" or \"Element.prototype.animate\". Its best exact matches are accepted only when they name one feature: a single key resolves to that key, several keys of one web-features feature resolve to the feature with its feature-level Baseline and compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct."

changedOutput schema / properties / results / items / properties / resolved_as / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "baseline_id": {
-        "description": "The web-features id this resolved to, or null when no web-features entry covers the key.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "bcd_key": {
-        "description": "The single browser-compat-data key this resolved to, or null when the web-features id spans more than one key.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "input": {
-        "description": "The feature string as the caller sent it, trimmed.",
-        "type": "string"
-      },
-      "resolved_via": {
-        "description": "Which step of the resolution order matched: bcd_key or web_features_id for an exact match, web_features_id_normalized when it matched only after lowercasing, redirect when the input pointed to a browser-compat-data entry that has moved or split, or search when resolve was true and the search index accepted a single unambiguous top hit — treat a search match as a best guess, not a confirmed key.",
-        "enum": [
-          "bcd_key",
-          "web_features_id",
-          "web_features_id_normalized",
-          "redirect",
-          "search"
-        ],
-        "type": "string"
-      }
-    },
-    "required": [
-      "input",
-      "bcd_key",
-      "baseline_id",
-      "resolved_via"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "baseline_id": {
+        "description": "The web-features id this resolved to, or null when no web-features entry covers the key.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "bcd_key": {
+        "description": "The single browser-compat-data key this resolved to, or null when the web-features id spans more than one key.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "input": {
+        "description": "The feature string as the caller sent it, trimmed.",
+        "type": "string"
+      },
+      "resolved_via": {
+        "description": "Which step of the resolution order matched: bcd_key or web_features_id for an exact match, web_features_id_normalized when it matched only after lowercasing, redirect when the input pointed to a browser-compat-data entry that has moved or split, or search when resolve was true and the best exact matches in the search index all named one feature or key — treat a search match as a best guess, not a confirmed key.",
+        "enum": [
+          "bcd_key",
+          "web_features_id",
+          "web_features_id_normalized",
+          "redirect",
+          "search"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "input",
+      "bcd_key",
+      "baseline_id",
+      "resolved_via"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

First observedSep 20, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, closed-world), so the bar is lower; the description still adds failure semantics beyond the schema — a typo yields a correctable miss, whitespace yields invalid_feature_input, and multi-feature or cross-feature resolve matches are rejected. It stops short of describing pagination or result ordering, but for a read-only batch check that is minor.

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?

Two sentences, purpose front-loaded, and every clause names a distinct return field rather than padding. The second sentence is dense but earns its length by telling the agent what a call yields; only slight redundancy with the output schema keeps it from a 5.

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?

With an output schema present, the description needn't enumerate return values, yet it does so clearly and also covers input limits, resolve fallback, and error behavior. Nothing essential to calling it correctly is missing; the only weakness is that some return-field detail duplicates the output schema rather than adding new 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%, so both parameters are fully documented in the schema itself, including the resolve fallback rules and the 200-char/20-item bounds. The description only restates the batch limit, adding no syntax or format meaning beyond what the schema already carries, so the 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?

States a specific verb (check) plus the concrete decision it supports ('whether web features are safe to ship') and enumerates the exact outputs an agent gets back: Baseline state, crossing date, limiting browser/version, deprecation status, and excluded traffic share. The call limit ('up to 20 BCD keys or web-features ids') further pins down scope, distinguishing it from the search and single-feature siblings.

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?

Explicitly routes the agent to browsercompat_search_features for any key it doesn't already know, which is real when-to-use guidance. It does not say when to prefer this over browsercompat_get_feature or the compare/ list siblings, so the routing is partial rather than complete.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.