Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude-design import the design from my clipboard"
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.
A local MCP server named claude_design that bridges Claude Design projects into existing Claude Desktop (Cowork) sessions.
Claude Design has a "Share to Claude Code" button. It copies a snippet to your clipboard:
Make sure the claude_design MCP connector (https://api.anthropic.com/v1/design/mcp) is connected...
Then use the claude_design MCP tools to import this project: https://claude.ai/design/p/<uuid>?file=...
Implement: <filename>Pasting that into Claude Desktop should work — but it doesn't, for three reasons:
The real claude_design MCP uses OAuth through claude.ai, which is behind Cloudflare bot protection. mcp-remote (the standard bridge) hits a Cloudflare JS challenge instead of the OAuth metadata JSON and fails immediately.
The only workaround was downloading a ZIP and uploading it as a file — but that opens a new session, losing all conversation context. And the ZIP doesn't include the design chat history anyway (requirements, iterations, decisions), which is often the most valuable part.
Claude Cowork had no way to receive a design at all. The "Send to Claude Code" file-transfer path creates a new session by design. There was no sharing path for existing Cowork sessions.
Related MCP server: Noor MCP Code Assistant
This server registers itself as claude_design in Claude Desktop. When you paste the "Share to Claude Code" snippet, Claude Desktop calls this server's tools instead of trying the broken OAuth flow.
The server:
Reads the designOauth access token written by /design-login from the macOS Keychain (Claude Code-credentials entry) — no hardcoded secrets
Calls https://api.anthropic.com/v1/design/ directly with that token
Decodes the base64-encoded project data field to extract the full chat history (requirements, iterations, back-and-forth) — the ZIP bundle omits this entirely
Fetches all code files (HTML, JS, JSX, CSS, SVG) and lists binary assets by name
Exposes a download_bundle tool that saves the full ZIP (code + images + screenshots + uploads) to ~/Downloads
The result: paste the snippet into any existing Claude Desktop session, Claude sees the design files and the conversation that produced them, and implements in-context.
git clone https://github.com/kuatecno/mcp-design.git ~/mcp-design
cd ~/mcp-design
npm installIn Claude Code CLI (terminal):
/design-loginThis writes a designOauth token into your macOS Keychain. The MCP reads it from there at runtime — no config file needed.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"claude-design": {
"command": "/path/to/node",
"args": [
"/Users/you/mcp-design/node_modules/.bin/tsx",
"/Users/you/mcp-design/src/index.ts"
]
}
}
}Use the absolute path to node from your Node version manager (e.g. ~/.nvm/versions/node/vX.Y.Z/bin/node). Claude Desktop runs with a restricted PATH so bare node won't resolve.
Restart Claude Desktop.
Click "Share to Claude Code" in Claude Design, paste the clipboard text into any Claude Desktop session. Done.
Tool | Description |
| Fetches all code files + chat history for a project. Main entry point for the "Share to Claude Code" flow. |
| Returns the full design conversation: requirements, iterations, decisions. |
| Reads one file with optional chunked paging for large files. |
| Lists all files in a project with sizes and content types. |
| Returns project metadata. |
| Lists all your Claude Design projects. |
| Downloads the full ZIP bundle (code + images + uploads) to |
The designOauth token is written by /design-login and expires after ~8 hours. When it expires, run /design-login again in Claude Code CLI — it refreshes the Keychain entry and the MCP picks it up automatically on the next call (no restart needed).
macOS (Keychain is macOS-only)
Claude Code CLI installed and logged in
Node.js 18+
Claude Desktop (for the Cowork session use case)
Download a Claude Design project as a ZIP bundle to a local directory. Includes all files: code (HTML/JS/JSX), images, screenshots, and uploads. The ZIP also works without chat history — use get_chats for that separately.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project UUID or full claude.ai design URL. | |
| dest | No | Local directory to save the ZIP into (default: ~/Downloads). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action and contents, but fails to disclose behavior such as whether it overwrites existing files, requires authentication, has size limits, or what the return value is. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the main action, and includes a useful sibling pointer. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a side effect (saving a file) and no output schema, the description should at least mention the result or confirmation. It does not address return value, error conditions, or expected behavior after download. However, the purpose and contents are well covered, so it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds the context 'ZIP bundle' and 'local directory', but does not significantly extend understanding beyond the schema. The value added is marginal, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download a Claude Design project as a ZIP bundle') and specifies the contents ('code, images, screenshots, uploads'). It also distinguishes itself from the sibling tool get_chats by stating that the ZIP does not include chat history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to download a project bundle) and explicitly recommends using get_chats for chat history separately. However, it does not contrast with other siblings like list_files or get_file, leaving some ambiguity about granularity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full chat/conversation history from a Claude Design project. This is the design conversation context — requirements, iterations, decisions — fundamental for understanding what to implement.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project UUID or full claude.ai design URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning full chat history but omits details on pagination, read-only nature, permissions, or any side effects. For a read tool, basic transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. First sentence captures core action; second adds useful context. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete. It explains the return value and its importance. However, it could mention if there are limits on history length or data format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so description adds minimal value beyond the schema. It confirms the parameter expects a project identifier but does not elaborate on format or constraints not already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'full chat/conversation history' from a Claude Design project. It unambiguously distinguishes from sibling tools like get_project, list_files, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it is 'fundamental for understanding what to implement', but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw content of a file in a Claude Design project. Use offset and limit to read large files in chunks (default chunk: 20000 chars). Reports total size so you know if more remains.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project UUID or full claude.ai design URL. | |
| path | No | File path within the project, e.g. 'Kua - Landing.html'. If omitted and a ?file= param is in the project URL, that file is used. | |
| offset | No | Character offset to start reading from (default 0). | |
| limit | No | Max characters to return (default 20000, max 40000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses chunking behavior (offset, limit), default chunk size, max limit, and that total size is reported. Does not explicitly state read-only nature but it's implied. Adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second explains chunking. No filler, front-loaded, every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description mentions that total size is reported, helping the agent understand response contents. Could specify format or error handling, but adequate for a simple file retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all 4 parameters (100% coverage). Description adds value by explaining the chunking purpose and defaults for offset and limit, which is not obvious from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states that the tool gets raw file content from a Claude Design project. The verb 'get' and resource 'raw content of a file' are specific. Distinguishes from siblings like list_files and download_bundle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific guidance on using offset and limit for large file chunking, including default and maximum values. Lacks explicit comparison to alternative tools but the usage hints are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a Claude Design project. Accepts a project UUID or a full claude.ai/design/p/ URL.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project UUID or full claude.ai design URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It only states 'get metadata' without discussing safety (read-only nature implicitly but not explicitly), authentication needs, or what the response contains. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant or missing words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and no output schema, the description covers the purpose and input format adequately. However, it omits what 'metadata' includes, leaving some incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description already covering UUID/URL input. The tool description repeats this information, adding no new semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'metadata for a Claude Design project', which is distinct from siblings like 'download_bundle' or 'get_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies acceptable input formats (UUID or full URL) but does not explicitly state when to use this tool over alternatives like 'list_projects'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a Claude Design project: reads project metadata, lists all files, and returns the content of each HTML/JS/JSX file so it can be implemented. Pass the full claude.ai/design/p/?file= URL from the 'Share to Claude Code' clipboard text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full claude.ai design project URL (from 'Share to Claude Code' clipboard). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool reads metadata, lists files, and returns content of specific file types. This adds context beyond the schema. No annotations are provided, so the description carries the full burden. It does not mention side effects (likely read-only) or error handling, but the main behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first explains the tool's action, second provides precise usage instruction. No extraneous words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the main behavior and input format. It does not specify return format or error handling, but the context is sufficient for basic usage. Sibling tools exist but are not contrasted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'url' parameter. The description adds specific context on what URL to pass (full claude.ai design URL from clipboard), going beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a Claude Design project by reading metadata, listing files, and returning content of HTML/JS/JSX files. It distinguishes from siblings that handle individual operations (get_file, list_files, get_project).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use it: with a full URL from 'Share to Claude Code' clipboard. It clearly explains the input format. However, it does not explicitly mention when not to use it or compare to sibling tools like download_bundle or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files in a Claude Design project.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project UUID or full claude.ai design URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits like read-only nature, pagination, or whether file contents or metadata are returned. The minimal description leaves the agent uncertain about side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's action. It is front-loaded and efficient, though slightly under-informative for a complete specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and no details about return values, the description is incomplete. It does not specify what 'files' refers to (metadata, contents, IDs), leaving the agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'project' parameter with 100% coverage (a string for UUID or URL). The description adds no further semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all files in a Claude Design project', making the purpose understandable. However, it does not distinguish from sibling tools like 'get_file' which might retrieve a single file, but the name itself provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_file' or 'list_projects'. The description does not mention exclusions or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Claude Design projects the user owns or can edit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it's a read operation (list), but omits details on pagination, ordering, error handling, or whether results are filtered by ownership/edit rights beyond the statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information, front-loaded with the essential action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It lacks information about return format, pagination, or limits. For a simple list tool, it is adequate but not comprehensive enough to fully inform agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivially. Baseline for 0 parameters is 4. Description adds no additional semantic value beyond the schema, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it lists all projects the user owns or can edit, using verb 'list' and resource 'projects'. Clearly distinguishes from sibling tools like get_project (single project) and list_files (files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing a list of accessible projects, but provides no guidance on when to choose this over alternatives like get_project or download_bundle. No explicit when-not-to-use or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0download_bundleget_chatsget_fileget_projectimport_projectlist_fileslist_projectsScored across 7 tools
Each tool has a distinct purpose: downloading bundles, retrieving chat history, reading files, getting project metadata, importing projects, listing files, and listing projects. However, 'import_project' partially overlaps with 'get_project', 'list_files', and 'get_file', which could cause slight confusion.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., download_bundle, get_chats, list_projects). No deviations or mixed conventions.
With 7 tools, the set is well-scoped for managing Claude Design projects. Each tool earns its place without being too few or too many.
The tool set covers reading, listing, and exporting operations comprehensively. However, it lacks tools for creating, updating, or deleting projects or files, which may be needed for full lifecycle management.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.