Click on "Install 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-mcp Design a landing page and pull the files into the repo"
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.
Talk to Claude Design from Claude Code. Send it design instructions, read what it says back, pull the files it makes into your repo, and put the right screen on your display so you can watch it work.
Claude Design is a separate product from Claude Code. It has its own projects, its own chats, and its own files, and no API. So the two never met.
This is the bridge. Claude Code can now ask the designer for a screen, watch it being drawn, read the reasoning, and pull the result straight into the codebase.
you → Claude Code → claude.ai/design → a design
← its reply, its files ←/plugin marketplace add marvin-socialista/claude-design-mcp
/plugin install claude-design@claude-designThen once, in the installed plugin directory:
npm install # Playwright and the MCP SDK
npm run seed # copy your claude.ai session into the tool's browser profile
npm run smoke # read-only check, spends nothingnpm install is not optional and not automatic: this drives a real browser, so
Playwright has to be there.
seed copies only claude.ai cookies out of a Chrome profile you already use
(~/.claude/playwright-profile by default, or pass another path). Nothing else
from that profile is read or duplicated. If it is not signed in, or the session
later expires, npm run login opens a window so you can sign in by hand.
git clone https://github.com/marvin-socialista/claude-design-mcp
cd claude-design-mcp && npm install && npm run seed
claude mcp add claude-design --scope user -- node "$PWD/src/index.mjs"Related MCP server: Herald
Start something
Tool | What it does |
| The home-screen tiles: Blank, Mobile app design, Slides, Wireframe, Diagram and 9 more |
| The "What should we create?" box: a prompt, an optional template, and it starts building |
| An empty design-system project. Type is fixed at creation, so it cannot be converted later |
| Attach design systems to a project so its chats design against them |
| Attach a local folder as the project's codebase, so it designs against your real code |
| Point a project at a connected GitHub repository |
| Push a Figma |
Talk to it
Tool | What it does |
| Every project, with its |
| Chat threads in a project, marking the active one |
| Make a different thread active, since |
| Send an instruction, wait for the answer, return the reply and what changed. Takes local |
| Tail of a transcript. How you read what Claude Design said |
See and read what it built
Tool | What it does |
| The rendered page as an image, so Claude can actually judge the design |
| Put the window on your display, on a given project, chat and page |
| Grep the project's files, with line numbers and context |
| Read a file, or a line range of one, without downloading it |
| Recursive file listing |
Move work around
Tool | What it does |
| Download files to a local directory, binaries included |
| Push files up, e.g. components into a design system |
| Shut the background Chrome and flush its profile |
Delete (permanent, no trash, no undo)
Tool | What it does |
| Delete a project or design system. Requires |
| Delete files from a project, verifying they are gone |
| Delete one chat thread and its transcript |
delete_project is guarded the way GitHub guards repo deletion. A UUID is easy
for an agent to carry over from the wrong step; a name has to be looked up and
matched deliberately. Verified: it refuses "Bridge test DS" when the project
is actually called "Bridge test DS (safe to delete)".
The plugin also ships a claude-design skill that teaches Claude when and how
to reach for these, so you can just say what you want.
"Link local code" has no file input. Its browse… calls
window.showDirectoryPicker(), a native OS dialog that no automation can drive,
which normally ends the story.
So the picker is replaced. link_local_code reads the folder in Node, then
injects a synthetic FileSystemDirectoryHandle implementing the parts the app
uses (values, entries, getFileHandle, getDirectoryHandle,
queryPermission) and overrides showDirectoryPicker to return it. The handle
is given the real prototype via Object.setPrototypeOf, so an instanceof
check still passes while our own methods shadow the native ones, which would
throw on a foreign object.
Verified end to end: after attaching src/, Claude Design listed all five
files and quoted the first line of session.mjs correctly.
Text files only, skipping .git, node_modules and build output, bounded by
file count and total bytes. Point it at a frontend or design-system folder
rather than a monorepo.
The handle is synthetic and lives in the page. A real one is persisted and re-permissioned across sessions; this one is not, so re-attach if a later session needs the files again.
screenshot returns the rendered page as an image, so Claude Code can judge
layout, spacing, type and colour instead of trusting the reply text. Use
width: 402 for an iPhone-class frame, format: "png" to read fine type, and
fullPage: true with savePath for a long document.
search_code plus read_file covers the other half: read the markup Claude
Design actually wrote, without pulling anything to disk. A .dc.html page runs
to hundreds of KB, so grep first, then read the region.
The browser sits parked offscreen while data is read, so nothing interrupts you.
open_screen moves it onto the display over CDP rather than relaunching, and
send_prompt defaults to visible: true.
Open the screen the work is about before sending the prompt, so you watch it
change instead of being shown the result afterwards. Page names in the switcher
drop the extension: ask for Prototype.dc.html and it matches the page listed
as "Prototype".
There is no public API. What follows was worked out by reading the app's own network traffic and shipped bundle.
claude.ai/design speaks a Connect-RPC service,
anthropic.omelette.api.v1alpha.OmeletteService. Plain cookie auth, no extra
headers. The useful methods:
Method | Shape |
|
|
|
|
|
|
|
|
| server-streaming, the generation endpoint |
Reads go over the RPC. Sending a prompt goes through the real page. That split is the whole design, and it is not laziness.
Chat does not take a prompt string. It takes messagesRequest, a bytes field
holding the entire model request the client assembles, and it streams
tool_delta / tool_block_complete events back. The browser executes those
tools. The bundle contains the client-side executor (case 'local_read': …)
for roughly twenty of them: reading and writing project files, grep, screenshots,
check_design_system, generate_image, the Figma bridge. The agent loop lives
in the page.
Calling Chat directly would therefore mean reimplementing Claude Design's
harness: its system prompt, every tool schema, every tool implementation, and
the turn lifecycle (CancelChat, ReleaseTurn, the park-and-wake path). That is
cloning the app. Driving the page instead gets all of it for free, and costs one
Chrome process.
Two signals, both required.
Network quiet is tracked with a PerformanceObserver on resource timings, which
is how the app itself watches its own stream: entries are reported on
completion, so a new …/Chat entry means a stream just ended. One user turn is
several streams (model asks for a tool, browser runs it, next stream carries the
result), so quiet means "no stream has ended for idleSeconds".
Quiet alone is a trap, though. A long tool call is silent, so a turn in
flight can look finished. The decisive signal is an assistant message with
content actually landing in the transcript. Only when both hold does
send_prompt return.
No fetch patching anywhere, so nothing here can break the page.
Chrome runs headed but parked offscreen at -2400,-2400. This is not
cosmetic: Cloudflare serves headless Chrome a 403 challenge on claude.ai even
with a valid session and stealth evasions loaded. Verified both ways, headless
403 and headed 200.
Env var | Effect |
| Start with the window on screen |
| Force headless. Expect Cloudflare to block it |
| Browser profile name (default |
| Reuse an existing Chrome profile directory instead. One Chrome per directory, so that browser must be closed first |
This rides an internal, undocumented API. It can change without notice and there is no support if it does.
It spends your normal Claude credits and is subject to the usual rate limits.
Do not close the browser mid-turn. The browser is the agent's tool executor, so killing it aborts the work in progress and no reply is saved.
send_prompt posts into the project's active chat. Pass chatId to aim
it, which clicks through the chat-history popover, since no URL selects a chat
(?chat=, /c/<id> and /chat/<id> all load the project and leave the
previous thread selected). Creating a new chat is not automated.
File entries carry no version or mtime, so send_prompt reports files
added and removed accurately but cannot see an in-place edit. The reply
text is what tells you those.
The page switcher lists pages, not every file. Use pull_files for the rest.
HTML comes back with Claude Design's own preview runtime bolted to the front,
a data-omelette-injected style and script pair worth about 15 KB.
read_file strips it; pass raw: true to keep it.
WriteFiles takes mutations with a write oneof, and its data is a plain
string, not proto bytes. Both mistakes fail silently, returning 200 while
storing an empty file or the literal base64. write_files therefore reads
back what it wrote and raises if nothing landed.
If this saved you time, you can buy me a coffee ☕.
MIT
Point a project at one of the connected GitHub repositories, so new designs start from the product that already exists. Requires GitHub to be connected on the account already; this will not perform an OAuth grant.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name or fragment, e.g. claude-design-mcp | |
| visible | No | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context by stating that no OAuth grant will be performed and that a prior GitHub connection is required. However, it does not describe side effects like overwriting an existing repository link or what happens if the project already has a repo associated.
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 and front-loaded with the core action. Every sentence earns its place: the first states the purpose, the second adds a critical prerequisite and an exclusion. No wasted words.
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?
The description provides the essential purpose and a key prerequisite, but it omits details about the 'visible' parameter and potential behavior on repeated calls. Since there is no output schema and no annotations, more context would be needed for a fully self-sufficient description.
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 description coverage is only 33% (only 'repo' is described). The description does not explain the 'projectId' or 'visible' parameters, nor does it add meaning beyond the schema's existing example. Given the low coverage, the description fails to compensate for the undocumented parameters.
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 uses a specific verb ('Point') and resource ('project', 'connected GitHub repositories'), clearly stating the tool's function: associating a project with an existing GitHub repo. It also distinguishes itself from sibling tools like link_local_code by specifying GitHub repositories as the target.
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 a clear prerequisite: GitHub must already be connected on the account. It also explicitly states what the tool will not do ('will not perform an OAuth grant'), giving useful context. However, it does not mention alternative tools or explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shut the background Chrome down and flush its profile. Call this when you are done for a while.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool shuts down Chrome and flushes its profile, implying data removal, but does not explain consequences (e.g., clears cookies/history, potential irreversibility) or whether it affects unsaved work. This is a moderate level of transparency for a destructive-ish operation.
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 short sentences with no filler. The action is stated first, followed by a clear usage directive. It earns its place entirely.
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 zero-parameter tool with no output schema, the description covers what it does and when to invoke it. The phrase 'flush its profile' is slightly vague but overall adequately complete for its complexity.
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 tool has zero parameters, so the input schema is trivial. Per rubric, a no-parameter tool gets a baseline of 4; the description does not need to add parameter-level detail. There is no gap here.
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 'Shut the background Chrome down and flush its profile' uses a specific verb ('shut down') and resource ('background Chrome', 'profile'), clearly distinguishing it from sibling tools like list_chats or send_prompt, which are unrelated. It is immediately obvious what the tool does.
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 instruction 'Call this when you are done for a while' provides explicit usage context. It does not mention exclusions or alternatives, but no sibling tool performs browser shutdown, so the guidance is sufficient for selecting the right tool in the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an empty design-system project. A project type is fixed at creation and cannot be changed later, so a design system has to be made as one from the start. Push components into it with write_files, then attach it to projects with link_design_systems so their chats design against it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the design system |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses key behavioral traits: the project is empty and its type is fixed at creation and cannot be changed later. This is critical context for the agent. It does not mention return values or error cases, but the disclosed constraints are significant.
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?
Three concise sentences with the main action front-loaded. The first sentence states what it does, the second explains the immutable project-type constraint, and the third links to sibling tools. No wasted words.
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 creation tool with one parameter and no output schema, the description covers purpose, constraints, and integration with sibling tools. It doesn't mention what is returned (e.g., project ID) or behavior on name conflicts, but the essential context is present.
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 has 100% coverage with the 'name' parameter described. The tool description adds no extra semantics about naming conventions or requirements beyond 'Name for the design system', so the baseline 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 states 'Create an empty design-system project' with a specific verb and resource, clearly distinguishing it from the generic create_project sibling by emphasizing the empty project and fixed type.
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 explicitly states when to use this tool ('a design system has to be made as one from the start') and provides a clear workflow: push components with write_files and attach with link_design_systems. This gives the agent strong guidance on sequencing and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a brand new project from the home screen: pick a template, describe what to create, and it begins building. Returns the new projectId. Claude Design names the project from your prompt. Attach local images (screenshots, references) with attachments to design from them.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Wait for the first build to finish | |
| prompt | Yes | What to create. This is the "What should we create?" box. | |
| visible | No | Show the window so the user can watch | |
| maxChars | No | ||
| template | No | Template name or fragment, e.g. "Mobile app" or "Slides". Omit for Blank. | |
| attachments | No | Local file paths to attach, e.g. screenshots from this repo | |
| idleSeconds | No | ||
| timeoutSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context: Claude Design names the project from the prompt, attachments are used as design references, and it returns the new projectId. However, it does not disclose timing/side-effect behaviors like waiting for the build to finish or window visibility, which are influenced by parameters and not covered by annotations (since none exist).
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?
Three sentences, front-loaded with the main action, and each sentence earns its place: workflow, auto-naming behavior, and attachment usage. No wasted words.
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?
With 8 parameters, no annotations, and no output schema, the description covers the core workflow and return value (projectId) but omits details about wait/visible/timeout parameters. It is sufficient for a basic invocation but not a comprehensive reference.
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 description coverage is 63%, and the description adds meaning for a few parameters: 'pick a template' explains the template param, and 'design from them' clarifies attachments. Other parameters like wait, visible, and timeoutSeconds are not explained in the description, though the schema provides some detail. This is a minimal compensation.
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 starts a brand new project from the home screen, with a specific workflow (pick template, describe, begin building). This distinguishes it from siblings like list_projects and delete_project, which operate on existing projects.
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 that this is for starting a new project from the home screen. It does not explicitly exclude alternatives or state when not to use it, but the context is unambiguous enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete one chat thread from a project, including its transcript. No undo.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Permanently delete', 'including its transcript', and 'No undo', which effectively communicates irreversibility and the scope of deletion. It does not mention permissions or error handling, but the destructive nature is clearly disclosed.
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 leads with the action verb and immediately states the key consequence ('No undo'). Every word contributes value, and it is perfectly sized for a straightforward destructive operation.
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 simplicity of the operation (2 required string params, no output schema, no annotations), the description adequately covers the essential context: what is deleted, the scope, and irreversibility. It does not explain return values or error cases, but for a delete tool without an output schema, this is not a critical omission. It is nearly complete for its complexity.
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 schema description coverage is 0%, so the description should compensate. It partially does by saying 'one chat thread from a project,' implying projectId scopes the project and chatId identifies the thread. However, it does not explain parameter formats, constraints, or relationships beyond these implied roles, so it adds only modest value over 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 uses the strong verb 'delete' with a clear resource ('chat thread'), specifies the exact scope ('from a project'), and includes additional clarity about what is deleted ('including its transcript'). It clearly distinguishes itself from sibling tools like delete_project and delete_files by naming the chat thread as the target.
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 this tool is appropriate: permanently removing a chat thread. It does not explicitly name alternatives or state when not to use it, but the phrase 'from a project' frames the scope. It lacks explicit exclusions or comparisons to delete_project/delete_files, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete files from a Claude Design project. No undo. Verifies they are gone.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Project-relative paths | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses permanence ('Permanently delete', 'No undo') and verification ('Verifies they are gone'), which are key behavioral traits. It does not mention permissions or recursive behavior, but the essential risk factors are covered.
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 extremely concise: three short sentences, each providing essential information. No filler or redundancy; every phrase adds value.
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's simplicity and lack of annotations or output schema, the description covers the core destructive aspects and verification. However, it omits details about non-existent paths, whether directories can be deleted, or error/return behavior, leaving some ambiguity for an agent.
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 has 50% parameter description coverage ('Project-relative paths' for paths, projectId undocumented). The description adds context by indicating 'from a Claude Design project', which clarifies projectId's role, but it does not explain the format or constraints of paths 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 'Permanently delete files from a Claude Design project' with a specific verb and resource. It unmistakably differentiates from sibling tools like delete_chat or delete_project by focusing on 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?
The description implies usage for deleting files but does not explicitly state when to prefer this over alternatives like write_files or delete_project. The 'No undo' warning provides caution but no direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a Claude Design project or design system. There is no trash and no undo. Ask the user before calling this, then pass the project's exact current name as confirmName: the call is refused if it does not match, which is what stops the wrong project being deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| confirmName | Yes | The project's exact current name, from list_projects |
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 permanent deletion, absence of trash/undo, the confirmation requirement, and the refusal behavior when confirmName does not match—all critical behavioral traits for a destructive operation.
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 concise sentences front-load the action and essential safety constraints. Every word earns its place, with no irrelevant detail.
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?
The tool has no output schema or annotations, but the description covers purpose, safety, and parameter usage thoroughly. It could mention what happens on success (e.g., confirmation message), but the provided information is sufficient for safe invocation.
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 schema documents confirmName but not projectId (50% coverage). The description adds meaningful context for confirmName (exact current name, mismatch refusal) and clarifies the deletion target, partially compensating for the missing projectId 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 begins with 'Permanently delete a Claude Design project or design system', a specific verb and resource. The title and sibling tools (delete_chat, delete_files) further distinguish it, making the tool's purpose unmistakable.
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 explicitly instructs to ask the user before calling and explains the confirmName safeguard. It provides clear context for when to use the tool but does not mention alternative tools or when not to use it beyond the user-permission requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set which design systems a project designs against. Replaces the current set, so pass every one you want kept. Pass an empty list to detach all.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| designSystemIds | Yes | Project ids of design systems. Empty array detaches all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing the tool's side effects. It clearly states that the operation replaces the entire current set, which is critical behavioral information. It also explicitly covers the 'detach all' behavior with an empty list, leaving no ambiguity about the mechanism.
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 short sentences, front-loaded with the main purpose, and every phrase adds value. It avoids repetition and is immediately readable, making it an excellent example of concise, well-structured documentation.
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 two-parameter tool with no output schema, the description covers the main behavior, the replacement semantics, the empty-list special case, and how to correctly provide the parameter. No additional context is needed; the tool is fully specified for an agent to use correctly.
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 schema provides descriptions for designSystemIds (including the empty array behavior) but not for projectId. The description adds critical meaning to designSystemIds by instructing the user to 'pass every one you want kept,' which supplements the schema's note. While projectId is not elaborated, its role is self-evident from the name and context, so the description compensates adequately for the 50% schema 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 ('Set which design systems a project designs against') with a specific verb and resource. It distinguishes itself from sibling tools like 'create_design_system' (which creates a new system) and 'link_local_code' (which connects code), making its purpose unambiguous.
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 explicit instructions on how to use the tool: 'Replaces the current set, so pass every one you want kept. Pass an empty list to detach all.' This tells the agent exactly what to pass and handles the edge case. It doesn't name alternative tools, but no close alternative exists among siblings, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a folder from this machine to a Claude Design project, so it designs against your real code. Sends text files only, skipping .git, node_modules and build output, bounded by file count and total size. Point it at the frontend or design-system folder rather than a whole monorepo.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | Yes | Local directory path | |
| visible | No | ||
| maxBytes | No | ||
| maxFiles | No | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: 'Sends text files only, skipping .git, node_modules and build output, bounded by file count and total size.' This is valuable for understanding filtering and limits. It does not mention auth or return behavior, but the core operation is well-disclosed.
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 three sentences, each contributing essential information: the action, the filtering behavior, and the recommended usage. No fluff or redundancy; it is front-loaded with the main verb and resource.
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 tool with 5 parameters, no output schema, and no annotations, the description covers the essential purpose, filtering behavior, and typical usage scenario. It could detail all parameters, but the schema and context signals (like sibling list_projects) fill in some gaps. It is reasonably complete for an agent to understand when and how to invoke it.
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 description coverage is only 20%, so the description must compensate. It provides meaningful context for the 'dir' parameter ('frontend or design-system folder') and conceptually mentions file count/size limits, but does not name parameters like maxFiles/maxBytes or explain units. It partially compensates but leaves projectId and visible undocumented.
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 'Attach a folder from this machine to a Claude Design project,' using a specific verb and resource. It distinguishes itself from siblings like choose_repository by focusing on local folder attachment, and adds scope ('so it designs against your real code') and placement guidance ('frontend or design-system folder').
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 usage context: 'Point it at the frontend or design-system folder rather than a whole monorepo.' This gives an exclusion (don't use for monorepo) but does not explicitly name alternative tools or provide when-not-to-use scenarios beyond that. Effective but lacks full alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the chat threads inside one Claude Design project, newest first, marking which one is active.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Project UUID from list_projects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds behavioral details like 'newest first' and 'marking active', but does not explicitly state that it's read-only or describe the return format. For a simple list tool, it provides some transparency but not full.
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?
One clear sentence, front-loaded with purpose, no redundant words.
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 1-param tool with no output schema, the description covers purpose and some behavioral details. It could be improved by describing the return structure, but it's reasonably complete for a simple list operation.
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% (projectId described in schema), so baseline is 3. The description does not add parameter-specific information beyond what the schema provides.
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 verb 'List' and resource 'chat threads inside one Claude Design project', with specific details (newest first, active marking). Distinguishes from sibling list tools like list_projects and list_templates by specifying the resource and project scope.
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 (to view chats in a project) but does not explicitly state when to use this vs alternatives. No mention of exclusions or prerequisites beyond the schema's projectId reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files in a Claude Design project.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Only paths starting with this | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only restates that it lists files; it does not mention whether listing is recursive, includes directories, respects permissions, or any output shape. The return format and any side effects are completely undisclosed.
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, front-loaded sentence with zero wasted words. It states the verb, resource, and scope efficiently.
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?
The tool is simple, but with no output schema and no annotations, the description should at least hint at return values or usage alternatives. It does neither, so an agent is left with only the name and schema to infer behavior. The description is minimally viable but lacks important context.
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 description coverage is 50% (prefix is described, projectId is not). The tool description adds no parameter semantics whatsoever, leaving projectId's meaning implicit and failing to clarify the filtering behavior of prefix beyond the schema's minimal 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 uses a specific verb and resource: 'List the files in a Claude Design project.' This clearly distinguishes it from sibling tools like list_chats, list_projects, and list_templates, which target other resource types.
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 no guidance on when to use this tool versus alternatives such as pull_files, read_file, or search_code. It only states what the tool does, not when it is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every claude.ai/design project you can open, with its projectId and whether it is a design system. Start here to pick the right project.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by project type | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The phrase 'you can open' adds context about access scoping, but it does not explicitly state that the operation is read-only or describe any side effects. The verb 'List' implies read-only, but a more explicit disclosure would be better.
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 long, front-loaded with the core functionality, and includes a helpful usage hint. Every word earns its place with no 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?
The tool is simple with only one optional parameter and no output schema. The description explains the key return fields (projectId and design system status) and gives usage guidance. It lacks only minor details such as return format or pagination, which are not critical for this straightforward list operation.
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 has 100% coverage with a single enum parameter and default value, so the schema already fully documents the parameter. The description does not mention the 'kind' parameter, but it is not required given the schema coverage. Baseline 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 uses a specific verb ('List') and resource ('claude.ai/design project'), and specifies the output fields (projectId and design system flag). It clearly differentiates from siblings like list_chats or list_templates by focusing on projects, and even guides the user to 'start here'.
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 usage context by stating 'Start here to pick the right project', indicating when to use the tool. However, it does not explicitly mention exclusions or alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The template tiles on the Claude Design home screen (Blank, Mobile app design, Slides, Wireframe, Diagram and the rest). Use before create_project to pick one by name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only listing operation (via the verb 'list') and provides context about home screen tiles, but it does not disclose return format, sorting, or any edge cases. For a simple list tool, this is adequate but not rich.
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 efficient sentences: the first states what is listed, the second gives usage context. No filler, well front-loaded, every sentence earns its place.
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 zero-parameter list tool with no output schema and no annotations, the description covers the essential purpose and usage. It implies the return value is template names ('pick one by name'), though it stops short of detailing the exact response structure. This is nearly complete for the tool's simplicity.
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 has zero parameters, so the baseline per rubric is 4. The description adds no param-specific meaning, but none is needed; it focuses on output semantics (template names).
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 lists project templates, naming specific examples (Blank, Mobile app design, Slides, etc.). It distinguishes from sibling tools by focusing on template tiles, not chats, projects, or other resources.
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?
Explicitly instructs when to use: 'Use before create_project to pick one by name.' This names the follow-up tool and gives a clear workflow, satisfying the when-to-use requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bring the Claude Design window on screen and open a project, optionally a specific chat and a specific file, so the user can watch. Use this before send_prompt when the user should see the work happen, and to show them a finished screen. The browser normally sits parked offscreen, so nothing is visible until this is called.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | File to open in the viewer, e.g. Prototype.dc.html | |
| chatId | No | Chat to make active first | |
| visible | No | false parks the window back offscreen | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses a key behavioral trait: 'The browser normally sits parked offscreen, so nothing is visible until this is called.' This adds valuable context beyond the schema, explaining why the tool is necessary and what you can expect if you don't call it.
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 concise sentences front-load the main purpose and immediately follow with usage guidance. No redundant wording or filler – every sentence contributes essential 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 straightforward UI-control tool with no output schema, the description covers the essential context: what it does, when to use it, and why it's needed (offscreen browser). It doesn't describe edge cases like what happens if the project ID is invalid, but such details aren't critical for this kind of atomic action.
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 schema already documents most parameters (path, chatId, visible) with descriptions, covering 75%. The description references these parameters indirectly ('open a project', 'specific chat', 'specific file') but doesn't add new syntax or format details, so it adds minimal value 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 tool's purpose: bringing the Claude Design window on screen and opening a project, chat, and file for the user to watch. It uses specific verbs (bring, open) and references the resource, distinguishing it from siblings like close_browser or send_prompt.
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 explicit usage context: 'Use this before send_prompt when the user should see the work happen, and to show them a finished screen.' It also explains the crucial background behavior that the browser is normally offscreen, making the need for this tool clear. It stops short of listing when not to use it or naming alternatives explicitly, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download files from a Claude Design project into a local directory, preserving paths. Handles binaries.
| Name | Required | Description | Default |
|---|---|---|---|
| dest | Yes | Local directory to write into | |
| paths | No | Explicit list of paths, overrides prefix | |
| prefix | No | Only paths starting with this | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses 'preserving paths' and 'handles binaries', which are useful behavioral traits. However, it does not state whether existing local files are overwritten, whether directories are created, or what happens if both paths and prefix are provided. These gaps leave key behaviors unexplained.
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, front-loaded with the core action. Every phrase adds value: 'Download files', 'into a local directory', 'preserving paths', 'handles binaries'. There is no fluff or repetition.
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 moderate complexity (4 params, no annotations, no output schema), the description is understandably brief but leaves out important context: what happens on local conflicts, whether the destination is created, and what the function returns. The schema partially compensates for parameter details, but the overall tool behavior is not fully specified.
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 75% (three of four parameters described), so the baseline is 3. The description adds no direct parameter details beyond what the schema provides. It relates indirectly via 'preserving paths' to the paths/prefix semantics, but does not clarify the relationship between paths and prefix or the default behavior when both are absent.
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 uses a specific verb ('Download') and clearly names the resources ('files from a Claude Design project') and destination ('local directory'). It distinguishes from siblings like write_files (upload), list_files (list), and read_file (read single file) by emphasizing the pull/download direction and adding 'preserving paths' and 'handles binaries'.
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 clearly communicates when to use the tool: when you need to download project files to local disk. It implies context but does not explicitly name alternatives or exclusions (e.g., 'for uploading use write_files'). The purpose statement alone is enough to infer usage, but missing explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what Claude Design has said. Returns the tail of the transcript for one chat. This is the read side of the conversation: use it after send_prompt, or on its own to catch up on what was discussed in the browser.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent messages to return | |
| chatId | No | Chat id. Defaults to the active chat. | |
| maxChars | No | Per-message clip length | |
| projectId | Yes | Project UUID | |
| includeAll | No | Include system/bookkeeping messages too |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that only the 'tail' is returned and implies a non-mutating read operation, but it omits behavioral nuances like default limit, chatId defaulting, or whether it affects the active chat state.
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 three sentences with no fluff. It front-loads the action, then gives return semantics and usage context, making every sentence useful.
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 read tool with no output schema, the description provides a good mental model: it states what is returned ('tail of the transcript'), when to use it, and that it is non-destructive. It could be improved by noting that projectId is required, but the schema already covers that.
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 description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it references 'tail' implicitly but does not explain how limit or maxChars affect the result.
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 uses a specific verb 'Read' and a clear resource ('what Claude Design has said', 'the transcript for one chat'). It explicitly differentiates from siblings by labeling it the 'read side' of the conversation and contrasting it with send_prompt.
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 provides clear usage context: 'use it after send_prompt, or on its own to catch up on what was discussed in the browser.' This tells when to use the tool, but it does not explicitly mention alternatives or when not to use it, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file straight out of a Claude Design project, no download needed. A .dc.html page runs to hundreds of KB, so use offset/limit to read a slice, and search_code first to find the line you want.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Keep Claude Design's injected preview runtime instead of stripping it | |
| path | Yes | Project-relative path, e.g. Prototype.dc.html | |
| limit | No | How many lines. Omit for the whole file, subject to maxChars. | |
| offset | No | First line to return, 0-based | |
| maxChars | No | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses useful behavioral traits: files can be hundreds of KB, so slicing is recommended, and no download is needed (inline access). However, it does not describe the return format, error handling, or any permission requirements, leaving gaps in behavioral transparency. The added context about file size and slicing is appreciated but not comprehensive.
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 long, front-loaded with the primary purpose, and every clause contributes: the first sentence states what the tool does, the second gives practical usage tips. There is no redundant filler or repetition of schema details.
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 read-only file access tool with 6 parameters, no annotations, and no output schema, the description covers the essential context: direct project access, large-file handling with offset/limit, and integration with search_code. It does not explain return value structure or error cases, but the core usage scenario is well addressed, making it nearly complete for common needs.
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 67% (4 of 6 parameters have descriptions). The description explicitly explains the purpose of offset/limit ('read a slice'), adding meaning beyond the schema. However, it does not compensate for the missing descriptions of maxChars and projectId, and it does not elaborate on the raw parameter. The description adds some value but largely relies on 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 tool's function: 'Read a file straight out of a Claude Design project, no download needed.' It specifies a concrete verb ('read') and resource ('file from a Claude Design project'), and distinguishes itself from siblings like search_code (finding lines) and pull_files (downloading) by emphasizing in-place reading. The title 'Read the built code' reinforces the purpose.
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 actionable guidance: for large files, use offset/limit to read a slice, and use search_code first to locate the line. This implies a workflow and when to use read_file versus search_code, but it does not explicitly mention alternative tools like pull_files for downloading or state when not to use read_file. Still, the context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture what a page in a Claude Design project actually looks like and return it as an image, so you can judge the work rather than taking the designer's word for it. Use it after send_prompt to check the result, before sending a revision so your critique is specific, and whenever the user asks whether something looks right. Captures the rendered design out of the viewer, without the app's own UI around it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Page to capture, e.g. Components.dc.html. Omit for whatever is open. | |
| width | No | Viewport width, e.g. 402 for an iPhone-class frame | |
| chatId | No | ||
| format | No | png for crisp type, jpeg for a smaller image | jpeg |
| height | No | ||
| quality | No | jpeg only | |
| visible | No | Show the window while capturing | |
| fullPage | No | Capture the whole document instead of the visible area. Can be very tall. | |
| savePath | No | Also write the image here. Use for full-page captures instead of returning them inline. | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the screenshot captures the rendered design out of the viewer without app UI, which is useful. However, it does not mention whether the design must be open, any waiting behavior for rendering, or that the operation is read-only. Given the tool's simple nature, this is adequate but not richly transparent.
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, front-loaded with the core function, and every sentence adds value: what it does, when to use it, and a key detail about the output (no UI chrome). No wasted words.
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 tool with 10 parameters, no annotations, and no output schema, the description covers purpose and usage but leaves gaps: it does not explain the return format (e.g., inline image vs. savePath), whether the project must be currently open, or any limitations like fullPage being very tall. The schema helps but is not fully relied upon because coverage is only 70%.
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 description coverage is 70%, so the schema already explains most parameters (e.g., path, width, format, quality). The description does not add parameter-specific meaning beyond the tool's overall purpose, but it does not need to since the schema covers most. It provides context that could help interpret parameters like 'path' and 'fullPage' implicitly, but no direct additions.
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 captures a page in a Claude Design project and returns it as an image, distinguishing it from sibling tools by emphasizing its use for visual review. The verb 'capture' plus the resource 'page' is specific, and the title 'See the design' reinforces the purpose.
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 explicit usage guidance: use after send_prompt to verify results, before revisions to make critique specific, and whenever the user asks if something looks right. This clearly indicates when to invoke the tool and connects it to the workflow with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grep the project's own files for a regex and get back matches with line numbers and context. This is how you find what Claude Design actually built without downloading anything: locate the markup or token, then read_file that region.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | Regex flags | i |
| prefix | No | Only search paths starting with this | |
| pattern | Yes | JavaScript regex source, e.g. shelf-builder|line-tab-feed | |
| projectId | Yes | ||
| maxMatches | No | ||
| contextLines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format (matches with line numbers and context), the scope (project's own files), and a key behavioral trait (doesn't download anything). It doesn't mention limits or performance, but for a read-only grep-like operation, this is reasonably transparent. No contradictions with annotations exist since none are provided.
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 pack in the core purpose, return details, and a usage workflow. Every clause earns its place; there is no redundancy or fluff. The structure is front-loaded with the verb and resource, making it immediately scannable.
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 search tool with no output schema, the description covers the essential aspects: what it searches, what it returns, and how to follow up. It doesn't mention defaults for maxMatches or contextLines, but those are schema-documented. The overall context is sufficient for an agent to decide and invoke the 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 description coverage is 50%, so the description must compensate. It adds meaning for 'pattern' by giving examples ('markup or token') and implies 'contextLines' via 'context'. However, it doesn't clarify flags, maxMatches, projectId, or prefix beyond what the schema already provides. It adds some value but not comprehensive parameter guidance.
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 uses a specific verb ('Grep') and resource ('the project's own files') and clearly states the function: regex search with line numbers and context. It distinguishes itself from siblings by emphasizing that it works on the built code without downloading anything, positioning it as a local inspection tool, and even suggests a follow-up with read_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?
The description explicitly explains when to use this tool: to find what Claude Design actually built without downloading, by locating markup or tokens and then reading the region with read_file. It provides a clear workflow and an implicit exclusion (don't download), though it doesn't name alternative tools directly, the direction is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give Claude Design an instruction in one project and wait for it to finish, then return what it said and which files it touched. It runs its own agent loop (reading and writing project files, taking screenshots), so a single prompt can take minutes. Sends into the project's active chat.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Wait for it to finish. false returns as soon as the prompt is sent. | |
| chatId | No | Chat to post into. Defaults to whichever is already active. | |
| prompt | Yes | What Claude Design should do | |
| visible | No | Show the browser window so the user can watch it work | |
| maxChars | No | Per-message clip length | |
| projectId | Yes | Project UUID from list_projects | |
| attachments | No | Local file paths to attach, e.g. a screenshot from this repo to design from or compare against | |
| idleSeconds | No | Network-quiet period before checking for a reply. Raise it for jobs with long tool calls. | |
| timeoutSeconds | No | Give up waiting after this long | |
| referenceProjectIds | No | Other projects to pull context from. Their URLs are appended to the prompt, which is how Claude Design picks them up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it discloses that the tool runs its own agent loop, reads/writes project files, takes screenshots, waits for completion, and returns what was said and which files were touched. It also notes the potentially long duration. This goes beyond minimal, though it does not mention explicit timeouts or error conditions.
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 three concise sentences: first states the core action, second adds critical behavior and duration, third clarifies the target chat. No redundant words, and the information is 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?
Given the tool's complexity (10 params, no output schema), the description adequately explains the return value, side effects, and long-running nature. It could mention more about parameter interactions (e.g., referenceProjectIds, wait=false), but the schema covers those details. The description provides enough for an agent to decide whether to use this tool and what to expect.
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 schema already provides descriptions for all 10 parameters (100% coverage), so the description adds little beyond the schema. It does clarify the 'active chat' default and that returns include touched files, which slightly enriches semantics, but the schema does the heavy lifting.
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's function: sending an instruction to Claude Design in a project, waiting for completion, and returning the response and touched files. It uses a specific verb ('Give') and resource ('Claude Design'), and the agent-loop behavior distinguishes it from sibling tools like read_chat or write_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?
It provides clear context for when to use this tool: when you want Claude Design to autonomously work on an instruction in an active chat. It does not explicitly list alternatives or exclusions, but the description's emphasis on the agent loop and waiting time implies appropriate use cases. The mention of the active chat and the 'single prompt can take minutes' qualifier gives the agent a sense of expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a different chat thread active in a project. send_prompt always posts into the active chat, so use this to aim it at the right conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavioral trait: switching the active chat state, and the consequence that send_prompt targets the active chat. However, it does not mention return values, whether the operation is reversible, or any error/validation behavior, which are gaps for a state-changing tool.
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, front-loaded with the core purpose, and every sentence earns its place. It is concise and adds meaningful context without repetition or filler.
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 two-parameter switch tool, the description is largely complete: it explains the purpose, the relation to send_prompt, and the project context. It does not explain how to get the IDs, but with sibling list_chats and list_projects, this is a minor gap rather than a critical omission.
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 description coverage is 0%, and the description provides no parameter-specific details. While chatId and projectId are self-explanatory from their names, the description does not explain where to obtain these IDs, their format, or how they relate to list_chats/list_projects, so it fails to compensate for the lack of structured parameter descriptions.
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's verb ('Make a different chat thread active'), resource ('chat thread'), and scope ('in a project'). It also distinguishes itself from siblings by explicitly referencing send_prompt's behavior, making it clear this is a targeting/selection tool rather than a list/delete/read operation.
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 gives clear usage context: send_prompt always posts into the active chat, so use switch_chat to aim at the right conversation. It effectively names the primary alternative (send_prompt) and the rationale, but does not explicitly mention when not to use this tool or list other alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push a Figma .fig file from disk into a project through the import menu.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Local path to the .fig file | |
| visible | No | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden but only mentions 'through the import menu,' hinting at UI automation. It does not disclose side effects, file size limits, whether uploads overwrite existing files, or any required authentication state.
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 immediately conveys the core purpose without redundant words. It is well-structured 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?
While the tool is simple, the description leaves gaps: no output/return behavior is mentioned, 'visible' is unclear, and no guidance is given for obtaining the required projectId. The low schema coverage amplifies these omissions, making it only minimally 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 only 33% (only 'path' is described), and the description adds minimal clarification: 'from disk' explains path and 'into a project' explains projectId. However, the 'visible' parameter is entirely unexplained, and projectId lacks a description in both schema and 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 action ('Push a Figma .fig file') and the resource ('from disk into a project'), making it easy to understand what the tool does. It distinguishes itself from sibling tools like pull_files or list_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?
The description implies usage (uploading .fig files to projects) but does not explicitly state when to use it versus alternatives or mention prerequisites. It does not note that projectId could come from list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or overwrite files in a Claude Design project or design system. Use to push components, tokens or assets up from the repo. Overwrites without asking, so read first if unsure.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It explicitly discloses the destructive behavior: 'Overwrites without asking', which is critical for an AI agent to know. However, it lacks details about return values, potential failures, or side effects like directory creation.
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, front-loading the main purpose in the first sentence and adding a crucial caution in the second. Every word earns its place with no 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 schema thoroughly defines parameters and the description covers the key behavior (overwrite without asking), the tool is sufficiently specified. It lacks details on concurrency, limits (though schema has maxItems), or output, but these are not critical for a write 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?
The description does not directly explain parameters (schema coverage 0%), but the schema itself already provides clear descriptions for path, content, and encoding. The phrase 'push components, tokens or assets' adds context but doesn't define the parameters, so the description adds minimal semantic value 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 'Write or overwrite files' with a specific resource ('Claude Design project or design system'), giving a precise action and object. It distinguishes from sibling tools like read_file and pull_files by focusing on the write operation.
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 usage context: 'Use to push components, tokens or assets up from the repo', indicating the direction and content type. The warning 'read first if unsure' implies using a read tool when in doubt, though it does not explicitly name alternatives like read_file or pull_files.
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. Dates show when Glama detected each change.
v0.1.0choose_repositoryclose_browsercreate_design_systemcreate_projectdelete_chatdelete_filesdelete_projectlink_design_systemslink_local_codelist_chatslist_fileslist_projectslist_templatesopen_screenpull_filesread_chatread_filescreenshotsearch_codesend_promptswitch_chatupload_figwrite_filesScored across 23 tools
Every tool targets a distinct resource and action: list_* covers different entities, delete_* differentiates by object, and read_chat vs read_file vs screenshot are clearly separate. No two tools appear to do the same thing.
All tool names follow a consistent verb_noun snake_case pattern (list_chats, create_project, delete_files, etc.), with only minor exceptions like screenshot that are still readable and predictable.
At 23 tools, the set is within the 16-25 range that feels heavy for a typical MCP server. While each tool seems necessary for the broad domain, the count is borderline and may overwhelm agents.
Core workflows for projects, chats, files, design systems, and external links are covered, but there are minor gaps: no explicit create_chat tool for starting a fresh thread in an existing project, and no list_repositories to discover available GitHub repos before choosing one.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Serves your design system and coding standards to coding agents, so they stop guessing.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Build, version, review, and export websites, web apps, and games from a conversation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/marvin-socialista/claude-design-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
