Skip to main content
Glama

Is this CSS feature safe to ship, and who ships it

css_feature
Read-onlyIdempotent

Answers two questions about a modern CSS feature with data instead of recall. First, its Baseline status (widely available, newly available, or limited availability), the date, and which core browsers lack it, read from the open web-features dataset at build time. Second, how many of CSS Crème's curated, decoded showcase sites ship it, which ones, how many of them guard it with @supports, and the exact @supports conditions they test. Also returns a fallback note where we have one, any name the feature has shipped under before (an agent that learned the old name will otherwise write it), and the documented limits that catch people out, each cited to the page it was read on. Call it before writing CSS that uses container queries, :has(), anchor positioning, @scope, view transitions, oklch(), color-mix(), light-dark(), subgrid, scroll-driven animations, @property, text-wrap and similar, so the CSS you write is accurate for today rather than for your training date. With no feature given it returns the Ship Gap: features that are safe and mostly ignored, and features that are early and shipped anyway.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
featureNoA web-features id or a plain name: "container-queries", "has", ":has()", "anchor positioning", "oklch", "subgrid", "@scope". Omit for the whole Ship Gap summary.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds substantial context: data is read from a build-time dataset (implying potential staleness), what fields are returned (baseline, adoption, @supports conditions, fallback, prior names, limits), and that each item is cited. This exceeds what annotations alone provide and gives the agent a clear picture of behavior without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph of roughly 150 words. It is front-loaded with the main purpose, but it could be structured (e.g., bullet points) to improve scannability. Every sentence adds information, so it's not wasteful, but it is verbose for a tool with a single optional parameter.

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?

Given the tool has one optional parameter and no output schema, the description covers the key behavioral aspects: what it returns, how it sources data, the no-parameter mode, and usage timing. It doesn't specify the output format, but that's not critical for a read-only lookup. The description is sufficiently complete for an agent to know when and how to invoke it.

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 schema already describes the parameter with examples and the omit behavior (100% coverage). The description repeats similar examples but doesn't add new semantic meaning beyond what the schema already conveys. Baseline of 3 applies because the schema does the heavy lifting.

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 answers two specific questions about a CSS feature: Baseline status and adoption among showcase sites, with data from specific sources. It lists example features and even mentions the no-parameter Ship Gap mode. This is a precise verb+resource definition, and no sibling tool overlaps with this functionality.

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 gives a direct usage instruction: 'Call it before writing CSS that uses...' and lists concrete examples. It also explains the alternative mode (no feature returns Ship Gap). It doesn't mention explicit exclusions, but with no competing tool, this is not a gap. Clear context is provided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.