browser-compat-mcp-server

Browsercompat Get Feature

browsercompat_get_feature

Read-onlyIdempotent

Get the compatibility record for one web feature: Baseline state and the date it crossed, deprecation and standards status, per-browser version added and removed with flags, vendor prefixes and partial-implementation notes, and the MDN and specification links. Accepts a BCD key such as css.selectors.has or a web-features id such as has; the response echoes which one it matched. An unresolved feature returns found: false with guidance rather than an error.

Input Schema

TableJSON Schema

Name	Required	Description
`feature`	Yes	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 string is rejected against this schema; a whitespace-only string returns invalid_feature_input. Call browsercompat_search_features first if you do not already know the key.
`resolve`	No	When true, a string 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 compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct rather than a confident answer about the wrong feature.
`subkeys_offset`	No	Direct child keys to skip, default 0. Each subkeys page contains at most 100 keys; pass its next_offset to continue.
`include_runtimes`	No	Add the bun, deno, nodejs, and oculus rows to support. Leave off for browser ship decisions.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	No	web-features display name for the feature.
`error`	No	Present when the call failed. Absent on success.
`found`	No	True when the feature string resolved to a tracked entry.
`status`	No	Standards status for the resolved key. Absent for webextensions keys, which record none, and when the id spans more than one key.
`mdn_url`	No	MDN reference page for the resolved key.
`outcome`	No	found when per-feature data was returned, no_compat_data when the entry is tracked but owns no browser-compat-data keys, miss when nothing matched.
`subkeys`	No	Direct child compat records of the resolved BCD key. Absent for childless keys and resolutions without a single key.
`support`	No	One row per reported browser. Absent when the id spans more than one browser-compat-data key.
`baseline`	No	Baseline state for the resolved key, or the feature rollup when a web-features id resolved to more than one key.
`guidance`	No	What to do next on a miss or with no compat data.
`spec_urls`	No	Specification URLs for the resolved key, always an array.
`compat_keys`	No	Present when the web-features id spans more than one browser-compat-data key. Call this tool again with one of them for the per-browser fields.
`description`	No	web-features description, or the browser-compat-data description with tags stripped.
`discouraged`	No	Feature-level discouragement, independent of leaf standards status. Also retained in status.discouraged when status exists.
`resolved_as`	No	How the feature string was matched, or null on a miss.
`data_version`	No	Vintage of each bundled dataset behind this answer.
`limiting_browser`	No	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.
`runtimesExcluded`	No	Notes that the feature carries server-runtime or XR data that was left out.
`baselineNotMapped`	No	Explains why a resolved key carries no Baseline state.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 30, 2026

changedInput schema / properties / resolve / description

Previous value: -"When true, a string 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 compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct rather than a confident answer about the wrong feature."New value: +"When true, a string 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 compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct rather than a confident answer about the wrong feature."

addedInput schema / properties / subkeys_offset

Added value: +{
+  "default": 0,
+  "description": "Direct child keys to skip, default 0. Each subkeys page contains at most 100 keys; pass its next_offset to continue.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / discouraged

Added value: +{
+  "additionalProperties": false,
+  "description": "Feature-level discouragement, independent of leaf standards status. Also retained in status.discouraged when status exists.",
+  "properties": {
+    "according_to": {
+      "description": "URLs of the bodies that discourage the feature.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "reason": {
+      "description": "Why the feature is discouraged, as web-features states it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "reason",
+    "according_to"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / limiting_browser / description

Previous value: -"Among the Baseline core browsers, the one requiring the newest release. Absent until every core browser has shipped a resolvable version."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."

addedOutput schema / properties / subkeys

Added value: +{
+  "additionalProperties": false,
+  "description": "Direct child compat records of the resolved BCD key. Absent for childless keys and resolutions without a single key.",
+  "properties": {
+    "keys": {
+      "description": "At most 100 direct child keys, in BCD traversal order. Call browsercompat_get_feature for one, or browsercompat_check_baseline for up to 20.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "next_offset": {
+      "description": "Offset for the next page; absent at or past the end.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "total": {
+      "description": "Total direct callable child keys, before paging.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "truncated": {
+      "description": "True when more direct children remain after this page.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "total",
+    "keys",
+    "truncated"
+  ],
+  "type": "object"
+}

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. Off by default so a typo returns a miss you can correct rather than a confident answer about the wrong feature."New value: +"When true, a string 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 compat_keys, and matches spanning two features are a miss. Off by default so a typo returns a miss you can correct rather than a confident answer about the wrong feature."

changedOutput schema / 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

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, and the description still adds useful behavior: an unresolved feature returns found: false with guidance rather than an error, and the response echoes which identifier form matched. It does not discuss pagination behavior beyond what the parameter schema states, but it clearly 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.

Conciseness4/5

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

Front-loaded with the resource and a dense enumeration of returned fields, then two sentences covering input formats and the not-found path. Every sentence earns its place, though the field enumeration is long enough to be slightly list-like rather than crisp.

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?

An output schema exists, so the description need not explain return values, yet it summarizes them and adds the important 'found: false, not an error' contract. Combined with annotations covering safety and 100% schema coverage on inputs, the agent has what it needs; only the sibling-boundary guidance is 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?

Schema description coverage is 100%, so the schema already documents all four parameters and 3 is the baseline. The description adds genuine value on the primary parameter by naming both accepted identifier families (BCD keys like css.selectors.has vs web-features ids like has) and the echo-back semantics, going slightly beyond the structured field.

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 specific verb and resource ('Get the compatibility record for one web feature') and enumerates exactly what the record contains: Baseline state, deprecation/standards status, per-browser version added/removed, prefixes, and doc links. It does not, however, explicitly differentiate itself from siblings like browsercompat_check_baseline or browsercompat_compare_support, so an agent must infer the boundary from 'for one web feature'.

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 guidance is implied rather than stated: the dual key/id input and the resolve fallback shape how it is called, and the schema (not the description) tells the agent to call browsercompat_search_features first if the key is unknown. There is no explicit when-to-use/when-not comparison against check_baseline or compare_support.

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.