Skip to main content
Glama

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. It obeys the site's robots.txt for CSSCremeBot: a disallowed path is refused with ROBOTS_DENIED, which a retry will not change. A bot challenge, a parked or for-sale domain, or a host's default page is refused with NOT_THE_SITE and the evidence, rather than measured as if it were the site. Every error starts with its code and a retry verdict (never, later, with-changes). A read is reused for up to maxAge seconds (default 600, 0 for fresh), and every result carries work: the requests it made of the site. 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).
maxAgeNoHow old a reused read may be, in seconds. Default 600; 0 reads the site now. A reused read keeps its own fetchedAt and says cache.hit: true.
expectSpecNoOptional brand spec to check field by field, for example {"primary":"#635BFF","bg":"#FFFFFF","font":"Inter","heading":"Sohne","radius":"8px","base":"16px","spacing":"4px","darkMode":true,"tokens":{"--brand":"#635BFF"}}. The json response then carries `compliance`: per field a verdict (match, near, different, not-declared), what it was compared against, and the value found. not-declared means the site gives nothing to compare; it is never filled with the nearest guess.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / expectSpec
      Added value: +{
      +  "description": "Optional brand spec to check field by field, for example {\"primary\":\"#635BFF\",\"bg\":\"#FFFFFF\",\"font\":\"Inter\",\"heading\":\"Sohne\",\"radius\":\"8px\",\"base\":\"16px\",\"spacing\":\"4px\",\"darkMode\":true,\"tokens\":{\"--brand\":\"#635BFF\"}}. The json response then carries `compliance`: per field a verdict (match, near, different, not-declared), what it was compared against, and the value found. not-declared means the site gives nothing to compare; it is never filled with the nearest guess.",
      +  "type": "object"
      +}
    • addedInput schema / properties / maxAge
      Added value: +{
      +  "description": "How old a reused read may be, in seconds. Default 600; 0 reads the site now. A reused read keeps its own fetchedAt and says cache.hit: true.",
      +  "maximum": 3600,
      +  "minimum": 0,
      +  "type": "integer"
      +}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavioral detail beyond those: it reads CSS without rendering, reports confidence levels, obeys robots.txt with ROBOTS_DENIED, refuses bot challenges and parked domains with NOT_THE_SITE, returns retry verdicts, reuses reads up to maxAge, and reports the requests made. This is far more than the annotations alone provide.

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 long but information-dense: every sentence introduces a distinct behavior or constraint, from robots.txt handling to retry verdicts to cache reuse. It is front-loaded with the core purpose, though the single-paragraph format with many semicolon-separated clauses makes it harder to scan than it could be.

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?

There is no output schema, so the description carries the burden of explaining what the tool returns. It covers the measured design properties, the drop report, confidence levels, error codes and retry verdicts, cache behavior, the 'work' field, and the available format artifacts. This is sufficient for an agent to understand the tool's behavior and invoke it correctly.

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?

Schema description coverage is 100%, so the schema already documents url, expect, format, maxAge, and expectSpec in detail. The description adds context about caching and the 'work' field, but it does not materially enrich parameter meaning beyond what the input schema already provides, so the baseline score of 3 is appropriate.

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 opens with a specific verb and resource: 'Fetch a public site's HTML and stylesheets and return what its CSS declares,' followed by concrete outputs like custom properties, colors, font stacks, border radii, spacing, and framework. It clearly describes what the tool does, but it does not explicitly name or contrast sibling tools, so differentiation is left mostly to the reader.

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?

The description ends with an explicit use case: '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.' This gives clear context for when to invoke it, but it does not state when not to use it or name alternatives such as decode_site or get_design_md_for_url.

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.