Skip to main content
Glama

CSS SOTA

by io.github.LuSrodri

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueNoA 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_keyNoA 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.
propertyNoA CSS property name, e.g. "display", "anchor-name". Used when bcd_key is absent.
all_browsersNoInclude every browser in the dataset (Opera, Samsung Internet, WebView, IE) rather than only the seven that determine Baseline.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
specYes
mdnUrlYes
supportYes
baselineYes
resolvedYes
featureIdYes
deprecatedYes
suggestionsYes
experimentalYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: audit_css checks a stylesheet, check_support looks up browser versions for a specific feature, search_css_features finds features by keyword, and whats_new lists recent Baseline crossings. However, check_support and get_feature both provide browser support info, and get_feature also includes shipped versions, which could cause an agent to pick the wrong one for a quick lookup.

Naming Consistency4/5

All tool names use lowercase snake_case, which is consistent. Most follow a verb_noun pattern (audit_css, check_support, get_feature, search_css_features), but 'dont_make_me_think' is an idiomatic phrase and 'whats_new' is a question-like phrase, breaking the strict verb_noun consistency.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose of providing CSS support and Baseline information. Each tool covers a distinct aspect (auditing, lookup, search, news, deep-dive, and UX review), and none feels redundant or missing within the stated domain.

Completeness5/5

The tool set provides a complete workflow: audit a stylesheet, check specific support, search for features, get detailed feature info, and see what's new. There are no obvious gaps for a CSS support and Baseline status server, and the additional UI/UX review tool expands coverage without creating dead ends.

Resources