Skip to main content
Glama

CSS SOTA

by io.github.LuSrodri

Search CSS features

search_css_features
Read-only

Search CSS features on the Web Platform Dashboard (webstatus.dev) by keyword, Baseline status, and the date range in which they reached Baseline. Use this to answer questions like "which CSS features for scroll animations are Baseline yet?" or "what limited-support CSS is there for anchoring?". Returns live Baseline data. For the browser versions a specific property shipped in, use check_support instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of features to return.
queryNoFree-text search over feature names and descriptions, e.g. "container queries", "anchor", "scroll". Omit to list all CSS features matching the other filters.
sinceNoOnly features that became Baseline Newly available on or after this date (YYYY-MM-DD). Combined with `baseline`, this means "went Newly in this range AND is status X today".
untilNoOnly features that became Baseline Newly available on or before this date (YYYY-MM-DD).
baselineNoFilter by Baseline status: "widely" (interoperable for 30+ months, safe to use), "newly" (interoperable across all major engines recently), or "limited" (not yet available across all major engines).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe dashboard query that was executed.
totalNoTotal matches upstream, across all pages.
featuresYes
truncatedYesWhether more matches exist than were returned.

Schema Changelog

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

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate read-only and open-world behavior. The description adds 'Returns live Baseline data,' which clarifies the data source is real-time and not cached, and clarifies the meaning of Baseline through examples. This goes beyond the annotations without contradicting them.

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: purpose, usage examples, and alternative. No wasted words; information is front-loaded and directly relevant to tool selection and invocation.

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?

Given the 5 parameters, read-only/open-world annotations, and presence of an output schema, the description covers the essential aspects: what it does, when to use it, the live-data nature, and an explicit alternative. It does not need to explain return values since an output schema exists.

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 input schema provides 100% coverage of parameter descriptions, so the schema does the heavy lifting. The description only summarizes the filter dimensions (keyword, baseline status, date range) without adding new syntax or format details beyond what the schema already specifies.

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 clearly states the tool searches CSS features on the Web Platform Dashboard with specific filters (keyword, Baseline status, date range). It distinguishes itself from check_support by explicitly naming that sibling for version-specific queries, and it provides concrete example questions.

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?

It explicitly describes when to use this tool ('Use this to answer questions like...') and points to an alternative (check_support) for a different use case. This gives clear guidance on tool selection among siblings.

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