standby-design-mcp
Server Details
Generate design systems: OKLCH color palettes, fluid type scales, spacing, shape and icon tokens.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 8 of 8 tools scored.
Each tool targets a distinct aspect of design system generation: colors, icons, shapes, spacing, typography, exporting, retrieving, and font listing. No overlapping functionality; descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., generate_color_palette, list_fonts). No mixing of conventions or ambiguous names.
With 8 tools, the server covers all major token categories and key operations (generation, export, retrieval, font listing). The count is well-scoped for its purpose—neither too few nor excessive.
The tool surface provides complete coverage for generating, exporting, and retrieving design systems. All essential token types are covered, and export supports multiple formats. There are no obvious gaps that would hinder an agent.
Available Tools
8 toolsexport_design_systemExport design system codeARead-onlyInspect
Generate the full token code for a design system URL in one format: "css" (CSS custom properties incl. semantic shadcn/ui-compatible tokens), "tailwind" (Tailwind v4 @theme), "design-tokens" (W3C DTCG JSON — typography & spacing), "llm-briefing" (Markdown brief for AI code generation), or "font-embed" (Fontshare snippet). Optionally restrict to specific sections. Always give the returned standby.design/system URL to the user alongside the code — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A standby.design URL or raw unified hash. | |
| format | Yes | Output format. | |
| sections | No | Which sections to include. Default: all configured sections (symbol only when configured). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so no side effects. The description adds behavioral context by telling the agent to present the standby.design/system URL alongside the code, which is an important user-facing instruction. 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 a single, dense paragraph that is front-loaded with the main action. It efficiently lists format options inline. No wasted words, though slight restructuring could improve readability.
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 absence of an output schema, the description adequately covers the key aspects: input parameters (fully detailed), output format options, and the required agent behavior of returning the URL. It could mention that the output is code/text, but the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value beyond schema by detailing the output for each format (e.g., 'CSS custom properties incl. semantic shadcn/ui-compatible tokens') and clarifying the default behavior for the sections parameter ('Default: all configured sections').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Generate') and resources ('full token code for a design system URL'), and lists available formats. It clearly distinguishes itself from sibling tools like generate_color_palette or generate_icon_tokens by focusing on exporting an entire design system in a chosen format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool and includes the instruction to always return the URL. However, it does not explicitly mention when not to use it or directly compare to sibling tools, though the purpose implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_color_paletteGenerate color paletteARead-onlyInspect
Generate a perceptually uniform OKLCH color palette from a brand color: 18-step scales for brand/surface/error/accents, semantic tokens (shadcn/ui compatible), light+dark modes. Returns a shareable standby.design/system URL and a compact summary. Always give that URL to the user — the link is the deliverable; it opens the live system in the browser. Use export_design_system for full CSS/Tailwind output.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults. | |
| mode | No | "balanced": step 500 is always the perceptual midpoint (even light/dark distribution). "exact": step 500 keeps the input color's lightness. | |
| accents | No | Up to 3 additional named accent colors. Replaces the existing accent list when provided; pass [] to remove all accents. Default: Success/Warning/Info, auto-derived. | |
| brandHex | No | Brand color as 6-digit hex, e.g. "#335A7F". The palette midpoint is derived from this. | |
| brandPin | No | Pin the primary token to the exact input hex instead of the palette step. | |
| errorPin | No | ||
| themeName | No | Name of the design system (appears in exports and page title). | |
| bgColorHex | No | Surface tint color as hex, or "auto" to derive from the brand color (default). | |
| brandInvert | No | For pinned brand: mirror lightness in dark mode (e.g. black buttons in light mode, white in dark). | |
| chromaScale | No | Surface saturation 0–1 (0 = grey surfaces, 1 = vibrant). Default 0.25. | |
| errorInvert | No | ||
| errorColorHex | No | Error/destructive color as hex, or "auto" to derive from the brand hue (default). | |
| fgContrastMode | No | Text color strategy on colored backgrounds. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, which is consistent. The description adds that the tool generates a URL and that modifying via the 'url' parameter only changes this tool's section, preserving others. This goes beyond the annotation read-only hint.
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?
Four sentences with clear front-loading: purpose, output, crucial user instruction, and alternative. Every sentence is valuable, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (13 parameters, no output schema). The description explains the URL deliverable and a compact summary but does not detail the summary content or the 18-step scales. Given the complexity, more output specification would be beneficial.
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 85%, so baseline is 3. The description adds context like 'auto-derive from brand color' for some parameters, but this mostly mirrors the schema's existing descriptions. No substantial added meaning.
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 specifies the verb 'generate', the resource 'color palette', and details the outputs: 18-step scales, semantic tokens, light+dark modes, and a URL. It clearly distinguishes from sibling 'export_design_system'.
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 tells when to use this tool (to generate a palette) and provides an explicit alternative in export_design_system for full CSS/Tailwind output. It also instructs to always give the URL to the user. Could mention other token generation siblings but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_icon_tokensGenerate icon tokensARead-onlyInspect
Pick an icon set and generate icon sizing tokens (xs–2xl + stroke width). Either select a specific set or state style preferences and get a recommendation. Available sets: material-outlined, material-filled, lucide, phosphor-regular, phosphor-bold, phosphor-thin, phosphor-fill, solar-linear, solar-bold, solar-broken, tabler-outline, tabler-filled, radix. Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Icon set variant id to select explicitly, e.g. "lucide-outlined". One of: material-outlined, material-filled, lucide, phosphor-regular, phosphor-bold, phosphor-thin, phosphor-fill, solar-linear, solar-bold, solar-broken, tabler-outline, tabler-filled, radix. Pass "auto" to clear the selection and use the recommendation instead. | |
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults. | |
| scale | No | Size scale ratio (default 1.272). | |
| style | No | Preferred icon style for the recommendation. | |
| weight | No | Preferred stroke weight. | |
| corners | No | Preferred corner style (sharp = corporate/precise, rounded = friendly). | |
| baseSize | No | Base icon size (md) in rem (default 1.25). | |
| snapTo4px | No | Round sizes to the 4px grid (default true). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true contradicts the description's implication of modification via the 'url' parameter ('Existing URL to modify'). This is a serious inconsistency, reducing transparency to 1.
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?
Four sentences, front-loaded with purpose. The list of available sets is lengthy but valuable. Could be slightly more concise but overall 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?
No output schema, but description explains the return value (shareable URL and summary) and emphasizes the deliverable. Covers main use case and parameter combination strategy well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with property descriptions. The description adds context about recommendation behavior and output sizes but does not significantly enhance parameter understanding beyond the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate icon sizing tokens' and specifies the resource (icon set and sizes xs–2xl + stroke width). It distinguishes from sibling token generators by focusing on icons.
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 when to use the tool ('Pick an icon set and generate icon sizing tokens') and provides two modes (specific set or recommendation). It does not explicitly exclude alternatives, but context from sibling tools helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_shape_tokensGenerate shape tokensARead-onlyInspect
Generate shape tokens — radii, shadows, borders, focus rings — in one of four visual styles: "paper" (classic surfaces with layered shadows), "glass" (liquid glass), "neomorph" (soft neumorphism), "neobrutalism" (hard offset shadows). Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults. | |
| style | No | Top-level visual style (default "paper"). | |
| glassBlur | No | Glass backdrop blur (default 1.0). | |
| ringWidth | No | Focus ring width in px (default 2). | |
| glassDepth | No | Glass displacement intensity (default 0.2). | |
| ringOffset | No | Focus ring offset in px (default 2). | |
| shadowType | No | Shadow rendering for paper style. | |
| borderWidth | No | Border width in px (default 1). | |
| shadowScale | No | Elevation level spread ratio (default 1.272). | |
| borderRadius | No | Base radius in px; scales to a xs–xl radius set (default 8). | |
| ringColorHex | No | Custom focus ring color as hex, or "auto" (default). | |
| borderEnabled | No | ||
| shadowEnabled | No | ||
| shadowOffsetX | No | Brutalist shadow X offset in px (default 2). | |
| shadowOffsetY | No | Brutalist shadow Y offset in px (default 4). | |
| borderColorHex | No | Custom border color as hex, or "auto" (default). | |
| separationMode | No | How surfaces separate from the background. | |
| shadowColorHex | No | Custom shadow color as hex, or "auto" (default). | |
| shadowStrength | No | Shadow alpha multiplier (default 1.0). | |
| glassDispersion | No | Chromatic aberration intensity (default 0.4). | |
| shadowBlurScale | No | Shadow blur multiplier (default 1.0). | |
| brutalistVariant | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond what the readOnlyHint annotation already provides. It does not mention side effects, authentication needs, or rate limits. The description adds no additional transparency value.
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 (three sentences) and front-loaded with the core purpose. It ends with an actionable instruction for the agent, making it efficient and well-structured.
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 complexity (22 parameters, no output schema), the description is adequate but incomplete. It explains the styles and the deliverable (URL) but does not mention that all parameters are optional or that the tool can modify an existing system. The modification behavior is only in the schema description, not the main description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), so the baseline is 3. The description adds context about the styles and the optional URL parameter (modifying vs starting fresh), which goes beyond the schema. It does not explain every parameter, but the schema is already descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate', the resource 'shape tokens', and the output (a shareable URL). It distinguishes from sibling tools that generate other token types (color, icons, space, type scale) or perform export/get operations.
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 when to use the tool (to generate shape tokens in one of four visual styles) but does not explicitly state alternatives or when not to use it. It lacks explicit guidance compared to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_space_tokensGenerate spacing & layout tokensARead-onlyInspect
Generate spacing tokens (3xs–3xl), breakpoints, container widths, prose measure, and aspect ratios. Returns a shareable standby.design/system URL and a summary. Always give that URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults. | |
| mode | No | "harmonic": multiples of the base (default). "geometric": compound ratio steps. | |
| snap | No | Snap token values to a sensible grid (default true). | |
| ratio | No | Ratio for geometric mode (default 1.272). | |
| baseRem | No | Base spacing in rem (default 1.0). | |
| containers | No | Replace the container list. Defaults: prose 680, narrow 880, default 1200, wide 1440. | |
| fluidMaxVw | No | Upper fluid viewport anchor in px (default 1920). | |
| fluidMinVw | No | Lower fluid viewport anchor in px (default 375). | |
| multiplier | No | Uniform scale factor on all tokens (default 1.0). | |
| proseMaxCh | No | Prose measure in ch (default 65). | |
| breakpoints | No | Replace the breakpoint list, e.g. [{"name":"sm","minPx":640},...]. Defaults: sm 640, md 768, lg 1024, xl 1280, 2xl 1536. | |
| aspectRatios | No | Replace the aspect ratio list, e.g. [{"name":"video","w":16,"h":9}]. | |
| includeReciprocals | No | Also export flipped (portrait) variants of each ratio (default true). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that only spacing settings are changed, preserving other tool settings. However, annotations claim readOnlyHint=true, contradicting the generation/modification nature. Description adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and output. Every sentence adds value. Zero waste.
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?
Provides necessary context: URL is deliverable, other settings preserved. Lacks request limits or error info, but schema is thorough for 13 params.
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 covers 100% of parameters with descriptions. Description adds no extra parameter meaning but does mention the URL output. 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?
Description clearly states the verb 'generate' and the resource 'spacing tokens, breakpoints, container widths, etc.' It distinguishes from sibling tools (color, type, shape, icons) by specifying its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by describing action and result (URL deliverable) but lacks explicit when-to-use vs. alternatives or when-not-to-use. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_type_scaleGenerate type scaleARead-onlyInspect
Generate a fluid typographic scale (CSS clamp() between 375px and 1920px viewports) with 11 levels (Display, H1–H6, Body L/M/S, Caption), Fontshare fonts, line heights and letter spacing. Returns a shareable standby.design/system URL and a summary table. Always give that URL to the user — the link is the deliverable. Use list_fonts to discover font slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Existing standby.design URL (or raw hash) to modify. Only this tool's section is changed; color/type/shape/icon/spacing settings from other tools are preserved. Omit to start fresh from defaults. | |
| ratio | No | Scale ratio for custom mode. Presets: 1.2 minor third, 1.25 major third, 1.272 golden-ratio-area (default, √φ), 1.333 perfect fourth, 1.618 golden ratio. The empirical perceptual corridor is 1.20–1.50. | |
| baseSize | No | Desktop base size in rem (default 1.0). | |
| bodyFont | No | Fontshare font slug for body text. | |
| monoFont | No | Font slug for code. System stacks: "system-mono", "consolas", "sf-mono". | |
| scaleMode | No | "custom": compound ratio scale (default). "traditional": classical Renaissance point sizes per level. | |
| autoShrink | No | Percent reduction for the auto-derived mobile ratio (default 25). Only used when mobileRatio is not set. | |
| headingFont | No | Fontshare font slug for headings, e.g. "satoshi", "general-sans", "clash-display". | |
| mobileRatio | No | Explicit mobile scale ratio. Omit to auto-derive from ratio and autoShrink. | |
| headingWeight | No | Font weight for headings (default 500). | |
| mobileBaseSize | No | Mobile base size in rem (default = baseSize). | |
| lineHeightOverrides | No | Per-level line-height overrides, e.g. {"h1": 1.1, "body-m": 1.6}. Levels: display, h1–h6, body-l, body-m, body-s, caption. | |
| letterSpacingOverrides | No | Per-level letter-spacing overrides in em, e.g. {"display": -0.05}. | |
| traditionalAssignments | No | For traditional mode: desktop px size per level, e.g. {"display": 48, "h1": 36, ...}. | |
| traditionalMobileAssignments | No | For traditional mode: mobile px size per level. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool can modify existing designs (when url param is provided) and returns a new URL, implying state changes. However, annotations set readOnlyHint=true, which directly contradicts this. The description itself is fairly transparent, but the contradiction reduces the score significantly.
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 with key information front-loaded. It is concise yet informative, providing context about the tool's purpose and deliverables. Minor verbosity could be trimmed but is well-structured overall.
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 main outputs (URL and summary table) and modification behavior. It does not include error handling or limitations, but the complexity is well-addressed 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?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds value by explaining the output and referencing list_fonts for font slugs, but otherwise does not significantly enhance parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a fluid typographic scale using CSS clamp(), specifies 11 levels, Fontshare fonts, line heights, and letter spacing. It identifies the output (standby.design URL and summary table) and distinguishes from siblings by mentioning Fontshare and suggesting list_fonts for font discovery.
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 'Always give that URL to the user' and 'Use list_fonts to discover font slugs,' providing clear usage directives. It does not explicitly state when to avoid this tool versus alternatives, but the sibling list includes other token generators and list_fonts, making the context clear for typography work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_design_systemInspect design systemARead-onlyInspect
Decode a standby.design URL (or raw hash) and return an overview of the full design system: color palette, type scale, spacing & layout, shape tokens, and icons — plus per-tool edit links. Always give the standby.design/system URL to the user — the link is the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A standby.design URL or raw unified hash (e.g. from a previous generate_* call or copied from the browser). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, so description adds context about the return value (per-tool edit links) and the deliverable instruction; no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, no filler, 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?
Given the tool is simple with one param and no output schema, the description sufficiently covers input, output, and a key usage instruction; missing output format details but acceptable.
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% for the single 'url' parameter, and the description largely echoes the schema without adding new semantic details.
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 the tool decodes a standby.design URL and returns a full design system overview, distinguishing it from siblings that generate individual token sets.
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 explicit guidance on when to use this tool versus siblings like export_design_system or generate_* tools; however, the instruction to always give the URL implies it's a primary deliverable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_fontsList available fontsARead-onlyInspect
List Fontshare font slugs usable in generate_type_scale (headingFont/bodyFont/monoFont), grouped by category. This is the bundled seed catalog — any valid Fontshare slug works even if not listed here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it groups by category and that any valid Fontshare slug works beyond the listed ones, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose, no extraneous text.
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 parameter-less tool with no output schema, the description fully describes what the tool returns and clarifies the catalog's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description doesn't need to add param info. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists font slugs usable in generate_type_scale, grouped by category. It also notes it's a bundled seed catalog, distinguishing its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly connects the output to generate_type_scale parameters. It doesn't explicitly state when not to use, but given the simplicity and sibling context, it's clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!