Skip to main content
Glama
yujeongJeon

caniuse-mcp

by yujeongJeon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

📊 Caniuse MCP

npm version License: MIT

A Model Context Protocol (MCP) server providing browser compatibility data and web API support information using the caniuse.com database.

Features

  • Multiple Data Sources: Combines data from CanIUse, MDN BCD, and Web Features for comprehensive compatibility information

  • Browser Compatibility Data: Get detailed compatibility information for web features across all major browsers

  • Baseline Status: See Web Features baseline status (high/low) for modern browser support

  • Feature Search: Look up web features by name using comprehensive databases

  • Always Up-to-Date: Queries the latest compatibility data in real-time

  • MCP Compatible: Works seamlessly with any MCP-compatible client

  • Smart Feature Sampling: Provides accurate compatibility data through intelligent sampling of feature variants and edge cases

NOTE

However, some MCP clients may not support sampling features, which could affect the comprehensiveness of the compatibility information returned.

Related MCP server: DevServer MCP

Installation

npm install -g caniuse-mcp

Or with pnpm:

pnpm add -g caniuse-mcp

Usage

As an MCP Server

Add to your MCP client configuration.

Vscode with copilot:

{
  "servers": {
    "caniuse": {
      "command": "npx",
      "args": ["-y", "caniuse-mcp"]
    }
  }
}

Claude desktop:

{
  "mcpServers": {
    "caniuse": {
      "command": "npx",
      "args": ["-y", "caniuse-mcp"]
    }
  }
}

Available Tools

1. caniuse_feature

Look up browser compatibility for web features.

Parameters:

  • feature (string): The feature to look up (e.g., "flexbox", "grid", "promises", "fetch")

Example:

Please tell me the scope of the "promises" browser support.

Response:

Returns detailed compatibility information from multiple sources:

CanIUse Data:

  • Support status for major browsers: Chrome, Firefox, Safari, Edge, iOS Safari, Chrome Android

  • Version-specific support information

  • Partial support details

  • Notes about implementation differences

  • Polyfill availability

Web Features Data:

  • Baseline status (high/low/false) indicating cross-browser support maturity

  • Related MDN documentation IDs

  • Specification links

  • Modern browser support information

MDN Browser Compatibility Data:

  • Detailed API/feature support

  • Experimental and deprecated status

  • Standard track information

2. browserslist_compatibility_check

Check web feature compatibility against your browserslist configuration.

Parameters:

  • feature (string): The feature to check compatibility for

  • browserslistQuery (string, optional): Browserslist query string (e.g., "> 1%, last 2 versions")

  • configPath (string, optional): Path to .browserslistrc file

  • projectPath (string, optional): Path to project root with package.json or .browserslistrc

Example:

Check if array.at is compatible with my browserslist config: ">= 1%, not dead, Chrome >= 106, ios_saf >= 16"

Response:

Returns compatibility results filtered by your target browsers:

  • Target browser list from your browserslist query

  • Feature support status for each target browser version

  • Identifies compatibility issues with specific browser versions

  • Combines data from CanIUse, MDN BCD, and Web Features

Use Cases:

  • Validate new web features against your project's browser support policy

  • Check if a feature works in your target browsers before using it

  • Analyze compatibility with company-specific browserslist configurations

  • Ensure features work in specific browser version ranges

3. list_tools

List all available tools and their descriptions.

Example Response:

# Available Tools in caniuse-mcp

## caniuse-feature
Look up the compatibility of web features across different browsers using data from caniuse.com.

## browserslist-compatibility-check
Check web feature compatibility against your browserslist configuration.

## list-tools  
List all available tools and their descriptions

Supported Browsers

  • Desktop: Chrome, Firefox, Safari, Edge

  • Mobile: iOS Safari, Android Chrome, Samsung Internet

  • Legacy: Internet Explorer (with polyfill information)

Feature Categories

The server supports compatibility data for:

  • CSS Properties & Values

  • HTML Elements & Attributes

  • JavaScript APIs

  • Web APIs (Fetch, WebSockets, etc.)

  • ECMAScript Features

  • Media & Graphics APIs

  • Security Features

  • Performance APIs

  • And many more...

Development

Prerequisites

Setup

# Clone the repository
git clone https://github.com/yujeongJeon/caniuse-mcp.git
cd caniuse-mcp

# Install dependencies
pnpm install

# Build the project
pnpm build

Scripts

  • pnpm build - Build the TypeScript project

  • pnpm lint - Run ESLint

  • pnpm prettier - Check code formatting

  • pnpm fix - Fix linting and formatting issues

Project Structure

src/
├── index.ts              # Main server entry point
├── lib/
│   ├── browserslist.ts   # Browserslist query parser
│   ├── caniuse-api.ts    # Caniuse API client
│   ├── caniuse-db.ts     # Data processing utilities
│   ├── compat-utils.ts   # Multi-source compatibility data aggregation
│   ├── consts.ts         # Constants and configuration
│   ├── mdn.ts            # MDN compatibility data
│   └── web-features.ts   # Web Features baseline data
└── tools/
    ├── index.ts          # Tools registry
    ├── registry.ts       # Tool registration system
    ├── browserslist-compat/
    │   ├── index.ts      # Browserslist compatibility
    │   └── schema.ts     # Input validation schemas
    ├── caniuse/
    │   ├── index.ts      # Multi-source feature 
    │   └── schema.ts     # Input validation schemas
    └── list-tools/
        └── index.ts      # Tools listing functionality

API Reference

Tool: caniuse_feature

Fetches compatibility data for a specified web feature.

Input Schema:

{
  feature: string // Feature name to look up
}

Output:

  • Comprehensive browser support information

  • Version-specific compatibility data

  • Implementation notes and caveats

  • Polyfill availability information

Tool: browserslist_compatibility_check

Checks web feature compatibility against browserslist configuration.

Input Schema:

{
  feature: string // Feature name to check
  browserslistQuery?: string // Browserslist query string
  configPath?: string // Path to .browserslistrc file
  projectPath?: string // Path to project root
}

Output:

  • Target browser list from browserslist query

  • Feature support status filtered by target browsers

  • Compatibility issues with specific browser versions

  • Combined data from CanIUse, MDN BCD, and Web Features

Tool: list_tools

Lists all available tools in the MCP server.

Input Schema:

{} // No parameters required

Output:

  • Tool names and descriptions

  • Usage information

  • Available functionality overview

Contributing

  1. Fork the repository

  2. Create your feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add some amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

License

This project is licensed under the MIT License

Data Sources

This MCP server combines compatibility data from multiple authoritative sources:

By leveraging these three complementary data sources, the server provides the most complete and accurate browser compatibility information for web developers:

  • CanIUse provides detailed version-by-version support history

  • Web Features offers baseline status to quickly understand cross-browser maturity

  • MDN BCD adds specification details and experimental/deprecated flags

References

Made with ❤️ by yujeongJeon

Available Tools

3 tools
browserslist_compatibility_checkA

Check web feature compatibility against your browserslist configuration. This tool analyzes whether a web feature is supported by the browsers specified in your browserslist query, .browserslistrc file, or package.json browserslist field.

ParametersJSON Schema
NameRequiredDescriptionDefault
featureYesThe web feature to check compatibility for, e.g., "flexbox", "grid", "es6", "array.findindex"
configPathNoPath to browserslist config file (.browserslistrc or package.json)
projectPathNoProject root path to automatically find browserslist config
browserslistQueryNoBrowserslist query string, e.g., "> 1%, last 2 versions, not dead"

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It clearly indicates the tool reads and analyzes browserslist configuration rather than modifying anything, which is useful. However, it does not describe what happens if no config is found, how sources take precedence, or what the result format looks like, so some behavioral ambiguity remains.

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 contain no filler, and the primary action is front-loaded in the first sentence. The second sentence expands only with the concrete configuration sources, all of which are relevant to invoking the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does and which configuration sources it reads, which is sufficient to invoke it. However, there is no output schema and the description does not describe the return value, failure behavior, or how to choose between this and caniuse_feature, leaving some uncertainty about what to expect after the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The schema already documents feature, configPath, projectPath, and browserslistQuery with examples; the description adds no parameter-specific meaning beyond restating the config-source options, so it neither improves nor undermines the already complete schema documentation.

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: 'Check web feature compatibility against your browserslist configuration.' It names the concrete config sources (query, .browserslistrc, package.json browserslist field), and this configuration-scoped behavior clearly distinguishes it from the broader caniuse_feature sibling without needing to inspect schemas.

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 makes the usage context clear: use this tool when you want to evaluate a feature against the browsers defined by a browserslist source. It does not explicitly name caniuse_feature as the alternative for general compatibility lookups, so there is no when-not-to-use guidance, but the intended scenario is well implied.

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

caniuse_featureB

Look up the compatibility of web features across different browsers using data from caniuse.com.

ParametersJSON Schema
NameRequiredDescriptionDefault
featureYesThe feature to look up on caniuse.com, e.g., "flexbox", "grid", "es6", "array.at"

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'look up' implies a read-only operation with no side effects, which is helpful, but the description does not disclose response format, network dependency, or any limitations. It does not contradict annotations because no annotations are present.

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?

The description is a single, direct sentence with no filler words. It front-loads the action and resource, and includes the data source. Every part of the sentence earns its place, making it highly concise and well structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter lookup tool, the description is adequate. However, with no output schema and no annotations, it does not explain what the returned compatibility data looks like or how this tool differs from the sibling browserslist_compatibility_check. These are notable gaps, though the tool is simple enough that an agent can likely call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the 'feature' parameter already well documented and accompanied by examples. The description adds the context of caniuse.com as the data source, but it does not meaningfully extend the parameter semantics beyond what the schema already provides.

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 'look up' and a clear resource: compatibility of web features across different browsers, sourced from caniuse.com. It is clear and unambiguous, though it does not explicitly distinguish itself from the sibling tool browserslist_compatibility_check, which likely performs a similar compatibility lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention the sibling tools or any criteria for choosing between caniuse_feature and browserslist_compatibility_check. It simply states what the tool does, leaving usage decisions entirely to the agent.

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

list_toolsA

List all available tools and their descriptions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations are present, so the description carries the full burden. It clearly indicates a read-only listing operation, but does not describe the return format, ordering, or any potential limitations. The gap is minor for such a simple tool, but still present.

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?

A single, front-loaded sentence with no filler. It communicates the action and the outcome efficiently.

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?

For a zero-parameter discovery tool, the description is essentially complete: it tells the agent what the tool lists and what each tool entry includes. The only slight gap is not specifying the exact response schema, but the absence of parameters and the simple metadata listing reduce the need for more detail.

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?

The tool has zero parameters, and schema description coverage is 100%. With no parameters to describe, the description has no additional semantic burden. Baseline 4 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?

States a specific verb 'List' and a specific resource 'all available tools and their descriptions'. This clearly distinguishes it from sibling tools, which focus on browser feature data and compatibility checks.

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?

The intended use is implied: call this tool when you need an inventory of available tools. However, the description gives no explicit alternatives or exclusion criteria, so an agent must infer when not to use it.

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 updatesv1.1.2
    • First observedbrowserslist_compatibility_check
    • First observedcaniuse_feature
    • First observedlist_tools
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation4/5

caniuse_feature and browserslist_compatibility_check both concern browser compatibility, but one is a general feature lookup while the other evaluates a browserslist configuration. list_tools is clearly a meta tool. The descriptions do enough to keep the two domain tools from being easily confused.

Naming Consistency3/5

list_tools follows a verb_noun pattern, while caniuse_feature and browserslist_compatibility_check are noun-like compound names rather than action-oriented commands. All names are snake_case, so the inconsistency is noticeable but not chaotic.

Tool Count4/5

Three tools is a reasonable size for a focused read-only compatibility server. list_tools is somewhat redundant as a meta tool, but it does not significantly harm the overall scope.

Completeness4/5

The core workflows of looking up a feature and checking against a browserslist configuration are covered. A search or listing tool for available caniuse feature names would make the set more complete, but agents can work around this if they know the feature slug.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers