standby-design-mcp

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

The description adds the critical behavioral detail that the returned standby.design/system URL is the deliverable and must always be provided to the user, which goes beyond the readOnlyHint annotation. It also explains format-specific behaviors (e.g., design-tokens only includes typography & spacing), though some of this is already in the schema.

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 and front-loads the core action. The first sentence is dense with the format list, but every sentence carries essential information, including the critical URL deliverable instruction. It could be slightly more concise, but it is not bloated.

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 export tool without an output schema, the description adequately covers the output (code and URL), section filtering behavior, and format semantics. It does not describe error cases or pagination, but the provided information is sufficient for an agent to invoke the tool and handle results 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?

Schema description coverage is 100%, providing a baseline of 3. The description adds significant value by explaining each format enum value (e.g., 'css' includes semantic shadcn/ui-compatible tokens, 'tailwind' is Tailwind v4 @theme), which is not in the schema's generic 'Output format' description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates full token code for a design system URL in one of five explicitly enumerated formats, making the verb and resource specific. It distinguishes from sibling tools (generate_color_palette, generate_type_scale, etc.) by focusing on full-system export rather than individual token 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 implies the usage for full design system export but does not explicitly name alternatives or state when not to use it. Phrases like 'full token code' and 'one format' suggest the use case, but there is no direct comparison to sibling tools or exclusion criteria.

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

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

Annotations declare readOnlyHint=true, and the description does not contradict this. Description adds that the tool generates a URL and summary, but does not elaborate on side effects, auth needs, or rate limits. Since annotations already cover safety, the description provides minimal additional behavioral context.

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?

Description is three concise sentences, front-loaded with the primary function. Every sentence adds essential information without redundancy, making it efficient for an AI agent to parse quickly.

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?

Despite 13 parameters and no output schema, the description clearly explains the return value (URL and summary) and its significance. The rich schema covers parameter specifics, so the description adequately complements it for complete 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 coverage is 85%, so the schema already documents most parameters. Description adds no extra parameter-level detail beyond what is in the schema. Baseline score of 3 is appropriate as the description does not meaningfully enhance parameter understanding.

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?

Description clearly states it generates a perceptually uniform OKLCH color palette from a brand color, specifying outputs (18-step scales, semantic tokens, URL). Distinguishes from sibling 'export_design_system' for full CSS/Tailwind, making the tool's specific purpose evident.

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 to always give the URL to the user as the deliverable, and mentions using 'export_design_system' for full output. Provides clear context for when to use this tool versus alternatives, though lacks explicit 'when not to use' scenarios.

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

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

Annotations declare readOnlyHint=true, and the description adds that the tool returns a shareable standby.design/system URL and a summary, emphasizing that the URL is the deliverable. This is useful behavioral context beyond the safety annotation, though it doesn't detail any side effects (consistent with read-only).

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

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

The description is concise (3 sentences) and front-loaded with purpose, then mode selection, then output. The long list of available sets is somewhat redundant with the schema enum but is easily skimmable and doesn't waste 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?

Given 8 optional parameters with full schema coverage, the description covers the essential decision (set vs. style), output format (URL + summary), and the critical usage note (give URL to user). It doesn't address parameter interactions or precedence, but that's not essential for a first 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 input schema provides descriptions for all 8 parameters (100% coverage). The description restates the set list and style options but does not add new parameter semantics beyond what the schema already specifies. Baseline 3 is appropriate as the schema carries the parameter documentation burden.

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 generates icon sizing tokens (xs–2xl + stroke width) and explicitly lists available icon sets, distinguishing it from sibling tools like generate_color_palette and generate_type_scale. The verb 'generate' plus specific resource 'icon sizing tokens' provides precise 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 explains two distinct usage modes: selecting a specific set or providing style preferences for a recommendation. It gives context for when to use the tool (when icon tokens are needed) but does not explicitly mention alternatives or when not to use it, though sibling names imply these.

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

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

The description discloses that the tool returns a shareable URL and summary, and emphasizes the URL as the deliverable. This adds value beyond the readOnlyHint annotation, and there is no contradiction with annotations.

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

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

The description is two concise sentences, with the main verb and resource front-loaded, and every phrase earns its place (styles, deliverable). No redundancy 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?

The description covers the tool's core purpose, styles, and output deliverable. The rich schema compensates for any missing parameter details, though it could mention the ability to modify an existing URL (which is present in the schema but not the 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?

The schema already provides descriptions for 87% of parameters, so the description adds no parameter-specific meaning beyond that. Baseline 3 is appropriate since 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 identifies the tool as generating shape tokens (radii, shadows, borders, focus rings) and enumerates the four visual styles, differentiating it from sibling token generators as well as other design system tools.

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 creating shape tokens but does not explicitly state when to use this tool versus alternatives or provide exclusions. It does give a clear deliverable instruction ('Always give that URL to the user'), but lacks explicit guidance on when to choose this over sibling tools.

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

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

With readOnlyHint=true and openWorldHint=false provided, the safety profile is covered. The description adds valuable behavioral context by revealing the return format (shareable URL and summary) and the critical instruction that the URL is the deliverable the agent must provide to the user. No contradictions with annotations.

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

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

The description is two sentences long: the first states exactly what the tool generates, the second explains the deliverable and required user-facing action. No wasted words, and the most important 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 13-parameter complexity and no output schema, the description adequately communicates the return value (URL and summary) and the user-facing requirement. It could additionally mention that an existing URL is modified, but that information is already in the schema, so the description is sufficiently 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 description coverage is 100% with all 13 parameters documented in the schema. The main description does not add parameter-level detail beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Generate') and resource ('spacing tokens'), enumerating the exact output categories (3xs–3xl, breakpoints, container widths, prose measure, aspect ratios). It distinguishes itself from sibling token generators like generate_color_palette and generate_type_scale.

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 implies use for generating spacing/layout tokens, and the sibling tool names make the alternative tools obvious. However, it does not explicitly say when not to use this tool or name alternatives directly, so it stops 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.

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

The description details the output (URL, summary table) and the generation process (fluid scale, clamp(), levels). The readOnlyHint annotation is consistent as the tool appears to compute without side effects; no contradiction detected.

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 well-structured sentences that pack essential information (viewport range, levels, fonts, output) without redundancy. Every word serves a purpose.

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 15 parameters and no output schema, the description covers the core functionality, output, and key details. It could mention that the summary table includes level details, but overall it is complete enough for an AI 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?

With 100% schema coverage of parameter descriptions, the tool description adds context by summarizing font categories and referencing list_fonts. This adds value beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a fluid typographic scale with CSS clamp(), specifies 11 levels, Fontshare fonts, and returns a shareable URL and summary table. It effectively distinguishes from sibling tools like generate_color_palette.

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 instructs to always give the URL to the user and recommends using list_fonts to discover font slugs, providing practical usage guidance. It lacks explicit when-not-to-use scenarios but still offers clear context.

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

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

Consistent with readOnlyHint=true (no modification). Adds useful details about output structure (overview content, per-tool edit links) and states the URL is the deliverable, beyond what annotations provide.

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, no wasted words. First sentence explains purpose and output. Second sentence gives a key usage instruction. Front-loaded and efficient.

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

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

For a single-parameter tool with no output schema, the description sets complete expectations: input format, output components, and usage instruction. No gaps.

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?

Adds meaning beyond schema: clarifies acceptable input types (standby.design URL or raw hash) and provenance (from generate_* calls or browser). Schema has 100% coverage but description enriches understanding.

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?

Describes decoding a standby.design URL/hash and returning a full design system overview. Clear verb 'decode' and resource 'design system overview'. Distinguishes from sibling generation tools by focusing on inspection.

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

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

Implies use when a URL/hash is available for inspection. Includes explicit instruction to give the URL to the user as the deliverable. Does not explicitly state when not to use, but context with siblings makes it clear.

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

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

Annotations indicate readOnlyHint=true, and the description adds that it is a bundled seed catalog and that valid slugs not listed still work, providing extra context beyond the annotations.

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

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

The description is two sentences, front-loading the main purpose and resource, with no redundant 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?

Despite having no output schema, the description fully explains what the tool returns (font slugs grouped by category) and its usage context, making it complete for the tool's simple functionality.

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?

There are no parameters, and schema coverage is 100% (empty). The description is not required to add parameter info, but it provides complete context for the tool's input.

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 Fontshare font slugs usable in generate_type_scale, grouped by category. It differentiates from sibling tools which are generation or export tools.

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 links the tool to generate_type_scale usage and notes that any valid Fontshare slug works even if not listed, guiding when to use it. No exclusion criteria are given, but the context is clear.

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