DESIGN.md Linter & Extractor

Extract a DESIGN.md file from a public webpage

extract_design_md

Read-only

Writes a starter DESIGN.md file from the CSS of one public webpage. Best for: a user who gives a website address and wants its colors, fonts, spacing, corner radii and component styles as a DESIGN.md file. Returns: markdown (the DESIGN.md text in the open Google format, YAML tokens then the 8 standard sections), the lint verdict of @google/design.md 0.4.0 on that text, the token counts and the number of stylesheets read. Pass url, such as "https://stripe.com"; a bare host such as "stripe.com" means https. Do not use for: pages behind a login, private or local addresses (localhost, 192.168.x.x), pages that robots.txt disallows, or a DESIGN.md file the user already has (use lint_design_md). Errors: blocked_url, invalid_url, robots_disallowed, fetch_failed and http_error each say what to send next.

Input Schema

Name	Required	Description
`url`	Yes	Address of one public webpage, such as "https://stripe.com". A bare host such as "stripe.com" means https. Only public http and https pages work: no login pages, localhost or private addresses.
`include_raw_css`	No	When true, adds the concatenated CSS that was read to rawCss. The response gets large, so leave it off unless the user asks for the CSS. Default false.
`max_stylesheets`	No	How many linked stylesheets to fetch and parse, 1 to 10. Default 5.

Output Schema

Name	Required	Description
`lint`	Yes	The official @google/design.md linter's verdict on markdown
`as_of`	Yes	ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.
`rawCss`	No	The concatenated CSS that was read; present only when include_raw_css is true
`source`	Yes	Who the data comes from, to cite and to check it against.
`document`	Yes	The extracted tokens, layout regions and rules before they are written as markdown
`markdown`	Yes	DESIGN.md in the open format (YAML tokens, then the 8 sections), ready to save
`metadata`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 19, 2026

addedOutput schema / properties / as_of

Added value: +{
+  "description": "ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.",
+  "type": "string"
+}

addedOutput schema / properties / source

Added value: +{
+  "description": "Who the data comes from, to cite and to check it against.",
+  "properties": {
+    "name": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "url"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "document",
-  "markdown",
-  "lint",
-  "metadata"
-]New value: +[
+  "document",
+  "markdown",
+  "lint",
+  "metadata",
+  "as_of",
+  "source"
+]

First observedOct 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true; the description adds substantive context beyond that — the exact return payload (markdown text, lint verdict, token counts, stylesheet count) and named error codes (blocked_url, robots_disallowed, fetch_failed) that tell the agent what to do next. The opening word "Writes" is slightly at odds with readOnlyHint phrasing, though the subsequent "Returns: markdown" clarifies it produces text rather than mutating state.

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?

Single paragraph broken into labeled segments — Best for, Returns, Pass url, Do not use for, Errors — with the core purpose front-loaded. No sentence is filler; even the error list earns its place by naming recovery actions.

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?

Output schema exists, yet the description still covers return shape, network constraints, robots behavior, and error taxonomy — everything an agent needs before calling. Nothing material is left implicit for a 3-parameter open-world fetch tool.

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 baseline is 3. The description restates the url guidance already in the schema (bare host means https) but says nothing about include_raw_css or max_stylesheets, so it adds no meaning beyond structured fields.

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 and resource ("Writes a starter DESIGN.md file from the CSS of one public webpage") and explicitly scopes it to a single page, which separates it from diff_design_md and lint_design_md. An agent can tell immediately what it produces.

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?

Has explicit "Best for:" telling when to use it (user supplies a website address and wants colors/fonts/spacing/radii as a DESIGN.md), explicit "Do not use for:" exclusions (login pages, private/localhost addresses, robots-disallowed pages), and names the sibling to use instead when a DESIGN.md already exists (lint_design_md).

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

All DESIGN.md Linter & Extractor tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.