io.github.cyanheadsPublished by GitHub account cyanheadsv0.3.0Updated Oct 26, 2026
Browser compatibility and Baseline status for any web feature — offline, from bundled MDN data.
Offline browser-compatibility lookup: lets an assistant check Baseline status, per-browser support and browserslist target fit for web features.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.cyanheads%2Fbrowser-compat-mcp-server/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"browser-compat": {
"type": "http",
"url": "https://browser-compat.caseyjhand.com/mcp"
}
}
}Browser compatibility and Baseline status for any web feature — offline, from MDN's browser-compat-data, web-features, and caniuse. STDIO or Streamable HTTP.
Public Hosted Server: https://browser-compat.caseyjhand.com/mcp
Browser support and Baseline status for any web platform feature, from MDN's @mdn/browser-compat-data, web-features, and caniuse-lite usage data. Check whether a feature is safe to ship against your browserslist targets. All data ships in the package: no network calls, no API key, no rate limit.
The browser-compat-guide covers assessing code against a project's browser policy and diagnosing historical support failures. It ships with plugin, npm, Docker, and MCPB installs and is available over MCP at skill://browser-compat-guide/SKILL.md.
browsercompat_list_reference tooltopic: bcd_namespaces (12), bcd_browsers (17), browserslist_agents (19), baseline_states (4), groups (104), or snapshots (11). Group and snapshot ids feed the search filters.id, label, and detail, plus count, reported, bcd_browser, usage_percent, maps_from, or spec_url where applicable. An agent's bcd_browser: null means support comparisons cannot evaluate it and report it in unchecked_targets.browsercompat_get_feature toolfeature, 1–200 characters: a BCD key (css.selectors.has) or web-features id (has). resolve: true (off by default) also accepts a name or notation when it matches exactly one feature. include_runtimes: true adds bun, deno, nodejs, and oculus support rows.outcome is found, no_compat_data, or miss; a miss returns found: false with guidance, and whitespace-only input returns invalid_feature_input. Each support row gives the newest release's statement, with the other BCD statements for that browser in other_statements.grid returns feature_support (one row per Baseline core browser) instead of support, status, mdn_url, and spec_urls; call one of its compat_keys for a key-level answer. compat_keys and subkeys page 100 at a time with compat_keys_offset and subkeys_offset (default 0). limiting_browser is the Baseline core browser with the newest required release.browsercompat_check_baseline toolomitted_features. More than 100 is rejected, and a whitespace-only entry returns invalid_feature_input.limiting_browser, deprecated, experimental, and discouraged, plus usage_percent_excluded and usage_source where caniuse covers the feature. Usage is left out when unavailable, never reported as zero.all_widely_available is true only when every entry resolves at widely and none was omitted; it does not assess deprecation.browsercompat_search_features toolquery, 1–100 characters, accepts names, keywords, or notation such as Array.prototype.at, display: grid, or <dialog>. Combine namespace (12 BCD namespaces), baseline (widely, newly, limited, not_mapped), group (including nested groups), and snapshot (such as ecmascript-2023).matched_on says why a result ranked where it did, and support_summary covers the seven Baseline core browsers: Firefox 33 (flagged), Safari 3 (prefixed), Chrome 94 (partial), and Edge ≤18 preserve the selected verdict and addition bound; — means unsupported, removed, or preview-only, and ? means unknown. Typed failures: invalid_query (zero searchable tokens), unknown_group, unknown_snapshot.limit (default 10, at most 50; larger values are served as 50 and reported in cap) and offset (default 0); totalCount and nextOffset drive paging. Zero hits succeed with a notice naming a filter to drop.browsercompat_compare_support tooltargets browserslist query, such as defaults or > 0.5%, last 2 versions; config packages and custom configuration are rejected, and local config discovery is disabled. Up to 100 features are accepted and the rest come back in omitted_features, which makes all_clear false. Typed failures: invalid_target_query, no_targets_resolved, invalid_feature_input.verdict is clears, fails, inconclusive, miss, or ambiguous. A feature clears only when every target in the query was evaluated and supports it, so a query that includes a browser with no compatibility data, as defaults does, never clears. all_clear is true only when every feature clears.support_source, failing_ranges, failing_total, and evaluated and unchecked totals with coverage percentages. Target rows page with target_offset (default 0) and target_limit (default 10, at most 10; larger values are served as 10 and reported in cap); verdicts and totals are the same on every page, and totalCount and nextOffset drive paging.CC BY 4.0 requires attribution wherever the caniuse data travels, so every response carrying a usage figure carries this string: Usage data from caniuse.com, © Can I Use contributors, CC BY 4.0. Figures are percentage points of global traffic. The bundled data tracks ~97.5% of global traffic; the remainder is untracked and unknown. Values are raw global percentages, without normalization to tracked traffic. Full license texts and notices are in THIRD_PARTY_NOTICES.md.
Built on @cyanheads/mcp-ts-core: stdio and Streamable HTTP transports, pluggable auth (none / jwt / oauth), swappable storage (in-memory, filesystem, Supabase, Cloudflare KV/R2/D1), structured logging with optional OpenTelemetry tracing.
Browser-compat-specific:
status.by_compat_key, never rolled up from the feature level, because keys under one feature legitimately disagreemoved redirectsafari 16.0 ↔ 16)Agent-friendly output:
data_version, the version of each bundled dataset behind the answerunchecked_targets and make the verdict inconclusivefound: false with guidance naming the next call, and typed errors with recovery hintsA public instance is available at https://browser-compat.caseyjhand.com/mcp — no installation required. Point any MCP client at it via Streamable HTTP:
Add the following to your MCP client configuration file:
Or with npx (no Bun required):
Or with Docker:
For Streamable HTTP, set the transport and start the server:
There are no server-specific environment variables: no API keys, no base URLs, and deliberately no browserslist configuration variable — the target query is always a tool input rather than ambient state. Framework transport, logging, and telemetry settings remain configurable.
See .env.example for the full list of optional framework overrides.
The Dockerfile defaults to HTTP transport, stateless session mode, and logs to /var/log/browser-compat-mcp-server. OpenTelemetry peer dependencies are installed by default — build with --build-arg OTEL_ENABLED=false to omit them.
The generated file tree is docs/tree.md.
See CLAUDE.md for development guidelines and architectural rules. The short version:
try/catch in tool logicctx.log for request-scoped logging, ctx.state for tenant-scoped storagesrc/index.tsIssues are welcome. Run checks and tests before submitting:
Apache-2.0 — see LICENSE for details.
Source: README.md at commit 7cc81e5
Browsercompat List Reference
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.
topicrequiredBrowsercompat Get Feature
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 — with every other support statement recorded for that browser, such as an earlier prefixed or flagged release, in other_statements — 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. A web-features id that spans several BCD keys, such as grid, returns web-features’ own feature-level release per Baseline core browser in feature_support and its compat_keys, 100 per page, in place of per-key fields. An unresolved feature returns found: false with guidance rather than an error.
featurerequiredresolvesubkeys_offsetinclude_runtimescompat_keys_offsetBrowsercompat Check Baseline
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 percentage points of global traffic that requiring it would exclude. Evaluates up to 20 BCD keys or web-features ids per call; up to 100 may be sent, and entries past the 20th come back unevaluated in omitted_features for the next call.
resolvefeaturesrequiredBrowsercompat Search Features
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.
grouplimitqueryrequiredoffsetbaselinesnapshotnamespaceBrowsercompat Compare Support
Compute whether a set of web features clears an explicit browserslist target query. Compares up to 20 features per call; up to 100 may be sent, and entries past the 20th come back unevaluated in omitted_features for the next call. Every call evaluates the whole query: each feature gets a verdict, the count of failing targets, those targets grouped into runs of consecutive query targets per browser in failing_ranges, and its own evaluated and unevaluated target counts with the percentage points of global 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, a failing row carrying the prefix, alternative name, or flag behind its verdict — 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. A BCD key is judged on its own per-browser support. A web-features id spanning several keys, such as grid, is judged on the release web-features lists for the feature as a whole in each Baseline core browser, as support_source says; its other browsers are not evaluated.
resolvetargetsrequiredfeaturesrequiredtarget_limittarget_offset100% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
{ "mcpServers": { "browser-compat-mcp-server": { "type": "streamable-http", "url": "https://browser-compat.caseyjhand.com/mcp" } }}{ "mcpServers": { "browser-compat-mcp-server": { "type": "stdio", "command": "bunx", "args": ["@cyanheads/browser-compat-mcp-server@latest"], "env": { "MCP_TRANSPORT_TYPE": "stdio", "MCP_LOG_LEVEL": "info" } } }}{ "mcpServers": { "browser-compat-mcp-server": { "type": "stdio", "command": "npx", "args": ["-y", "@cyanheads/browser-compat-mcp-server@latest"], "env": { "MCP_TRANSPORT_TYPE": "stdio", "MCP_LOG_LEVEL": "info" } } }}{ "mcpServers": { "browser-compat-mcp-server": { "type": "stdio", "command": "docker", "args": [ "run", "-i", "--rm", "-e", "MCP_TRANSPORT_TYPE=stdio", "ghcr.io/cyanheads/browser-compat-mcp-server:latest" ] } }}MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 bun run start:http# Server listens at http://localhost:3010/mcpgit clone https://github.com/cyanheads/browser-compat-mcp-server.gitcd browser-compat-mcp-serverbun installcp .env.example .env# edit .env if you want to override transport or logging defaults# One-time buildbun run rebuild
# Run the built serverbun run start:stdio# orbun run start:httpbun run devcheck # Lint, format, typecheck, securitybun run test # Vitest test suitebun run lint:mcp # Validate MCP definitions against specdocker build -t browser-compat-mcp-server .docker run --rm -p 3010:3010 browser-compat-mcp-serverbun run devcheckbun run test