Skip to main content
Glama

browser-compat-mcp-server

by io.github.cyanheads
OverviewDiscussionsAdmin

Server Details

Browser compatibility and Baseline status for any web feature — offline, from bundled MDN data.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
cyanheads/browser-compat-mcp-server
GitHub Stars
1
Server Listing
browser-compat-mcp-server

TDQS

A4.1/5.0

Scored across 5 tools

Disambiguation4/5

search_features, compare_support, and list_reference have clearly distinct roles (discovery, browserslist evaluation, vocabulary enumeration). check_baseline and get_feature overlap somewhat: both report Baseline state and the crossing date, differing mainly by batch-vs-single scope and the traffic-exclusion angle.

Naming Consistency5/5

All five tools follow the identical browsercompat_ + verb_noun pattern (check_baseline, compare_support, get_feature, list_reference, search_features). The convention is applied uniformly with no deviations.

Tool Count5/5

Five tools is well-scoped for a read-only compatibility data server: discovery, single-record lookup, batch ship-safety check, target comparison, and reference enumeration. Each tool covers a distinct workflow step without redundancy.

Completeness4/5

The surface covers the full lookup lifecycle, from keyword search and reference enumeration through single-feature detail and batch ship-safety/browserslist evaluation. Minor gap: no batch variant of get_feature for pulling full records on many features at once, though check_baseline partially fills this.

Available Tools

5 tools
browsercompat_check_baselineBrowsercompat Check BaselineA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
resolveNoWhen 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.
featuresYesUp 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

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
resultsNoOne result per requested feature. A miss is a result, not a failure.
totalCountNoNumber of results returned.
attributionNoRequired attribution for the caniuse-derived usage figures in this response.
data_versionNoVintage of each bundled dataset behind this answer.
unresolvedNoticeNoNames the entries that did not resolve and how to find the right key.
all_widely_availableNoTrue only when every entry resolved and reports Baseline widely. A single miss forces false. Deprecation and discouragement do not enter this answer.

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.

browsercompat_compare_supportBrowsercompat Compare SupportA
Read-onlyIdempotent
Inspect

Compute whether a set of web features clears an explicit browserslist target query. Every call evaluates the whole query: each feature gets a verdict, the count of failing targets, and its own evaluated and unevaluated target counts with the share of tracked traffic each covers. The target rows behind those numbers — which release each target maps to, which targets were not evaluated and why, and the failing and unevaluated targets of each feature — cover at most ten query targets per call; page through them with target_offset and target_limit, and the verdicts, coverage, and totals stay identical on every page. A target counts as evaluated only where compatibility data was read for it, so a feature clears only when every target in the query was evaluated and supports it, and is inconclusive otherwise — a query that includes a browser with no compatibility data, as "defaults" does, never clears.

ParametersJSON Schema
NameRequiredDescriptionDefault
resolveNoWhen 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 and gets a verdict, several keys of one web-features feature resolve to the feature as verdict ambiguous 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.
targetsYesA 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.
featuresYesUp 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.
target_limitNoHow many query targets this page covers, 1 to 10. It bounds every list of target rows in the response and never the evaluation: verdicts, coverage, and totals always describe the whole query.
target_offsetNoZero-based position in the target list of the query at which this page of target rows starts. Pass the nextOffset of the previous response to continue. An offset at or past the number of targets returns the whole-query verdicts and totals with no target rows.

Output Schema

ParametersJSON Schema
NameRequiredDescription
capNoThe target_limit that was applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of query targets this page covers.
resultsNoPer-feature verdicts and totals over the whole query, each with its own target rows for this page.
all_clearNoTrue only when every feature clears, which requires every target in the query to have been evaluated for it.
truncatedNoTrue when more query targets remain past this page.
nextOffsetNoThe target_offset of the next page. Present only while targets remain past this page.
query_echoNoThe targets query as the server parsed it.
totalCountNoNumber of targets the query resolved to, across every page.
attributionNoRequired attribution for the caniuse-derived coverage figures in this response.
data_versionNoVintage of each bundled dataset behind this answer.
offsetNoticeNoWhy this page carries no target rows, and the offsets that do.
uncheckedNoticeNoHow many of the query targets were not evaluated for every compared feature, the agents they belong to, and their combined usage share.
targets_resolvedNoThe mapping inventory for the query targets on this page: each target that maps onto a browser-compat-data release, and whether it was evaluated. A target with no mapping appears only in unchecked_targets.
unchecked_targetsNoThe query targets on this page that were not evaluated for every compared feature, each with the reason.
comparable_featuresNoHow many entries in features were compared against the targets. A miss or an ambiguous entry is not comparable; at 0 nothing was evaluated.
targets_resolved_totalNoQuery targets that map onto a browser-compat-data release, across every page.
evaluated_targets_totalNoQuery targets evaluated for every compared feature, across every page. evaluated_targets_total plus unchecked_targets_total is the number of targets in the query.
target_coverage_percentNoShare of tracked global traffic covered by the targets evaluated for every compared feature; 0 when no feature was comparable.
unchecked_targets_totalNoQuery targets not evaluated for every compared feature, across every page.
unchecked_coverage_percentNoShare of tracked global traffic covered by the targets counted in unchecked_targets_total.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent and closed-world, and the description adds substantial behavioral detail on top: pagination never changes verdicts/coverage/totals, a feature clears only when every target was evaluated and supports it, and a query containing a browser with no compat data (like 'defaults') never clears. This is exactly the kind of non-obvious semantics 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.

Conciseness4/5

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

Front-loaded with the core purpose in sentence one, then layered semantics. It is dense but nearly every clause carries information; a small amount of overlap with the schema on page stability keeps it from a 5.

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?

Output schema exists, yet the description still conveys the decisive semantics (evaluated vs unevaluated, inconclusive, clears-only-if-all-targets-evaluated). With annotations, a full parameter schema and an output schema, nothing an agent needs to call this correctly 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 coverage is 100%, so the baseline is 3, but the description reinforces key parameter behavior — paging via target_offset/target_limit, the ten-target cap, and nextOffset continuation. It adds invariant-level meaning rather than merely restating field docs.

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 precise verb and resource — computing whether a feature set clears an explicit browserslist query — and the word 'explicit' plus the query-based framing distinguishes it from the baseline-checking sibling. An agent can tell what it does and roughly how it differs from a fixed-baseline tool without opening a schema.

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?

Gives real usage context: call browsercompat_search_features first for unknown keys, and resolve is off by default so a typo yields a miss you can correct. It also explains pagination procedure. It stops short of naming when to prefer this over browsercompat_check_baseline or get_feature.

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

browsercompat_get_featureBrowsercompat Get FeatureA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
featureYesA 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.
resolveNoWhen 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_offsetNoDirect child keys to skip, default 0. Each subkeys page contains at most 100 keys; pass its next_offset to continue.
include_runtimesNoAdd the bun, deno, nodejs, and oculus rows to support. Leave off for browser ship decisions.

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameNoweb-features display name for the feature.
errorNoPresent when the call failed. Absent on success.
foundNoTrue when the feature string resolved to a tracked entry.
statusNoStandards status for the resolved key. Absent for webextensions keys, which record none, and when the id spans more than one key.
mdn_urlNoMDN reference page for the resolved key.
outcomeNofound 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.
subkeysNoDirect child compat records of the resolved BCD key. Absent for childless keys and resolutions without a single key.
supportNoOne row per reported browser. Absent when the id spans more than one browser-compat-data key.
baselineNoBaseline state for the resolved key, or the feature rollup when a web-features id resolved to more than one key.
guidanceNoWhat to do next on a miss or with no compat data.
spec_urlsNoSpecification URLs for the resolved key, always an array.
compat_keysNoPresent 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.
descriptionNoweb-features description, or the browser-compat-data description with tags stripped.
discouragedNoFeature-level discouragement, independent of leaf standards status. Also retained in status.discouraged when status exists.
resolved_asNoHow the feature string was matched, or null on a miss.
data_versionNoVintage of each bundled dataset behind this answer.
limiting_browserNoAmong 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.
runtimesExcludedNoNotes that the feature carries server-runtime or XR data that was left out.
baselineNotMappedNoExplains why a resolved key carries no Baseline state.

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.

browsercompat_list_referenceBrowsercompat List ReferenceA
Read-onlyIdempotent
Inspect

Enumerate the reference vocabulary this server uses: BCD namespaces, BCD browser ids, browserslist agent ids and their BCD counterparts, Baseline states, web-features groups, and ECMAScript snapshots. Use it to build valid inputs for the other tools and to see which target browsers can be evaluated.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicYesWhich vocabulary to list: bcd_namespaces for the 12 top-level browser-compat-data namespaces, bcd_browsers for the 17 tracked browsers, browserslist_agents for the 19 browserslist ids mapped to browser-compat-data browsers, baseline_states for the 4 Baseline states, groups for the 104 web-features groups, or snapshots for the 11 ECMAScript snapshots.

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
topicNoThe topic that was listed.
entriesNoEvery entry in the requested vocabulary.
attributionNoRequired attribution for the caniuse-derived usage figures in this response.
data_versionNoVintage of each bundled dataset behind this answer.

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds useful context about the reference vocabulary being used by the server. It also adds the evaluative use case, but does not disclose additional behavioral details such as pagination, output shape beyond the schema, or error conditions. The description 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?

Two sentences, front-loaded with the action verb and the full list of enumerated vocabularies, followed by the practical use case. There is no filler, and the structure makes the tool's purpose immediately clear.

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 simple one-parameter listing tool, the description is complete: it identifies the six topic categories, explains why the tool is useful, and notes that it helps construct valid inputs for the other tools. The annotations and output schema cover the remaining operational details, so nothing essential 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?

The schema coverage is 100%, and the schema's parameter description already explains each enum value in detail. The top-level description lists the same categories at a high level but does not materially add meaning beyond the schema. This is the baseline case where 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 uses a specific verb ('Enumerate') and a clear resource ('the reference vocabulary this server uses'), then lists the exact categories. This clearly distinguishes it from the sibling tools, which check, compare, get, or search individual features rather than listing reference vocabularies.

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 explicitly states when to use this tool: 'Use it to build valid inputs for the other tools and to see which target browsers can be evaluated.' It provides solid usage context, though it does not explicitly discuss when not to use it or name alternatives.

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

browsercompat_search_featuresBrowsercompat Search FeaturesA
Read-onlyIdempotent
Inspect

Find web features by plain name or keyword when the canonical key is unknown, across CSS, JavaScript, HTML, Web APIs, SVG, MathML, WebAssembly, and HTTP headers. Returns ranked matches with the BCD key, the web-features id, the Baseline state, a one-line support summary, and which field matched. Feed a result key into browsercompat_get_feature for the full record.

ParametersJSON Schema
NameRequiredDescriptionDefault
groupNoRestrict results to features in one web-features group or any group nested under it, for example "selectors" or "css". Keys with no web-features mapping never match. Call browsercompat_list_reference with topic groups for valid ids.
limitNoMaximum results to return, from 1 to 50.
queryYesPlain-language name, keyword, or code notation, for example "container query", "fromAsync", "Array.prototype.at", "display: grid", or "<dialog>".
offsetNoNumber of ranked matches to skip before returning results, for paging past limit. Pass the nextOffset from the previous response.
baselineNoRestrict results to one Baseline state.
snapshotNoRestrict results to features in one ECMAScript snapshot, for example "ecmascript-2023". Call browsercompat_list_reference with topic snapshots for valid ids.
namespaceNoRestrict results to one top-level browser-compat-data namespace.

Output Schema

ParametersJSON Schema
NameRequiredDescription
capNoThe limit that was applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of results on this page.
resultsNoRanked matches, best first. An empty array is a successful search with no hits.
truncatedNoTrue when more matches remain past this page.
nextOffsetNoThe offset of the next page. Present only while matches remain past this page.
totalCountNoMatches across every page, before offset and limit apply.
data_versionNoVintage of each bundled dataset behind this answer.
offsetNoticeNoWhy a page came back empty although the search matched.
noMatchNoticeNoHow to broaden a search that matched nothing.
appliedFiltersNoFilters the server applied to this search.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds genuinely useful behavioral context: matches are 'ranked', the result is a summary (not the full record), and the matching semantics include which field matched. It also discloses that keys with no web-features mapping never match. This goes beyond the annotation coverage without contradicting it.

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 sentences, each earning its place: first scopes the search behavior, second states the return value and ranking, third routes to the follow-up tool. It is front-loaded and contains no filler or repetition of schema content.

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 7-parameter search tool, the description covers purpose, scope, output format, and follow-up routing, while the schema and output schema handle parameter details and return structure. Sibling differentiation is addressed. Nothing an agent needs to call or interpret the result 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 description coverage is 100%, so the schema already documents every parameter thoroughly with examples and constraints. The description reinforces the query concept and introduces the cross-namespace scope, but does not need to add parameter-level meaning; baseline 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 opens with a specific verb and resource: 'Find web features by plain name or keyword when the canonical key is unknown,' immediately distinguishing this tool from get_feature (which requires a known key). It scopes the feature domains explicitly and names the sibling to feed results into, so an agent can tell exactly what this tool does.

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?

The description gives a clear when-condition ('when the canonical key is unknown') and routes follow-up usage ('Feed a result key into browsercompat_get_feature for the full record'). It also points to browsercompat_list_reference in the schema for valid group/snapshot ids, explicitly guiding the agent away from guessing invalid parameters.

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.

  1. 3 tool updates
    • Changedbrowsercompat_check_baseline3 fields changed
      • 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."
    • Changedbrowsercompat_compare_support33 fields changed
      • 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 and gets a verdict, several keys of one web-features feature resolve to the feature as verdict ambiguous 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, 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 and gets a verdict, several keys of one web-features feature resolve to the feature as verdict ambiguous 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 / target_limit
        Added value: +{
+  "default": 10,
+  "description": "How many query targets this page covers, 1 to 10. It bounds every list of target rows in the response and never the evaluation: verdicts, coverage, and totals always describe the whole query.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / target_offset
        Added value: +{
+  "default": 0,
+  "description": "Zero-based position in the target list of the query at which this page of target rows starts. Pass the nextOffset of the previous response to continue. An offset at or past the number of targets returns the whole-query verdicts and totals with no target rows.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
      • changedOutput schema / anyOf
        Previous value: -[
-  {
-    "not": {
-      "required": [
-        "error"
-      ]
-    },
-    "required": [
-      "query_echo",
-      "targets_resolved",
-      "unchecked_targets",
-      "target_coverage_percent",
-      "unchecked_coverage_percent",
-      "results",
-      "all_clear",
-      "data_version",
-      "totalCount",
-      "attribution"
-    ]
-  },
-  {
-    "required": [
-      "error"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "query_echo",
+      "comparable_features",
+      "targets_resolved",
+      "targets_resolved_total",
+      "evaluated_targets_total",
+      "unchecked_targets",
+      "unchecked_targets_total",
+      "target_coverage_percent",
+      "unchecked_coverage_percent",
+      "results",
+      "all_clear",
+      "data_version",
+      "totalCount",
+      "shown",
+      "cap",
+      "truncated",
+      "attribution"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
      • changedOutput schema / properties / all_clear / description
        Previous value: -"True only when every feature clears and unchecked_targets is empty."New value: +"True only when every feature clears, which requires every target in the query to have been evaluated for it."
      • addedOutput schema / properties / cap
        Added value: +{
+  "description": "The target_limit that was applied.",
+  "type": "number"
+}
      • addedOutput schema / properties / comparable_features
        Added value: +{
+  "description": "How many entries in features were compared against the targets. A miss or an ambiguous entry is not comparable; at 0 nothing was evaluated.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / evaluated_targets_total
        Added value: +{
+  "description": "Query targets evaluated for every compared feature, across every page. evaluated_targets_total plus unchecked_targets_total is the number of targets in the query.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / nextOffset
        Added value: +{
+  "description": "The target_offset of the next page. Present only while targets remain past this page.",
+  "type": "number"
+}
      • addedOutput schema / properties / offsetNotice
        Added value: +{
+  "description": "Why this page carries no target rows, and the offsets that do.",
+  "type": "string"
+}
      • changedOutput schema / properties / results / description
        Previous value: -"Per-feature verdicts against the resolved targets."New value: +"Per-feature verdicts and totals over the whole query, each with its own target rows for this page."
      • addedOutput schema / properties / results / items / properties / evaluated_coverage_percent
        Added value: +{
+  "description": "Share of tracked global traffic the targets evaluated for this feature cover.",
+  "type": "number"
+}
      • addedOutput schema / properties / results / items / properties / evaluated_total
        Added value: +{
+  "description": "Query targets this feature has compatibility data for, across the whole query.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • changedOutput schema / properties / results / items / properties / failing_targets / description
        Previous value: -"Every resolved target that failed, with the verdict that caused it."New value: +"The failing targets among the query targets on this page, with the verdict that caused each. Empty on a page that holds none even when failing_total is above zero."
      • addedOutput schema / properties / results / items / properties / failing_total
        Added value: +{
+  "description": "Failing targets across the whole query. Present when the feature was compared, as are the five fields after it.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • addedOutput schema / properties / results / items / properties / unchecked_coverage_percent
        Added value: +{
+  "description": "Share of tracked global traffic the targets not evaluated for this feature cover.",
+  "type": "number"
+}
      • addedOutput schema / properties / results / items / properties / unchecked_targets
        Added value: +{
+  "description": "The targets not evaluated for this feature among the query targets on this page, each with its reason.",
+  "items": {
+    "additionalProperties": false,
+    "description": "A target this feature was not evaluated against.",
+    "properties": {
+      "agent": {
+        "description": "browserslist agent id.",
+        "type": "string"
+      },
+      "reason": {
+        "description": "no_bcd_browser when the agent has no browser-compat-data counterpart, unknown_version when the token maps to no release, no_bcd_data when a compared feature records nothing for that browser, no_comparable_feature when every entry in features was a miss or ambiguous so nothing was compared.",
+        "enum": [
+          "no_bcd_browser",
+          "unknown_version",
+          "no_bcd_data",
+          "no_comparable_feature"
+        ],
+        "type": "string"
+      },
+      "usage_percent": {
+        "description": "Share of tracked global traffic this target covers.",
+        "type": "number"
+      },
+      "version_token": {
+        "description": "Version token browserslist produced for that agent.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "agent",
+      "version_token",
+      "reason",
+      "usage_percent"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / results / items / properties / unchecked_total
        Added value: +{
+  "description": "Query targets not evaluated for this feature, across the whole query. evaluated_total plus unchecked_total is the number of targets in the query.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • changedOutput schema / properties / results / items / properties / verdict / description
        Previous value: -"clears only when every resolved target is supported; inconclusive when a target could not be evaluated, including when no target resolved at all; ambiguous when the id spans more than one compat key."New value: +"Judged over the whole query, never over one page. fails when any evaluated target does not support the feature; inconclusive when nothing failed but at least one target in the query was not evaluated for this feature, including when none was; clears only when every target in the query was evaluated and supports it; miss when the entry did not resolve; ambiguous when the id spans more than one compat key or owns none."
      • addedOutput schema / properties / shown
        Added value: +{
+  "description": "Number of query targets this page covers.",
+  "type": "number"
+}
      • changedOutput schema / properties / target_coverage_percent / description
        Previous value: -"Share of tracked global traffic the evaluated targets cover."New value: +"Share of tracked global traffic covered by the targets evaluated for every compared feature; 0 when no feature was comparable."
      • changedOutput schema / properties / targets_resolved / description
        Previous value: -"Every browserslist token that was evaluated."New value: +"The mapping inventory for the query targets on this page: each target that maps onto a browser-compat-data release, and whether it was evaluated. A target with no mapping appears only in unchecked_targets."
      • addedOutput schema / properties / targets_resolved / items / properties / evaluated
        Added value: +{
+  "description": "True when every compared feature has compatibility data for this target. False when at least one compared feature records nothing for its browser, or when no feature in the call was comparable — the target then also appears in unchecked_targets. Mapping onto a release is not evaluation.",
+  "type": "boolean"
+}
      • changedOutput schema / properties / targets_resolved / items / required
        Previous value: -[
-  "agent",
-  "version_token",
-  "bcd_browser",
-  "bcd_version",
-  "bcd_release_index"
-]New value: +[
+  "agent",
+  "version_token",
+  "bcd_browser",
+  "bcd_version",
+  "bcd_release_index",
+  "evaluated"
+]
      • addedOutput schema / properties / targets_resolved_total
        Added value: +{
+  "description": "Query targets that map onto a browser-compat-data release, across every page.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
      • changedOutput schema / properties / totalCount / description
        Previous value: -"Number of feature results returned."New value: +"Number of targets the query resolved to, across every page."
      • addedOutput schema / properties / truncated
        Added value: +{
+  "description": "True when more query targets remain past this page.",
+  "type": "boolean"
+}
      • changedOutput schema / properties / uncheckedNotice / description
        Previous value: -"Names the target agents that were not evaluated and their combined usage share."New value: +"How many of the query targets were not evaluated for every compared feature, the agents they belong to, and their combined usage share."
      • changedOutput schema / properties / unchecked_coverage_percent / description
        Previous value: -"Share of tracked global traffic the unevaluated targets cover."New value: +"Share of tracked global traffic covered by the targets counted in unchecked_targets_total."
      • changedOutput schema / properties / unchecked_targets / description
        Previous value: -"Every target the server declined to claim a verdict for, with the reason."New value: +"The query targets on this page that were not evaluated for every compared feature, each with the reason."
      • changedOutput schema / properties / unchecked_targets / items / properties / reason / description
        Previous value: -"no_bcd_browser when the agent has no counterpart, unknown_version when the token maps to no release, no_bcd_data when a feature records nothing for that browser."New value: +"no_bcd_browser when the agent has no browser-compat-data counterpart, unknown_version when the token maps to no release, no_bcd_data when a compared feature records nothing for that browser, no_comparable_feature when every entry in features was a miss or ambiguous so nothing was compared."
      • changedOutput schema / properties / unchecked_targets / items / properties / reason / enum
        Previous value: -[
-  "no_bcd_browser",
-  "unknown_version",
-  "no_bcd_data"
-]New value: +[
+  "no_bcd_browser",
+  "unknown_version",
+  "no_bcd_data",
+  "no_comparable_feature"
+]
      • addedOutput schema / properties / unchecked_targets_total
        Added value: +{
+  "description": "Query targets not evaluated for every compared feature, across every page.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
    • Changedbrowsercompat_get_feature5 fields changed
      • 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"
+}
  2. 5 tool updates
    • Changedbrowsercompat_check_baseline2 fields changed
      • 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"
+  }
+]
    • Changedbrowsercompat_compare_support2 fields changed
      • 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 rather than a confident answer about the wrong feature."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 and gets a verdict, several keys of one web-features feature resolve to the feature as verdict ambiguous 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 / 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"
+  }
+]
    • Changedbrowsercompat_get_feature2 fields changed
      • 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"
+  }
+]
    • Changedbrowsercompat_list_reference1 field changed
      • changedInput schema / properties / topic / description
        Previous value: -"Which vocabulary to list: bcd_namespaces for the 12 top-level browser-compat-data namespaces, bcd_browsers for the 17 tracked browsers, browserslist_agents for the 19 browserslist ids mapped to browser-compat-data browsers, baseline_states for the 4 Baseline states, groups for the 103 web-features groups, or snapshots for the 11 ECMAScript snapshots."New value: +"Which vocabulary to list: bcd_namespaces for the 12 top-level browser-compat-data namespaces, bcd_browsers for the 17 tracked browsers, browserslist_agents for the 19 browserslist ids mapped to browser-compat-data browsers, baseline_states for the 4 Baseline states, groups for the 104 web-features groups, or snapshots for the 11 ECMAScript snapshots."
    • Changedbrowsercompat_search_features15 fields changed
      • addedInput schema / properties / group
        Added value: +{
+  "description": "Restrict results to features in one web-features group or any group nested under it, for example \"selectors\" or \"css\". Keys with no web-features mapping never match. Call browsercompat_list_reference with topic groups for valid ids.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "default": 0,
+  "description": "Number of ranked matches to skip before returning results, for paging past limit. Pass the nextOffset from the previous response.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
      • changedInput schema / properties / query / description
        Previous value: -"Plain-language name or keyword, for example \"container query\" or \"fromAsync\"."New value: +"Plain-language name, keyword, or code notation, for example \"container query\", \"fromAsync\", \"Array.prototype.at\", \"display: grid\", or \"<dialog>\"."
      • addedInput schema / properties / snapshot
        Added value: +{
+  "description": "Restrict results to features in one ECMAScript snapshot, for example \"ecmascript-2023\". Call browsercompat_list_reference with topic snapshots for valid ids.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
      • addedOutput schema / properties / appliedFilters / properties / group
        Added value: +{
+  "description": "web-features group filter the search applied, nested groups included.",
+  "type": "string"
+}
      • addedOutput schema / properties / appliedFilters / properties / snapshot
        Added value: +{
+  "description": "ECMAScript snapshot filter the search applied.",
+  "type": "string"
+}
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `invalid_query`: query is whitespace-only after normalization, or normalizes to zero tokens. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_query`: query is whitespace-only after normalization, or normalizes to zero tokens. `unknown_group`: group names no web-features group in the bundled data. `unknown_snapshot`: snapshot names no ECMAScript snapshot in the bundled data. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "invalid_query"
-]New value: +[
+  "invalid_query",
+  "unknown_group",
+  "unknown_snapshot"
+]
      • addedOutput schema / properties / nextOffset
        Added value: +{
+  "description": "The offset of the next page. Present only while matches remain past this page.",
+  "type": "number"
+}
      • addedOutput schema / properties / offsetNotice
        Added value: +{
+  "description": "Why a page came back empty although the search matched.",
+  "type": "string"
+}
      • changedOutput schema / properties / results / items / properties / matched_on / description
        Previous value: -"Which field matched the query, so the ranking can be inspected."New value: +"Which field matched the query, so the ranking can be inspected. path_suffix means the key ends in the dotted or property-value notation the query used, such as Element.animate or display: grid."
      • changedOutput schema / properties / results / items / properties / matched_on / enum
        Previous value: -[
-  "bcd_key",
-  "baseline_id",
-  "name",
-  "caniuse_title",
-  "path_segment",
-  "description",
-  "path_tokens"
-]New value: +[
+  "bcd_key",
+  "baseline_id",
+  "name",
+  "caniuse_title",
+  "path_suffix",
+  "path_segment",
+  "description",
+  "path_tokens"
+]
      • changedOutput schema / properties / shown / description
        Previous value: -"Number of results returned."New value: +"Number of results on this page."
      • changedOutput schema / properties / totalCount / description
        Previous value: -"Matches before the display cap was applied."New value: +"Matches across every page, before offset and limit apply."
      • changedOutput schema / properties / truncated / description
        Previous value: -"True when matches exceeded limit."New value: +"True when more matches remain past this page."
  3. 5 tool updates
    • First observedbrowsercompat_check_baseline
    • First observedbrowsercompat_compare_support
    • First observedbrowsercompat_get_feature
    • First observedbrowsercompat_list_reference
    • First observedbrowsercompat_search_features

Related MCP Connectors

Related MCP Servers

  • Baseline Checker

    htshongany
    A
    license
    A
    quality
    D
    maintenance
    Enables checking web feature compatibility with Baseline standards, analyzing HTML, CSS, and JavaScript code to provide detailed reports on Baseline status, browser support, and recommendations.
    2
    MIT

  • CSS MCP Server

    stolinski
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides up-to-date CSS documentation and browser compatibility data from MDN through natural language queries. Features intelligent caching and supports all CSS properties, selectors, functions, and concepts with automatic normalization.
    169 npm
    335
    ISC
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.

Resources