claude-design-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count3/5
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.
Completeness4/5
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.
Average 4.1/5 across 23 of 23 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![claude-design-mcp MCP server](https://glama.ai/mcp/servers/marvin-socialista/claude-design-mcp/badges/card.svg)](https://glama.ai/mcp/servers/marvin-socialista/claude-design-mcp)

Score Badge

Copy to your README.md:

[![claude-design-mcp MCP server](https://glama.ai/mcp/servers/marvin-socialista/claude-design-mcp/badges/score.svg)](https://glama.ai/mcp/servers/marvin-socialista/claude-design-mcp)

Latest Blog Posts

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

MCP directory API

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

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

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