CSS SOTA

Check CSS browser support

check_support

Read-only

Look up which browser versions support a CSS property, value, selector, at-rule or function, from MDN browser-compat-data bundled with this server (no network call). Give either a BCD key ("css.properties.anchor-name") or a property with an optional value ("display" + "grid"). Also reports vendor prefixes, partial implementations and the Baseline status of the feature the key belongs to.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_support"
  }
}

Input Schema

Name	Required	Description
`value`	No	A value for that property, e.g. "grid" for display. Falls back to the property's own support when the value is not tracked separately.
`bcd_key`	No	A browser-compat-data key, e.g. "css.properties.text-wrap-style", "css.selectors.has", "css.at-rules.container", "css.types.color.color-mix". Takes precedence over property/value.
`property`	No	A CSS property name, e.g. "display", "anchor-name". Used when bcd_key is absent.
`all_browsers`	No	Include every browser in the dataset (Opera, Samsung Internet, WebView, IE) rather than only the seven that determine Baseline.

Output Schema

Name	Required	Description	Default
`key`	Yes
`spec`	Yes
`mdnUrl`	Yes
`support`	Yes
`baseline`	Yes
`resolved`	Yes
`featureId`	Yes
`deprecated`	Yes
`suggestions`	Yes
`experimental`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description reinforces a safe local read by stating 'no network call' and 'bundled with this server'. It also discloses output characteristics (vendor prefixes, partial implementations, Baseline status). No contradictions.

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 carrying essential information: purpose, input modes, and output extras. No redundant phrases.

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?

With an output schema present, the description doesn't need to detail return structure. It covers data source, input modes, precedence, and key output categories, making it complete for a lookup tool.

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 descriptions already cover all four parameters (100% coverage), so baseline is 3. The description adds meaningful relational semantics: bcd_key takes precedence over property/value, and value falls back to property support. This elevates it above the baseline.

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 phrase 'Look up which browser versions support' with a clear resource (MDN browser-compat-data), and enumerates the queryable entities (CSS property, value, selector, at-rule, function). This clearly distinguishes it from sibling tools like search_css_features or audit_css.

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?

It explains the two input modes (BCD key or property/value) and the precedence relationship. It does not explicitly contrast with sibling tools, but the scope is clear enough that an agent would know when to invoke it for support lookups.

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

All CSS SOTA tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.