Skip to main content
Glama

CSS Crème

by com.csscreme
OverviewDiscussionsAdmin

Decode any live site into design tokens

decode_url
Read-onlyIdempotent

Fetch a public site's HTML and stylesheets and return what its CSS declares: named custom properties that look like design tokens, the colours it uses most, its font stacks, border radii, spacing values, and the framework it appears to be built with. Also returns a "drop" report: roughly how many words a web-to-markdown reader would carry away from this page, against the design decisions it would discard, because markdown is defined by throwing the design layer away. It reads CSS and does not render the page, so it reports a confidence ("tokens" when named properties were found, "derived" when only compiled CSS was available) and flags a JavaScript shell rather than pretending every site is equally legible. Use when the user wants to match a site that is not in the catalogue, or has fetched a page as markdown and needs what that markdown lost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute public http(s) URL of the page to read.
expectNoOptional brand hex, like #635BFF. The json response then carries `expect`: the nearest value the site declares (a token when it has any, else a literal), its CIE76 distance, and whether that is within the same-colour tolerance, near, or different. A distance, not a grade.
formatNoDefault json (the measurement). Or one artefact from the same read: md (DESIGN.md), tokens (W3C DTCG tokens.json with the site's declared names by scope), css (globals.css: shadcn variables, Tailwind v4 @theme, the declared block), tailwind (v4 and v3 shapes), registry (a shadcn registry item: npx shadcn add <url>), agents (an agents.md rules block), aliases (every resolved value mapped back to the declared names that produce it, with scope), figma (a script for Figma's use_figma tool that creates a Variables collection with Light and Dark modes, built from the same mapper the CSS Crème plugin runs).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses that it reads CSS without rendering, reports confidence levels ('tokens' vs 'derived'), and flags JavaScript shells. This sets accurate expectations about limitations and output without contradicting the annotations.

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

Conciseness4/5

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

The description is front-loaded with the core mechanism, then contextual details. It is a bit long and includes explanatory color like the markdown rationale, but every sentence carries useful information; only minor trimming would improve it.

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 no output schema, the description fully explains the return values: list of CSS-derived design data, the drop report, confidence indicators, and the JavaScript-shell flag. Together with the schema-described format enum, an agent has sufficient context for correct invocation.

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 already provides 100% coverage of all parameters, including detailed descriptions for url, expect, and the format enum. The description adds no extra parameter-level meaning, so the baseline score of 3 applies.

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 names a specific verb and resource: it fetches a public site's HTML and stylesheets and returns its CSS-declared design tokens, colors, fonts, radii, spacing, and framework. The distinctive 'drop' report and confidence levels separate it from typical theme tools, though it never explicitly differentiates itself from siblings like decode_site or get_theme_tokens.

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?

Explicit 'Use when' guidance is provided for two concrete cases: matching a site not in the catalogue, and needing back the design layer lost in markdown. It stops short of naming alternatives or saying when not to use it, so it lacks full exclusionary routing.

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

All CSS Crème toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources