What can you do with this server?

This server lets you control the real claude.ai/design web app from your editor or agent, driving your own logged-in browser session to create, iterate on, and manage AI-generated web designs. * Login: One-time browser-based authentication to claude.ai/design; session persists for all subsequent operations. * List Projects: Retrieve all your existing Claude Design projects from your account. * Create a Design: Submit a prompt to generate a new design project, with optional name, AI model (e.g., Opus, Sonnet), design system, and wait-for-completion behavior. * Iterate on a Design: Send follow-up prompts to an existing project to modify or refine a design. * Generate Variants: Create multiple design variants from one prompt in parallel. * Pull Files: Download a project's generated files to a local directory, with optional ZIP output. * Preview a Design: Render a project's HTML to a full-page PNG screenshot for visual review. * Read a File: Fetch the contents of a specific file within a project. * Check Status: Poll a project's generation state (generating, awaiting_input, done, no_output) and chat turn summary. * Edit a File: Apply direct string edits to a project file without re-prompting the AI. * Delete a Project: Permanently remove a design project (requires confirmation). * Manage Design Systems: Upload local design-system packages to your account and list existing design systems.

How do I use claude.design-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude.design-mcp Create a design for a tech startup landing page" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

claude.design-mcp

by coin-seeker

Overview Schema Related Servers Score Discussions

JavaScript

Local

claude.design-mcp

An MCP that drives the real Claude Design web app from your editor/agent — log in once, then create, iterate on, and pull designs that claude.ai/design generates on your own account (not a local imitation).

How it works

It drives your own logged-in Chrome (a dedicated profile) over CDP with playwright-core, and talks to the real claude.ai/design "Omelette" API as you, through your browser session.
Generation is triggered the way the website does it — your prompt is typed into the design composer and submitted; the tool then waits for the turn to finish (the ReleaseTurn network signal + file-tree stability) and reports the files Claude Design wrote. Files are pulled back to local on request.
Project metadata, files, deletes, and direct file edits use the documented JSON RPCs (CreateProject / ListFiles / GetFile / EditFile / DeleteProject), run in-page so they share your session + Cloudflare clearance.
Not a claude -p mimic. Every design is produced by claude.ai/design itself.

Related MCP server: Browser Agent MCP

Official Design MCP and protocol verdict (2026-08-12)

This project is an independent CDP browser-automation MCP. It does not call the official api.anthropic.com/v1/design/mcp endpoint. As described in How it works, it uses playwright-core and CDP to drive a real Chrome session that is already logged into the actual claude.ai/design web app.

The claude.ai/design UI's Create prompt for Claude Code export message hands off a project URL in the form https://claude.ai/design/p/<projectId>. For this server, the matching flow is to extract <projectId> from that URL and call design_pull. The official Design MCP is not needed to receive the generated files.

The MCP protocol revision discussed around 2026-07-28, including the stateless wire-protocol change adopted by some MCP ecosystems, has no practical effect on the current OpenCode stdio client integration or tool contract. This server responds to initialization with the fixed protocolVersion: "2024-11-05" handshake.

Re-review this verdict if any of these conditions occurs:

The OpenCode MCP client drops support for the older handshake version this server returns.
The project decides to replace its CDP browser-automation approach with the official api.anthropic.com/v1/design/mcp endpoint.
claude.ai changes its authentication or session model in a way that affects the CDP-driven login flow.

Tools

Tool	Does
`design_login`	One-time: open Chrome to log into claude.ai/design (session persists)
`design_list`	List your claude.ai/design projects
`design_create`	Create a project and generate a design from a prompt — `prompt`, `designSystem` XOR `withoutDesignSystem: true` (+ `withoutDesignSystemReason?`), `name?`, `wait?`, `model?`, `fresh?`
`design_variants`	Generate multiple design variants of one prompt in parallel — `prompt`, `designSystem` XOR `withoutDesignSystem: true` (+ `withoutDesignSystemReason?`), `count?`, `axis?`, `name?`, `preview?`, `model?`
`design_iterate`	Send a follow-up prompt to modify a design — `projectId`, `prompt`, `wait?`, `model?`, `designSystem?`
`design_pull`	Download a project's files to local — `projectId` or `name`, `dir?`, `zip?`
`design_preview`	Render a project's self-contained HTML to a full-page PNG for review — `projectId` or `name`, `path?`, `dir?`, `width?`
`design_get`	Read one file from a project — `projectId`, `path`
`design_status`	Report a project's chat/turn state — `projectId`
`design_check`	Poll and recover an asynchronous generation — `projectId`; returns `generating`, `awaiting_input`, `done`, `no_output`, `interrupted`, `stalled`, or `resume_exhausted`
`design_edit`	Apply a direct file edit — `projectId`, `path`, `edits`
`design_delete`	Delete a project — `projectId`, `confirm` (must be `true`; the call is rejected without it)
`design_system_sync`	Upload a materialized design-system package folder to claude.ai as a design system, by running Claude Code `/design-sync` in it — `dir`
`design_system_list`	List the design systems on your account (name + id), across every page of the project list

Every tool also accepts an optional caller object — { directory, sessionID, agent, project? } — that the MCP client may inject to say who is calling. It is never a generation argument: the dispatcher strips it before the handler runs and only records it in the call history.

Call history

Every tools/call dispatch appends exactly one JSON line to ~/.local/share/opencode-dashboard/claude-design-history/events.ndjsonl (dir 0700, file 0600; override the folder with CLAUDE_DESIGN_HISTORY_DIR), so a prompt history survives across MCP restarts. A line carries v, eventId, seq, ts, tool, durationMs, ok, error, projectId, projects, projectName, prompt (verbatim, never truncated), model, designSystem, withoutDesignSystem, withoutDesignSystemReason, wait, attemptId, caller, pullKind, revision, and a whitelisted result summary (counts and ids only — never file contents, base64, or environment values). Recording is best-effort observability: a failed write only warns on stderr and never turns a working tool call into an error. The CLI path is not recorded.

Revision snapshots

A successful plain design_pull (pullKind: "default" — no dir, no zip) also snapshots the pulled manifest into <CLAUDE_DESIGN_DIR>/.revisions/<projectId>/<revisionId>/, outside the pulled tree, so a design's edit history can be diffed later. revisionId is <YYYYMMDDTHHmmssSSS>-<uuid8> in UTC, so name order is time order. Each folder carries a .meta.json with the per-file SHA-256 list, a total hash, and incomplete: true when the pull reported partial file errors. The snapshot is staged in .staging-<revisionId>/ and atomically renamed, so listers only ever see finished revisions (skip any name starting with .). A pull whose content hash and completeness both match the previous revision is skipped and reports revision: null, meaning "unchanged — the previous revision is still current". Snapshot failures are non-fatal in the same way: revision: null plus an stderr warning, tool result untouched.

Setup

npm install                  # installs playwright-core (NO browser download — uses your Chrome)
node src/server.mjs login    # opens Chrome once; log into claude.ai (session is then reused, invisibly)

{ "mcp": { "claude-design": { "type": "local", "command": ["node", "/abs/path/claude.design-mcp/src/server.mjs"], "enabled": true } } }

CLI

node src/server.mjs login
node src/server.mjs list
node src/server.mjs list-systems
node src/server.mjs create "simple pricing card" pricing --design-system "Frontend Design System"
node src/server.mjs create "minimal landing page for a coffee shop" coffee --model opus --without-design-system
node src/server.mjs iterate <projectId> "add a dark mode toggle to the header" --model sonnet
node src/server.mjs check <projectId>
node src/server.mjs pull <projectId|name>
node src/server.mjs preview <projectId|name> [outDir] [width]
node src/server.mjs delete <projectId>
node src/server.mjs sync <packageDir> [--timeout-ms 900000]

After the one-time login, list/create/iterate/pull run with no visible window (off-screen Chrome) and reuse the persisted session.

Generation options

design_create, design_iterate, and design_variants accept an optional model. Use a family (opus, sonnet, haiku, or fable) to select that family's newest version from the live claude.ai/design menu. Pin a version with forms such as opus-4.8, opus-5, opus 5.0, claude-opus-4-8, or anthropic/claude-opus-5. New family versions become available automatically when they appear in the site menu. If a requested version is unavailable, the error lists the live menu options. For CLI create and iterate, pass the same value to --model.
design_create, design_iterate, and design_variants accept a designSystem (CLI --design-system), the name of one of the account design systems reported by design_system_list. It is matched case-insensitively, an unambiguous partial name works, and an unknown name errors with the list the composer offers. The chosen system replaces the org default rather than adding to it, and the result echoes the resolved name. claude.ai only offers the picker while a project has produced no design yet, so designSystem belongs on design_create; on design_iterate it works only for such a project and otherwise errors instead of silently ignoring the request. design_variants grounds every variant in the same system.
Grounding is mandatory on design_create and design_variants. Each call must carry exactly one of a non-blank designSystem or withoutDesignSystem: true (the boolean true, not "true" or 1) — never both, never neither. A violation is refused with one fixed message that names list_claude_synced_systems / design_system_list as the way to discover the available names, and the refusal happens before a browser session, an operation page, or a project exists, so a rejected call leaves the account untouched. On design_variants the check runs above the fan-out, so a refused call creates zero projects instead of returning per-variant errors. An opt-out may carry a free-text withoutDesignSystemReason, which is only valid together with withoutDesignSystem: true; both are echoed in the result and recorded in the call history. The CLI equivalent is create --without-design-system; iterate rejects that flag as unknown. design_iterate is deliberately not gated: a project that already holds a design no longer offers the picker, so there is nothing to choose there.
design_variants forces fresh: true on every project it creates. Each variant is named <base>-v<N>, and without fresh a rerun would reuse the same-named project from an earlier fan-out — a project that already holds a design, where the design system can no longer attach.
design_create and design_iterate accept wait (default true). Set wait: false to return after a verified Chat POST and the bounded question-form watch with { submitted: true, pending: true }; the CLI equivalent is --no-wait. A click or Enter press that does not produce a Chat request fails instead of reporting success.
design_create with an explicit name is find-or-create: an existing project with that exact name is reused (newest wins on collisions) and the result carries reused: true, so repeated calls iterate one project instead of piling up duplicates. Pass fresh: true to force a new project. Without name (prompt-derived name), every call creates a new project as before.
Poll submitted work with design_check({ projectId }), or node src/server.mjs check <projectId>. Its status is generating, awaiting_input, done, no_output, interrupted, stalled, or resume_exhausted. Each check reuses the held owner page while a turn is active (without reloading it), answers a question form when possible, and automatically clicks the interrupted banner's Resume button. interrupted means the banner was present but could not be resumed; stalled means the file tree was stable with no generated files and the last message was still the user's prompt. resume_exhausted is terminal after three consecutive Resume attempts and includes resumeAttempts, maxResumeAttempts, and problem: "resume_attempts_exhausted". _ds/** design-system material is not counted as generated output.

Asynchronous workflow

# 1. Submit without waiting
node src/server.mjs create "카드 UI" my-card --no-wait --model opus
# → { projectId: "...", submitted: true, pending: true }

# 2. Continue with other work...

# 3. Poll for completion (every 2-5 minutes is recommended)
node src/server.mjs check <projectId>
# → { status: "done", files: [...] }

# 4. Pull and preview the finished design
node src/server.mjs pull <projectId>
node src/server.mjs preview <projectId>

Requirements

Node.js 22+ (uses built-in fetch/WebSocket; playwright-core is the only npm dependency)
Google Chrome (the tools drive a dedicated Chrome profile)
A claude.ai account with Design access (you log in once via design_login)

Env

CLAUDE_DESIGN_PROFILE — dedicated Chrome profile dir (default ~/.cache/claude-design-mcp/chrome-profile)
CLAUDE_DESIGN_CHROME — path to Google Chrome (default: macOS Google Chrome)
CLAUDE_DESIGN_CDP_PORT — remote-debugging port (default 9377)
CLAUDE_DESIGN_DIR — where design_pull / design_preview write, each into its own <project>/ folder (default: the working folder); an explicit dir argument is used verbatim
CLAUDE_DESIGN_HISTORY_DIR — where the tools/call history is appended (default ~/.local/share/opencode-dashboard/claude-design-history, file events.ndjsonl)
CLAUDE_DESIGN_HEADLESS — set 1 to drive headless Chrome instead of off-screen
CLAUDE_DESIGN_TURN_TIMEOUT_MS — hard cap per generation turn (create ~360s, iterate ~240s defaults)
CLAUDE_DESIGN_QUIET_MS — how long the turn network must stay silent before a generation is judged complete (default 20000)
CLAUDE_DESIGN_PAGE_LEASE_MS — independent hard cap for an async owner page if its completion monitor hangs (default 2700000, 45 minutes)
CLAUDE_DESIGN_CLAUDE_BIN — Claude Code binary used by design_system_sync (default claude)
CLAUDE_DESIGN_SYNC_TIMEOUT_MS — hard cap for one /design-sync run (default 900000, 15 minutes)

Design-system sync

design_system_sync (CLI: sync <dir>) runs claude -p "/design-sync <pre-approval>" --dangerously-skip-permissions --output-format stream-json --verbose with the package folder as its working directory and reports what the sync uploaded. After a successful tokens-only sync, it uses the logged-in Chrome/CDP session to replace the uploaded styles.css import shim with the generated custom-property CSS from ds-bundle/_ds_bundle.css.

The folder must already be a package (package.json + a CSS entry such as styles.css, plus tokens/*.json, guidelines/*.md, README.md). Components are optional — a tokens-only package is accepted. The tool refuses before spawning if package.json is missing.
Exit status is not the success signal. A refused sync still exits 0 with subtype: "success", so the result is only ok: true when the reply carries a real project link; otherwise you get { ok: false, error, raw } with the full output for diagnosis.
A first run creates the project and writes .design-sync/config.json, which pins later runs to the same project (an unchanged re-run is then a no-op instead of a duplicate). If your pipeline regenerates the folder, snapshot .design-sync/ before replacing it and restore it afterwards — this tool never writes the package itself.
The prompt carries a pre-approval (SYNC_ARGS in src/sync.mjs), and it is load-bearing on a first run. /design-sync asks for two AskUserQuestion confirmations when the folder has no pin — accept the time/cost, then confirm the new project's name before create_project — and claude -p has no AskUserQuestion tool, so the turn would end with the question and upload nothing (exit 0, subtype: "success", no project link). The skill's own escape hatch ("if their request already acknowledged the time/cost… continue without re-asking") is what the pre-approval invokes, and it names the fresh-project creation explicitly. A pinned re-sync never hits either gate, which is why this only ever surfaced on a first-time sync. Claude Code appends the text after the slash command to the skill body as a fenced ## Hint block, so it must stay one positional string with no triple backtick in it.
A first sync takes ~10 minutes; unchanged re-runs take ~2. The CLI exits 1 on a failed sync.
The result adds flattened: true|false. A post-sync browser/write failure is reported as flattenError while the completed upload remains ok: true.

design_system_list (CLI: list-systems) is the read side of the same feature. claude.ai has no separate design-systems endpoint — design systems are returned by the ordinary project list RPC tagged PROJECT_TYPE_DESIGN_SYSTEM, which pages 20 at a time, so the tool follows every page and returns [{ name, id, publishedAt?, viewedAt? }] (publishedAt appears only once a system has been published). Use it to confirm what design_system_sync actually landed on the account. scripts/probe-design-systems.mjs re-captures that live shape if the API changes.

When is a generation "done"?

claude.ai/design drives generation as turns: your prompt streams in over a Chat RPC, kept alive by RenewTurn keepalives (~every 10s) and ended by a ReleaseTurn. design_create / design_iterate return once the files have settled AND the turn network has gone quiet for CLAUDE_DESIGN_QUIET_MS — comfortably longer than the keepalive interval, so a generation is never cut off mid-write (you always get a complete, coherent design, not a half-rendered one).

If a generation reaches its hard deadline before the quiet/stability checks complete, the result includes timedOut: true. Normal completions omit the field entirely; treat its presence as a signal that the returned files are the best available snapshot at the timeout rather than a fully quiet turn.

Note that claude.ai often runs an automatic refine pass that starts ~30s after the first design settles, so the design keeps improving on the server after the tool has returned its first complete version. To get the most-refined output, design_pull / design_preview always fetch the latest state, or raise CLAUDE_DESIGN_QUIET_MS (e.g. 60000) to make create wait through later refine passes (at the cost of a longer wait).

Available Tools

10 tools

design_createC

Create a Claude Design project and submit the initial prompt through the composer.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`prompt`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so the description must disclose behavior. It mentions creating a project and submitting a prompt but does not clarify side effects, permissions, rate limits, whether the operation is synchronous, or what the response contains. This is inadequate for a creation tool.

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 sentence, which is concise but lacks necessary detail. It front-loads the purpose but fails to provide adequate information for the agent to use the tool correctly. Ideally, it should include more context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, error conditions, or the nature of the 'composer' reference. An agent would likely need to infer or guess many details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description only implicitly covers the 'prompt' parameter. The 'name' parameter is not explained at all. The description adds no meaningful semantics beyond the parameter names in the schema.

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 action 'Create a Claude Design project' and distinguishes from siblings like design_edit, design_delete. It specifies submitting the initial prompt, making the purpose specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like design_edit or design_iterate. There is no mention of prerequisites or context for usage.

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

design_deleteC

Delete one Claude Design project.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

The word 'Delete' implies a destructive action, but the description does not disclose any behavioral traits such as irreversibility, permissions needed, side effects, or confirmation steps. With no annotations provided, the description fails to add transparency beyond the action itself.

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 short sentence, making it concise. However, it is under-specified given the lack of details in other dimensions; brevity here comes at the cost of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple deletion tool with one parameter and no output schema or annotations, the description is incomplete. It does not explain the effect on the project, any prerequisites, or what happens after deletion. Critical context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'projectId' parameter beyond its name and type. There is no indication of what values are valid or how to obtain the ID. The description adds no meaning beyond the schema.

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 verb 'Delete' and resource 'Claude Design project', which is specific and distinguishes from sibling tools that perform other actions like create, edit, get, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives. Among 9 siblings, there is no context on prerequisites, when deletion is appropriate, or when other tools like design_edit or design_status might be relevant.

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

design_editC

Apply direct string edits to one Claude Design project file.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`edits`	Yes
`projectId`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states that edits are applied, but fails to mention whether edits are atomic, what happens on failure, permissions required, or any side effects (e.g., overwriting existing content). The description is insufficient for understanding the tool's behavior.

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 a single concise sentence with no superfluous information. It is front-loaded with the core action. However, it is overly terse at the expense of necessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, output schema, and parameter descriptions, the description is inadequate for a mutation tool. It does not provide enough context to use the tool correctly, especially regarding the format of edits and expected behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 3 parameters (path, edits, projectId) with 0% description coverage. The description does not explain what each parameter represents or the expected format (e.g., what constitutes a valid 'edits' array). The phrase 'direct string edits' gives a vague hint but is insufficient for correct invocation.

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 clearly states the action ('apply direct string edits') and the target resource ('one Claude Design project file'). It distinguishes from sibling tools by specifying a direct edit operation, which contrasts with create, delete, get, list, and other operations. However, the term 'string edits' is somewhat ambiguous and could be more specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like design_create (for creating files) or design_get (for reading). There are no criteria for when edits are appropriate or any mention of prerequisites or constraints.

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

design_getC

Read one file from a Claude Design project.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`projectId`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic operation. It does not mention error behavior, access requirements, or other side effects.

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 a single sentence with no wasted words. However, it is too concise for a tool with no other documentation, sacrificing necessary detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the large sibling set, no output schema, and lack of parameter documentation, the description is insufficient. It leaves ambiguity about file types, project structure, and return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not add any parameter-level detail. While 'path' and 'projectId' are somewhat self-explanatory, the description fails to provide format, constraints, or relationship context.

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 action (read), the resource (one file), and the context (from a Claude Design project). It effectively distinguishes the tool from siblings like design_list or design_create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any context on prerequisites or when not to use it. The description is purely functional.

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

design_iterateC

Submit a follow-up prompt to an existing Claude Design project.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes
`projectId`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behaviors. It only says 'submit a follow-up prompt' but does not mention whether the tool modifies project state, requires authentication, or what the response contains (e.g., model reply).

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

Conciseness2/5

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

The description is a single sentence, which is concise but severely under-specified. It lacks critical details about parameters, preconditions, and effects, making it too minimal to be effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 2 required parameters, no output schema, and no annotations, the description should provide comprehensive context. It fails to explain expected input format, project lifecycle, or outcome of the submission, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description adds no meaning to parameters. Neither 'projectId' nor 'prompt' are explained beyond their types, leaving the agent without guidance on valid values or formats.

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 clearly states the verb 'submit' and the resource 'follow-up prompt to an existing Claude Design project'. It distinguishes from sibling tools like design_create (create new) and design_edit (modify project settings) by emphasizing the iterative 'follow-up' nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as design_edit or design_create. It does not clarify prerequisites like the need for an existing project or that the project must have an active conversation.

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

design_listA

List Claude Design projects from the logged-in web account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Mentions 'logged-in web account' implying authentication, but no details on read-only nature, pagination, or output format. Adequate but minimal.

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 sentence, clear and front-loaded. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no output schema and no annotations, description is minimal. Lacks details on what 'projects' includes (e.g., names, IDs) and no mention of read-only nature. Acceptable but could be improved.

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?

No parameters exist and schema coverage is 100%, so baseline is 3. Description adds no parameter info, but none needed.

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?

Description states 'List Claude Design projects from the logged-in web account.' Clear verb 'list' and resource 'Claude Design projects', distinguishing from siblings like design_get (single project) and design_create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like design_get or search. Does not mention when to avoid or prerequisites, though simple tool makes it obvious.

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

design_loginA

Open Chrome for claude.ai/design login and report the active account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

The description discloses that it opens a browser (Chrome) and reports an account, which is a significant behavioral trait not captured in any structured fields. However, it omits details like whether this requires a desktop environment, side effects on existing sessions, or what happens if Chrome is not installed. With no annotations, the description partially fills the transparency gap.

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?

A single sentence that is front-loaded with the primary action ('Open Chrome...') and completes with the secondary action ('report...'). Every word is necessary and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no output schema, the description communicates the core function but lacks details on the format of the reported account (e.g., string, JSON), potential user interaction required, or failure modes. It is minimally complete but could be more informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the input schema is trivially covered (100%). The description does not need to add parameter details. Per guidelines, 0 parameters baseline is 4, and the description meets that without superfluous information.

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 opens Chrome for a specific login page (claude.ai/design) and reports the active account. It uses strong verbs 'Open' and 'report', and the resource is explicitly a login operation, which distinctly separates it from sibling tools focused on design CRUD.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like design_get or design_list. There is no mention of prerequisites, ordering (e.g., must be called before design operations), or when not to use it.

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

design_previewC

Render a project's self-contained HTML to a full-page PNG screenshot for visual review.

ParametersJSON Schema

Name	Required	Description	Default
`dir`	No
`name`	No
`path`	No
`width`	No
`height`	No
`projectId`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It indicates a read-only operation but does not mention that it is non-destructive, any authentication requirements, or whether it modifies state. The term 'self-contained HTML' is not explained.

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 a single, clear sentence with no verbosity. However, it could be slightly more structured with additional context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 6 optional parameters, no output schema, and no behavioral details, the description is severely incomplete. It does not explain how parameters like width, height, or projectId affect the output, nor what a 'full-page PNG screenshot' entails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 6 parameters with 0% coverage (no descriptions). The description does not mention any parameters or their purpose, failing to add value beyond the schema.

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's function: rendering HTML to a PNG screenshot for visual review. It uses a specific verb ('Render') and resource ('project's self-contained HTML'), distinguishing it from sibling tools that perform CRUD operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as design_get or design_list. There is no mention of prerequisites, context, or when not to use it.

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

design_pullC

Pull one Claude Design project by projectId or exact name into a local directory.

ParametersJSON Schema

Name	Required	Description	Default
`dir`	No
`zip`	No
`name`	No
`projectId`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses the action but not behavioral traits such as whether the operation is destructive, if it overwrites local files, authentication requirements, or error handling. Without this, an agent cannot predict side effects.

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 a single sentence with no fluff, clearly stating the core functionality. It could be slightly more structured, but it is efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (none required), no output schema, and no annotations, the description is insufficient. It should include details on default behavior, output format, error conditions, and parameter interactions to enable proper invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains projectId and name as identifiers, but does not describe the 'dir' parameter (output directory) or 'zip' parameter (whether to create a zip file). This leaves agent uncertain about required or optional parameters.

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 clearly states the action ('Pull') and the resource ('Claude Design project'), and specifies two methods for identifying the project (projectId or exact name). However, it does not differentiate from sibling tools like design_get, which might also retrieve project data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., design_get, design_list). The description does not mention prerequisites, context, or cases where other tools would be more appropriate.

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

design_statusC

Summarize project data, chat count, and last message role.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. Only states 'summarize' without disclosing read-only nature, authentication needs, or output format. Does not indicate whether the tool has side effects.

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?

Single sentence is highly concise with no extraneous words. However, it may be overly brief; a bit more structure could improve clarity without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of summarizing project data, chat counts, and last message roles, and the lack of output schema or additional annotations, the description leaves significant gaps in understanding what is returned and how to interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single parameter projectId. The description mentions 'project data' but does not explain what projectId represents or how it should be used. Fails to add meaning beyond the schema.

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 uses a specific verb 'Summarize' and identifies distinct resource aspects: 'project data, chat count, and last message role'. It clearly distinguishes from sibling tools like design_get (which likely returns full design details) or design_list (which lists multiple designs).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as design_get or design_list. Lacks context for appropriate usage scenarios, prerequisites, or exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a unique action (create, delete, edit, get, iterate, list, login, preview, pull, status) targeting distinct operations on projects or files, with no overlap in purpose.

Naming Consistency5/5

All tools follow a uniform 'design_<verb>' pattern, using snake_case throughout, making naming predictable and easy to understand.

Tool Count5/5

10 tools is well-scoped for a design-related server, covering essential operations from login to CRUD to preview and status without being excessive or insufficient.

Completeness4/5

The tool set covers core workflows (login, list, create, read, update, delete, preview, pull), but lacks explicit support for file deletion or project metadata updates, which are minor gaps.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

pepita
dev.pepita.mcp
Read, edit, publish, and preview your pepita websites from Claude.
Content Management Systems Developer Tools
1
browserbasehq-mcp-browserbaseOAuth
ai.smithery
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser Automation Web Scraping Agent Orchestration
23,406
validatethat-mcp
io.github.RyanByrne
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Research & Data Product Management
2
LandingConnect
com.landingconnect
Build, clone & publish websites by chatting with Claude. Live in seconds, custom domains + SSL.
Web Scraping Content Management Systems Cloud Platforms
1

Related MCP Servers

MCP Browser Automation Server
Browser Automation App Automation Developer Tools
hrmeetsingh
A
license
B
quality
D
maintenance
Enables automation of browser tasks using Playwright by interacting via Claude Desktop for executing user-defined prompts and operations.
Updated 2 years ago (2024-12-31 21:42 UTC)
12
12
MIT
Browser Agent MCP
Agent Orchestration Browser Automation Web Scraping
imprvhub
A
license
A
quality
B
maintenance
A Model Context Protocol (MCP) integration that provides Claude Desktop with autonomous browser automation capabilities. This agent enables Claude to interact with web content, manipulate DOM elements, execute JavaScript, and perform API requests.
Updated 7 months ago (2026-02-05 01:49 UTC)
13
4
41
TypeScript
Mozilla Public 2.0
gotham-browser
Browser Automation Web Scraping
gotham-os
F
license
Not graded
quality
B
maintenance
Enables Claude Code to control a real browser using AI for web scraping, competitive intelligence, and UX auditing through the MCP protocol.
Updated 2 months ago (2026-06-24 15:20 UTC)
Browser AI MCP Server
Browser Automation Web Scraping
qckfx
A
license
Not graded
quality
C
maintenance
Enables natural language browser automation through Claude, wrapping Playwright to execute commands like navigation, clicking, form filling, and screenshots.
Updated a year ago (2025-07-24 22:15 UTC)
11
30
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/coin-seeker/claude.design-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server