Get the onboarding prompts for a named system to bootstrap a design package and sync it to Claude Design. Provide the system name to receive the copy-paste guide.
Markdown onboarding doc for a public system: the two copy-paste prompts an external AI coding agent uses to bootstrap a design package and sync it to Claude Design.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | System name, public slug or alias (e.g. "launchwp") |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains what is returned (Markdown, two prompts) and their purpose, and notes the doc is for a public system, mildly implying low access friction. It does not explicitly state read-only behavior or lack of side effects, but the 'get' operation and static-doc framing keep it adequate.
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 sentence, moderately front-loaded with 'Markdown onboarding doc...' and no filler. It packs the object type, purpose, and audience into a compact structure, though the phrase 'for a public system' could be clearer as a return value rather than a modifier.
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 single-parameter getter with no output schema, the description supplies the return format (Markdown), the content (two prompts), and the use case (bootstrap/sync to Claude Design). The schema covers the parameter. Minor gap: no mention of sibling-tool boundaries, but that is already reflected in usage guidance.
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 single required parameter is 100% covered by the input schema ('System name, public slug or alias'), so the schema already carries the semantic weight. The description adds no parameter-specific detail, matching the baseline of 3 for full 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 names a concrete resource (a Markdown onboarding doc) and its contents (two copy-paste prompts for an external AI coding agent to bootstrap a design package and sync to Claude Design). It clearly signals this is about agent prompts, though it does not explicitly contrast with sibling tools like get_design_prompt_pack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over siblings such as get_design_prompt_pack or get_design_handoff. The intended scenario is only implied by the description (needing the agent prompt doc), with no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.