Skip to main content
Glama

Extract design tokens

extract_design_tokens
Read-onlyIdempotent

Use when the user wants a site's complete token system - every color, font family, size, weight, spacing value, radius, shadow, line height, gradient and breakpoint with usage counts - or a paste-ready :root block (format='css'), tailwind.config (format='tailwind') or W3C Design Tokens file (format='dtcg'). Returns values and counts only, not layout or which element uses what: if the user asked to rebuild or clone a section, use extract_code, which returns the markup with the values in place. A site shipping light and dark themes returns the union of both (see colorSchemes) - pick colors by role, not by frequency. Not for: a short brand summary (use extract_brand). Lists trim to 60 per group; pass limit (up to 200) for more.

Input Schema

NameRequiredDescriptionDefault
urlYesThe website URL
freshNoSkip the 24-hour cache and re-extract the live page - use when the site just changed and a cached result would be stale. Charged normally; the fresh result replaces the cached copy.
limitNoMax entries per token list (default 60, up to 200).
formatNoOutput shape (default json). 'css'|'tailwind' return a paste-ready code block; 'dtcg' returns a standalone W3C Design Tokens file for Style Dictionary / Figma variables pipelines.
renderNoForce a real browser so the page's JavaScript runs before it is read. Slower, and adds 5 credits. Usually not needed: when the plain read comes back as a JavaScript app shell or the site refuses it (401/403/406) or timed out, the server already re-runs the page in a browser by itself at no extra cost, and usage.autoRender says so. Pass it for images, videos or Lottie that only load on scroll, with screenshot=true, or when a result is still thin after that automatic pass. If a 403 says the browser was refused too, the site cannot be extracted - do not retry. extract_code always runs in a real browser at no extra cost, so render=true is not needed there (only together with screenshot=true). On extract_design_tokens, render=true only permits the browser: the plain read still runs first, and the 5 credits are charged only if the browser was actually needed.
screenshotNoRequires render=true. Adds a screenshot field to the result: a public URL of a capture of the page (live 7 days), taken by the same browser that rendered it. Pass true for the 1440x900 viewport or 'full' for the entire page height. No extra credits beyond the render surcharge. Useful for showing the user what the extracted site looks like.
full_outputNoSkip long-string trimming. Responses still cap at ~100KB total.
response_formatNoHow much to return. 'concise' keeps lists to 10 entries and strings short - right for a summary or a chat answer. 'detailed' returns everything the tool has (same as limit=200 + full_output=true). Omit for the default, which fits a typical chat context. The generated code is never trimmed in any mode.

Output Schema

NameRequiredDescriptionDefault
urlNo
nextNoThe most likely follow-up call for this result, with the tool and arguments to use. Offer it to the user when it fits what they are doing.
usageNoCredit usage for the authed key (spent, remaining, monthly limit).
colorsNoEvery color with usage count
outputNoThe paste-ready :root{} or tailwind.config block when format='css'|'tailwind'
spacingNoThe spacing scale from margin/padding/gap
summaryNoCount per token group
fontSizesNoFont sizes with usage counts
gradientsNoGradients with type (linear/radial/conic) and count
boxShadowsNoBox shadows
breakpointsNoResponsive breakpoints from media queries
fontWeightsNoFont weights
lineHeightsNoLine heights
colorSchemesNoThe colour schemes this page declares: ["light"] or ["light","dark"]. When both, the counts above are the union of the two themes and neither is labelled - pick colours by role, not by frequency, and use extract_code with theme=dark when you need one theme on its own
fontFamiliesNoFont families with usage counts
borderRadiusesNoBorder radii
truncation_noteNoPresent when the result was trimmed to fit chat context - says what was dropped and how to get more (limit / full_output arguments, or the REST API).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the read-only/idempotent annotations: it discloses that only values and counts are returned (not layout or element mapping), that light+dark themes return the union of both, and that lists trim to 60 per group unless limit is raised. It also warns against picking colors by frequency.

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?

Dense and front-loaded with routing and scope first, then format options, then exclusions and limit behavior. It is a long, multi-clause single paragraph with some run-on sequencing, but nearly every clause carries decision-relevant information.

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 an output schema exists, return-value specifics need not be restated, and the description still covers scope, format choice, theme handling, trimming limits, and sibling routing. Nothing an agent needs to select and call this tool correctly is absent.

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 carries full semantics for all 8 parameters including format, limit, render, and screenshot. The description echoes format semantics (paste-ready :root block, tailwind.config, W3C file) and the limit cap without adding new parameter-level detail. Baseline 3 applies.

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?

States a specific verb+resource (extract a site's complete token system) and enumerates the concrete scope covered (colors, fonts, spacing, radius, shadows, gradients, breakpoints) plus the three output formats. It explicitly differentiates from siblings extract_code and extract_brand by name.

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?

Gives explicit when-to-use (complete token system, or paste-ready code block), when-not-to ('Not for: a short brand summary'), and a routing rule with the alternative named ('if the user asked to rebuild or clone a section, use extract_code'). Format-selection guidance for json/css/tailwind/dtcg is folded in.

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.