AI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
Check the WCAG contrast ratio between a foreground and background color, with AA/AAA pass/fail for normal and large text.
| Name | Required | Description | Default |
|---|---|---|---|
| bg | Yes | Background color (hex, rgb(), or hsl()). | |
| fg | Yes | Foreground color (hex, rgb(), or hsl()). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds valuable behavioral detail about AA/AAA pass/fail evaluation for normal and large text, which goes beyond the basic 'check' verb. It doesn't mention return format or error handling, but the annotations lower the bar for this dimension.
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 sentence that is front-loaded with the core action and outcome. There is no redundant phrasing, and every part contributes meaning.
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 simple two-parameter tool with good annotations and full schema coverage, the description adequately covers the tool's purpose and key outputs (AA/AAA for normal/large text). It does not describe the exact return structure, but no output schema exists, and the description mentions the essential result criteria.
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%: both fg and bg are described as color strings with acceptable formats. The description does not add extra parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and names the exact resource ('WCAG contrast ratio between a foreground and background color'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like extract_colors or get_palette by focusing on contrast checking rather than color extraction or palette generation.
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 when to use the tool: whenever you need to evaluate contrast between two colors against WCAG standards. However, it does not explicitly mention alternatives or situations when not to use it, missing the top tier of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert code between text formats (e.g. JSON↔YAML, CSS↔SCSS). Pure text transformation: the source is parsed and re-serialized, never executed and never stored. Use list_code_converters for valid from/to ids and per-converter options. Rate limit: 30 calls/min per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target format id. | |
| code | Yes | Source code to convert. | |
| from | Yes | Source format id (see list_code_converters). | |
| options | No | Per-converter options (see optionsSchema in list_code_converters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds important behavioral context: the source is 'parsed and re-serialized, never executed and never stored.' It also discloses a rate limit of 30 calls/min per IP, which is valuable operational information not present in the schema or 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?
Three sentences, each serving a distinct purpose: what the tool does, safety behavior, and how to find required identifiers/options. The description is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the tool's behavior is adequately described for invocation: it takes code and format IDs, uses list_code_converters for valid values, and has a documented rate limit. The pure-transformation guarantee and no-storage note give sufficient context for an agent to use it safely without additional queries.
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 already covers all four parameters with descriptive text (100% coverage), so the description does not need to compensate. It reinforces the meaning of from/to by pointing to list_code_converters, and the JSON↔YAML/CSS↔SCSS examples add semantic flavor, but the schema carries the primary 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 begins with a specific verb and resource: 'Convert code between text formats,' supported by concrete examples (JSON↔YAML, CSS↔SCSS). It clearly distinguishes this from sibling tools by emphasizing pure text transformation, which separates it from minify_code, detect_code, and other 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 directs users to list_code_converters for valid from/to IDs and per-converter options, which is a clear alternative for setup. It also clarifies that this is a pure transformation tool, but it does not explicitly address when to choose this over closely related siblings like minify_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the language/format of a code snippet. Static analysis only — the snippet is never executed and never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Snippet to inspect. Max 200,000 chars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds critical context beyond that: 'Static analysis only — the snippet is never executed and never stored.' This discloses privacy and execution guarantees, which is valuable behavioral transparency not present in the structured data.
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 that are front-loaded with the tool's purpose, followed by a crucial safety note. Every word earns its place, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers purpose, input (code snippet), size limit via schema, and behavioral constraints. It omits explicit mention of the return format (the detected language/format), but that is implied by the name and description. Given no output schema, a brief note on return could improve completeness, but current info is largely 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?
The input schema already provides a description for the single 'code' parameter, and schema coverage is 100%. The tool description does not add additional parameter semantics beyond what's in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Detect' with a clear resource 'the language/format of a code snippet,' making the tool's function immediately obvious. It also distinguishes itself from sibling tools like convert_code and minify_code, which focus on transformation rather than detection.
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 the primary use case: identifying the language/format of a code snippet. It does not explicitly mention when not to use it or name alternatives, but the distinction from siblings (e.g., convert_code) is implicit. Context is clear without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a dominant-color palette from an image. Send either a public image_url or image_base64 (base64/data-URI, e.g. a local screenshot). The image is processed in memory and never stored. Each color comes back with its hex, rgb, hsl, share of the image, and the closest human color name — a named palette in one call. Rate limit: 10 calls/min per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Palette mode: "balanced" (default), "vibrant", or "muted". | |
| count | No | How many colors to return (2–16, default 8). | |
| image_url | No | Public URL of the image to pull the palette from. Provide either this or image_base64. | |
| image_base64 | No | Base64-encoded image (raw base64 or a data:image/...;base64 URI), max 10 MB decoded — use this to send a local file/screenshot without hosting it. Provide either this or image_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent hints, the description discloses that the image is processed in memory and never stored, and includes a rate limit. This adds significant transparency about resource usage and side effects.
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, using two sentences plus a rate limit notice, with no redundant information. It is well-structured and easy to parse.
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 fully covers input, output, constraints, and processing details. It is self-contained and appropriate for the tool's purpose, even without an output schema.
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?
Each parameter is given additional context: mode explains options (balanced, vibrant, muted), count specifies number of colors, and image_url/image_base64 clarify the trade-off between URL and base64, including size limit. This enriches the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts a dominant-color palette from an image, and specifies the input (image_url or image_base64) and output (hex, rgb, hsl, share, color name), distinguishing it from sibling tools like get_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?
It provides usage constraints (public URL or base64, max size, rate limit) and states the processing is in-memory and not stored. However, it does not explicitly contrast with alternative tools like get_palette, so guidance on when to use this vs. others is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a fluid CSS clamp() expression for responsive sizing between two viewport widths. Pure calculation — returns a CSS snippet, writes and stores nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Root font-size in px for rem conversion (default 16). | |
| unit | No | Output unit (default rem). | |
| max_fs | Yes | Maximum size in px. | |
| max_vw | No | Viewport width at max_fs (default 1440). | |
| min_fs | Yes | Minimum size in px. | |
| min_vw | No | Viewport width at min_fs (default 320). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces these by stating 'writes and stores nothing.' It adds the context that the tool returns a CSS snippet, which is useful beyond the annotations. No contradiction exists.
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 the purpose front-loaded and the side-effect clarification following. Every sentence contributes essential information with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully describes all parameters and annotations cover safety, the description is sufficient. It communicates the core function and return type, though it does not detail output formatting, which is acceptable for a pure calculation tool without an output schema.
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?
All six parameters are fully described in the input schema (100% coverage). The description does not add parameter-specific details, but the schema already provides comprehensive descriptions for each parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with the verb 'Calculate' and the resource 'fluid CSS clamp() expression', scoping it to responsive sizing between viewport widths. It distinguishes itself from sibling tools by emphasizing pure calculation and no storage, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool — for generating a CSS clamp() between two viewport widths — and explicitly states it is a pure calculation. It does not name alternatives or exclusions, but the context is sufficiently clear to differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate tints and shades for a base color (lighter/darker steps) with hex values.
| Name | Required | Description | Default |
|---|---|---|---|
| hex | Yes | Base color in hex, rgb(), or hsl(). | |
| step | No | Step percentage (default 10). | |
| limit | No | Cap on tints/shades (default fills to ~100%). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds the detail of outputting hex values and lighter/darker steps, which is useful but does not disclose nuances like default step behavior or output format. This is adequate but not rich 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?
The description is a single sentence of 14 words, starts with the action verb, and avoids any fluff. Every word contributes to the core meaning, making it highly concise 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?
The tool has only 3 parameters, all documented, and no output schema. The description mentions 'with hex values' but does not specify the exact return format (e.g., array, object). Given the simplicity and annotation coverage, it is acceptable but leaves some ambiguity about output structure.
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 each parameter (hex, step, limit) already having a clear description. The tool description does not add any extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Generate' and clearly identifies the resource: tints and shades for a base color, with lighter/darker steps and hex values. This distinguishes it from siblings like get_palette or extract_colors, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or that get_palette might be more suitable for full palettes. Given the sibling tools, the lack of differentiation leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for one font family by slug: styles, weights, axes, license, subsets and download/CSS URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Family slug, e.g. 'inter', 'playfair-display'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent; the description adds value by enumerating the returned metadata fields (styles, weights, axes, license, subsets, download/CSS URLs), giving agents concrete expectations of the response. It does not cover error behavior, but the annotations satisfy the safety profile.
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 concise sentence that leads with the verb and resource, then enumerates contents efficiently. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param), strong annotations, and a description that explicitly lists the return value categories, the description is complete for an agent to successfully invoke and interpret results. No output schema exists, but the description compensates adequately.
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 'slug' parameter is fully described in the schema with an example. The description reinforces 'by slug' but adds no additional syntax, constraints, or formatting details beyond what the schema already provides, so the baseline of 3 applies.
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 retrieves full metadata for a single font family by slug, listing specific content areas (styles, weights, axes, license, subsets, URLs). This distinguishes it from sibling tools like get_font_files or get_font_download_url, which target narrower subsets.
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 usage context is implied: you need a font slug and want comprehensive metadata. However, it does not explicitly mention when to prefer this over search_fonts or when to use the more specific sibling tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the direct ZIP download URL for a font family (all styles + a ready fonts.css). Does NOT download — hand the URL to the user or fetch it separately.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Family slug, e.g. 'inter'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description complements this by explicitly stating the tool does NOT download the file, only returns the URL. This adds behavioral context beyond the annotations, though it does not mention error handling or invalid slugs.
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 no wasted words; the first sentence states the core function, and the second clarifies the non-downloading behavior. It is front-loaded with the purpose and remains highly concise.
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 tool with one parameter and strong annotations, the description covers the return value, contents of the ZIP, and the distinction between returning and downloading. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'slug' parameter with an example ('inter'), and the description references 'font family' but does not add extra meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 applies.
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 returns a direct ZIP download URL for a font family, using a specific verb ('Return') and resource. It also distinguishes from sibling tools by noting it does not download and includes a ready fonts.css, differentiating it from get_font_files or get_fonts_css.
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 tool is used when the user needs a download link rather than actual file content, advising to hand the URL to the user or fetch separately. It does not explicitly name alternatives, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every font file (weight/italic/format + direct woff2/ttf URL) for a family — handy for building custom @font-face rules.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Family slug, e.g. 'inter'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it lists every file (exhaustive), includes weight/italic/format details, and direct URLs. This goes beyond the annotations and helps set expectations for the returned data, despite lacking error or edge-case behavior.
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, information-dense sentence that front-loads the main action and resource, then adds the use case. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description is complete enough: it explains what is returned (font files with weight/italic/format and URLs) and why you'd use it (custom @font-face rules). It does not specify the response structure (e.g., JSON array), but that is a minor gap given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'slug' with an example 'inter'. The tool description does not add further parameter semantics beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource 'every font file' for a family, including the key attributes (weight/italic/format + direct woff2/ttf URL). This clearly distinguishes it from sibling tools like get_font_download_url or get_fonts_css, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'handy for building custom @font-face rules.' This implies when to use the tool (when you need all font files for a family rather than a single URL or a full CSS stylesheet). It does not explicitly list exclusions or alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ready-to-use @font-face CSS for a family spec (Google-Fonts-compatible), e.g. "inter:wght@400,700" or a variable range "inter:wght@300..900". Returns CSS text.
| Name | Required | Description | Default |
|---|---|---|---|
| family | Yes | Family spec, e.g. "inter:wght@400,700" or "inter:wght@300..900". | |
| display | No | font-display value (default swap). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints. The description adds that the tool returns CSS text and explains the family spec format, providing useful context beyond the annotations. 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?
Single, front-loaded sentence with examples and return type, no filler. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with read-only annotations, the description covers purpose, input format, and output type. Without an output schema, specifying 'Returns CSS text' provides adequate completion.
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% for both parameters. The description provides examples that mirror the schema descriptions, adding little new meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates @font-face CSS from a family spec, with specific verb 'Generate' and resource 'CSS'. It includes concrete examples distinguishing it from sibling tools that download fonts or files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it's for creating CSS-ready font-face rules from a Google-Fonts-compatible spec. However, it does not explicitly mention alternatives or when not to use this tool, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one color palette by id: its colors (hex), name/derived title, mood, harmony, temperature and tags.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Palette id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds useful behavior: it discloses the specific palette attributes returned, including the nuance of 'name/derived title' (a fallback naming behavior). This exceeds annotation context and explains what the tool yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with actionable verb ('Get'), clear resource ('one color palette by id'), and a compact list of returned fields. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and no output schema, the description adequately covers the return contract by listing all palette attributes (colors, name/derived title, mood, harmony, temperature, tags). This compensates for the absent output schema and makes the tool self-explanatory.
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 already fully documents the only parameter `id` with a description, achieving 100% schema coverage. The description adds no semantic detail beyond referencing retrieval by id, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets one palette by ID and enumerates the exact returned fields (colors hex, name/derived title, mood, harmony, temperature, tags), making its specific purpose clear and distinct from sibling tools like search_palettes (which finds palettes) and get_color_shades (which works from a color).
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 usage context is implied: use when you have a specific palette ID and need its full details. However, it does not explicitly contrast with search_palettes or state when not to use this tool, leaving the agent to infer the distinction from the phrase 'by id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one SCSS mixin by id: full source, parameters and usage example.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Mixin id (kebab-case), e.g. 'centerer', 'media-breakpoint-up'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral context by detailing exactly what the response includes (source, parameters, usage example), which is valuable given the absence of an output 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 a single sentence that front-loads the action and resource, then succinctly lists return contents. Every phrase earns its place, with no redundant or filler information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, single-parameter tool with robust annotations, the description is complete. It tells the agent what the tool does, what input is needed, and what output to expect, which is sufficient for selection and invocation without an output schema.
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 fully documents the single 'id' parameter with format (kebab-case) and examples. The description only restates that lookup is by id, adding minimal meaning beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('SCSS mixin'), and the scope ('by id'), while also specifying the return content (full source, parameters, usage example). This distinguishes it from sibling tools like list_scss_mixins, which serve a different 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 clearly implies usage when a specific mixin id is known and details are needed, contrasting with listing all mixins via list_scss_mixins. However, it does not explicitly mention when not to use it or name alternatives, leaving the guidance slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available code converters with their from/to ids and per-converter option schemas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable context beyond the annotations by specifying that the returned list includes from/to ids and option schemas, which gives the agent an idea of the response content in the absence of an output 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 a single, concise sentence that leads with the action verb 'List' and packs essential information (resource, metadata content) without any fluff. Every word contributes to the meaning.
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 tool with no parameters and no output schema, the description provides sufficient detail about what the tool returns (from/to ids and option schemas). The annotations cover safety and idempotence, making the overall context 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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because there are none, but it does mention per-converter option schemas, which are relevant to the converters themselves. This is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('available code converters') and the exact information provided (from/to ids and per-converter option schemas). This distinguishes it from sibling tools like convert_code, which performs conversions, and other list tools like list_scss_mixins, which target different domains.
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 makes the context clear: use this tool to enumerate code converters with their metadata. It does not explicitly mention when not to use it or point to alternatives, but the purpose is straightforward enough that no exclusion guidance is needed. A score of 4 is appropriate for clear context without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the SCSS mixin catalog (id, title, short description), optionally filtered by group or search.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | e.g. Bootstrap, Project, Pattern, Placeholder. | |
| fields | No | Detail level (default summary). | |
| search | No | Fuzzy substring across id/title/short/desc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds useful context about what the catalog contains (id, title, short description), which is not present in the schema. It does not discuss pagination or limits, but for a simple catalog list this is sufficient.
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 sentence that is direct and front-loaded. It conveys the purpose and key options without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return fields (id, title, short description), which is sufficient for a simple listing tool. The optional 'fields' parameter is described in the schema, so the description need not duplicate it, but the full output details are not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description briefly mentions 'filtered by group or search' but adds no meaning beyond what the schema provides. This meets the baseline for full 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 uses a specific verb 'List' and clearly identifies the resource as the 'SCSS mixin catalog', including the output fields (id, title, short description). This distinguishes it from the sibling get_scss_mixin tool, which is likely for retrieving a single mixin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for browsing the mixin catalog, optionally filtered by group or search. It does not explicitly mention when to use an alternative like get_scss_mixin, but the listing purpose is obvious and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available SVG optimization presets and what each one does.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, side-effect-free operation. The description adds little beyond what the annotations and name convey: it says the tool lists presets and their purposes, but does not describe return structure (e.g., array of objects) or whether the list is static or dynamic. With annotations covering the safety profile, no additional context is strictly needed, so a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action ('List'), the subject ('SVG optimization presets'), and the outcome ('what each one does'). There is zero redundancy or irrelevant detail, making it highly 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 simple, parameterless list tool, the description is nearly complete. It clearly states what the tool returns. A minor gap is that it does not explicitly connect to optimize_svg (the likely consumer of these presets) or indicate the output format, but given the output schema absence and the tool's simplicity, 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?
The tool has zero parameters, and the schema is an empty object. Per the rubric, a 0-parameter tool receives a baseline of 4 because there are no parameter semantics to clarify. The description's mention of 'available' presets is a minor addition, but no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'the available SVG optimization presets' plus what each does. This unambiguously distinguishes it from sibling tools like optimize_svg (which performs optimization) and other list tools (list_code_converters, list_scss_mixins), which target different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention related tools such as optimize_svg or other list_* tools, nor does it state a recommended workflow (e.g., 'use this to see available presets before optimizing'). The usage context is only implied by the tool name, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Minify or beautify JS, CSS, HTML, SVG, JSON or XML text. Set type=auto to sniff the language. The code is only parsed and re-printed — never executed and never stored. Rate limit: 30 calls/min per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code to transform. | |
| mode | No | Default minify. | |
| type | Yes | Source language, or 'auto' to sniff. | |
| keep_license | No | Preserve /*! ... */ license comments when minifying. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral context: the code is never executed or stored, and there is a rate limit of 30 calls/min per IP. This addresses potential safety and usage concerns, exceeding what annotations alone convey.
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 and front-loaded with the core purpose, followed by a safety guarantee and rate limit in a second sentence. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, 100% schema coverage, and no output schema, the description covers the essential aspects: supported formats, operation modes, language detection, and non-execution/storage guarantees. It omits details about the return format, but that is implicitly the transformed code, 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 coverage is 100%, so the schema already explains all parameters. The description adds minimal semantic value beyond highlighting type=auto for sniffing, but does not explain mode defaults or keep_license behavior. This is acceptable but does not elevate above baseline.
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 minifies or beautifies text in specific formats (JS, CSS, HTML, SVG, JSON, XML), using a specific verb and resource. It distinguishes itself from siblings like convert_code by explicitly listing supported languages and 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 provides clear context on when to use the tool by describing the transform operations and the type=auto option for sniffing. It does not explicitly mention alternatives or exclusions, but the context is sufficient to infer typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the closest human-readable name for one or more colors. Pass a single hex or several comma-separated (e.g. "#3b82f6,#000,#ff7f50"); returns each input with its nearest color name, the reference hex, an exact-match flag and the perceptual distance.
| Name | Required | Description | Default |
|---|---|---|---|
| hex | Yes | A hex color, or several comma-separated (e.g. "#3b82f6,#000,#ff7f50"). Up to 100 at once. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, which describe the safety profile. The description adds useful behavioral context beyond annotations by specifying the return components: nearest color name, reference hex, exact-match flag, and perceptual distance. It also discloses the 'up to 100 at once' limit, which is not in the annotations. This is solid transparency, though it does not discuss error conditions or response format details.
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, well-structured sentence that front-loads the purpose, then provides the input format, example, and output details. Every clause contributes necessary information; there is no wasted text or redundancy. It is concise yet comprehensive.
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 one-parameter tool with no output schema, the description is complete: it explains what the tool does, how to pass input, what the output contains, and operational limits. The annotations cover safety, and the return value breakdown compensates for the lack of an output schema. No important context is missing.
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 parameter 'hex', which already fully describes the format, examples, and limit. The tool description simply repeats this information without adding new semantics. Baseline 3 is correct because the schema does the heavy lifting, and the description adds no additional parameter 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 uses a specific verb and resource: 'Get the closest human-readable name for one or more colors.' It clearly distinguishes the tool's purpose from siblings like extract_colors, get_palette, or check_contrast by focusing on naming colors. The description also provides a direct input example, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context for use: when you have hex colors and need their nearest human-readable names. It gives explicit input format instructions and a usage example, but it does not explicitly mention alternatives or conditions when not to use the tool. This is clear context without exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimize/clean SVG markup (SVGO). Pure markup transformation — nothing is executed or stored. Returns minified SVG plus before/after sizes. Rate limit: 30 calls/min per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| svg | Yes | SVG source. Max 500,000 chars. | |
| preset | No | Optimization preset (default balanced). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint, but the description adds valuable specifics: nothing is executed or stored, minified SVG plus before/after sizes are returned, and there is a 30 calls/min/IP rate limit. This exceeds what annotations alone convey.
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: purpose first, then safety/output/rate limit. No wasted words; each clause provides distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with robust annotations and full schema coverage, the description covers purpose, safety, return value, and rate limiting. It could mention when to choose this over sibling tools, but that gap is captured in usage_guidelines; overall the tool is well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with svg and preset each having descriptions and preset also having an enum with default. The description adds no parameter-specific semantics (e.g., preset behavior or input constraints), so it does not need to compensate; 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 opens with 'Optimize/clean SVG markup (SVGO)', a specific verb+resource pair that clearly identifies a markup optimization tool. This distinguishes it from siblings like svg_to_datauri (format conversion) and minify_code (general minification).
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 does not explicitly name alternatives or provide when-to-use/when-not-to-use guidance. 'Pure markup transformation — nothing is executed or stored' implies a safe-use context, but the agent must infer when optimize_svg is preferred over minify_code or svg_to_datauri.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify which font is used in an image. Powered by our OWN CNN embedding model, trained on the jinero font catalog — it matches fonts by visual shape/style, so it needs NO OCR and NO text (works for Latin and Cyrillic). Send a tight crop of one line of text as either image_url (public URL) or image_base64 (base64/data-URI, e.g. a local screenshot). The image is processed in memory and deleted immediately — never stored. Returns the most visually similar font families with scores. Typically 0.3-1.7 s (an OCR-assisted rerank of top candidates engages when retrieval is uncertain). Rate limit: 5 calls/min per IP (model inference is compute-heavy).
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Number of font matches to return (3–20, default 8). | |
| image_url | No | Public URL of an image — a tight crop of one line of text. Provide either this or image_base64. Recognition is by visual shape (no OCR/text needed); Latin & Cyrillic supported. | |
| image_base64 | No | Base64-encoded image (raw base64 or a data:image/...;base64 URI), max 8 MB decoded — use this to send a local file/screenshot without hosting it. Provide either this or image_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though readOnlyHint=true already establishes a safe read, the description adds substantial behavioral context beyond the annotations: the image is "processed in memory and deleted immediately — never stored," internal reranking behavior ("OCR-assisted rerank of top candidates engages when retrieval is uncertain"), latency (0.3–1.7s), and the model's training source (jinero font catalog). This richly explains what the tool does behind the scenes.
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 front-loaded with the primary purpose and then efficiently covers model details, input format, privacy, output, and performance in sequence. Every sentence serves a purpose — from "trained on the jinero font catalog" (explaining coverage) to "rate limit: 5 calls/min per IP (model inference is compute-heavy)" (setting expectations). No filler or redundant phrases despite the technical density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and moderate complexity (ML inference, two mutually exclusive input modes, rate limiting), the description is remarkably complete. It covers the what (font identification), how (visual matching, no OCR), input preparation (tight crop, one line, Latin/Cyrillic), privacy (no storage), output (visually similar fonts with scores), operational constraints (latency, rate limits), and expectations under uncertainty (reranking behavior).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal marginal value over the schema since the schema already defines parameter constraints (range 3–20, mutual exclusivity of image_url/image_base64, max 8MB). The description's only added value is the crop/quality guidance, but this doesn't meaningfully extend beyond what the schema already communicates.
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?
"Identify which font is used in an image" is a specific verb+resource statement that clearly distinguishes it from siblings like search_fonts or get_font (which imply catalog/name-based lookups). The addition of "needs NO OCR and no text" further delineates it from text-based alternatives, making the tool's unique niche explicit.
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?
Provides clear, operational guidance: "tight crop of one line of text" via either image_url or image_base64, notes Latin/Cyrillic support, and rate limits (5 calls/min). It gives clear context on how to use, but falls short of the explicit when-not-to-use or alternative-naming that merits a 5 (e.g., it never references the sibling search_fonts to contrast with text-based search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the free font catalog by name, category, style tags, language coverage, variable/monospace flags and style count. Returns a paginated list of families.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Fuzzy name match. | |
| page | No | Page number. | |
| sort | No | Sort direction. | |
| langs | No | Comma-separated language codes, e.g. 'latin,cyrillic' — ALL must be supported. | |
| order | No | Sort field, default 'likes'. | |
| style | No | Comma-separated style tags, e.g. 'handwriting,condensed' — ALL must match. One of: handwriting, script, display, slab, rounded, condensed, expanded, stencil, pixel, blackletter, outline, retro. | |
| category | No | Comma-separated categories, e.g. 'serif,sans'. | |
| per_page | No | Results per page (default 24). | |
| variable | No | Only variable fonts. | |
| monospace | No | Only monospace fonts. | |
| styles_max | No | Maximum number of styles. | |
| styles_min | No | Minimum number of styles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds context about the catalog being free and the return being paginated, which is useful. However, it does not explain how filters combine across different parameters (e.g., AND vs OR) or any edge cases like pagination defaults, though some of that is in the schema descriptions. 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 short sentences. The first sentence states the action and the search dimensions, and the second states the return type. There is no wasted wording, and the most important information (what it searches) 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?
For a complex search tool with 12 optional parameters, the description is reasonably complete given the rich schema and annotations. It states the return type (paginated families) and the catalog scope (free). It does not explicitly mention that all filters are optional and combinable, nor does it detail cross-parameter AND semantics, but these are common for search tools and partially covered by schema descriptions for langs and style.
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%, and each parameter has a clear description. The tool description groups parameters into logical categories (name, category, style tags, etc.) but adds no new meaning beyond what the schema already provides. The baseline of 3 applies because the schema carries the full semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and names the resource 'free font catalog', then enumerates the key filter dimensions (name, category, style tags, language coverage, variable/monospace flags, style count). It clearly distinguishes this from sibling tools like search_palettes or get_font by focusing on catalog search. The return type (paginated list of families) is also stated, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching fonts by various criteria, but it does not explicitly state when to use this tool versus alternatives like search_palettes or get_font. No exclusions or alternative tool references are provided. While the context is clear, the lack of differentiation from sibling search tools leaves the agent to infer the appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the color-palette catalog by name, tone, temperature, mood, harmony, exact color count and tags. Returns a paginated list.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | e.g. pastel, muted, earthy, vibrant, monochrome. | |
| name | No | Fuzzy name match. | |
| page | No | Page number. | |
| tags | No | Tag slugs — ALL must match (AND). | |
| tone | No | Overall tone. | |
| order | No | Sort order (default newest). | |
| harmony | No | e.g. analogous, complementary, triadic, monochromatic, split-complementary, tetradic. | |
| per_page | No | Results per page (default 24). | |
| color_count | No | Exact number of colors. | |
| temperature | No | Color temperature. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and side-effect concerns. The description adds that it returns a paginated list, which is useful, but it does not elaborate on pagination behavior or result content beyond that. It adds some value but does not go far beyond the structured 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 one sentence, front-loaded with the verb 'search' and the resource, and wastes no words. Every part is relevant and it remains fully readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description is on the minimal side. It notes pagination but does not explain how filters combine (e.g., AND vs OR), what fields appear in the result list, or default sorting. Schema covers parameter descriptions, so the agent can infer, but the description could compensate more for the absent output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented meaningfully. The description merely lists the same search dimensions without adding extra syntax, combination logic, or defaults. It provides no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the color-palette catalog by specific criteria (name, tone, temperature, mood, harmony, color count, tags). This distinguishes it from sibling tools like search_fonts (searching fonts) and get_palette (fetching a specific 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 implies use for finding palettes by various attributes but does not explicitly mention when to prefer this over alternatives or provide exclusions. The purpose is clear enough for an agent to infer usage, but it lacks direct guidance such as 'Use for discovery, use get_palette for a known ID.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode an SVG (or fetched image) as a CSS-ready data: URI. Provide either raw svg or a url. Rate limit: 30 calls/min per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| svg | No | Raw SVG markup. Mutually exclusive with url. | |
| url | No | Public image URL the server will fetch. | |
| quotes | No | Quote style for the data URI (default double). | |
| encoding | No | Defaults: utf8 for SVG, base64 for raster. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behaviors. The description adds valuable context by mentioning the rate limit and the ability to fetch external URLs, which goes beyond the schema. 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 sentences, front-loaded with the core purpose, then provides input options and rate limit. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with full schema coverage and no output schema, the description sufficiently covers purpose, input methods, and a critical constraint (rate limit). It does not elaborate on default behaviors, but the schema handles those.
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 all parameters descriptively, so the baseline is 3. The description reinforces mutual exclusivity between svg and url, but does not add deeper semantic meaning or defaults beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encodes an SVG or fetched image into a CSS-ready data URI, which is specific and actionable. It distinguishes from siblings like optimize_svg by focusing on encoding rather than optimization.
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 producing data URIs but does not explicitly compare with alternatives or state when not to use it. It provides the two input modes (svg or url) but lacks guidance on selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
generate_clampget_scss_mixinlist_code_converterslist_scss_mixinslist_svg_presetsoptimize_svgsvg_to_datauriextract_colors3 fields changedInput schema / properties / image_base64Added value: +{
+ "description": "Base64-encoded image (raw base64 or a data:image/...;base64 URI), max 10 MB decoded — use this to send a local file/screenshot without hosting it. Provide either this or image_url.",
+ "type": "string"
+}Input schema / properties / image_url / descriptionPrevious value: -"Public URL of the image to pull the palette from."New value: +"Public URL of the image to pull the palette from. Provide either this or image_base64."Input schema / requiredRemoved value: -[
- "image_url"
-]recognize_font2 fields changedInput schema / properties / image_base64Added value: +{
+ "description": "Base64-encoded image (raw base64 or a data:image/...;base64 URI), max 8 MB decoded — use this to send a local file/screenshot without hosting it. Provide either this or image_url.",
+ "type": "string"
+}Input schema / properties / image_url / descriptionPrevious value: -"Public URL of an image — a tight crop of one line of text. Recognition is by visual shape (no OCR/text needed); Latin & Cyrillic supported."New value: +"Public URL of an image — a tight crop of one line of text. Provide either this or image_base64. Recognition is by visual shape (no OCR/text needed); Latin & Cyrillic supported."list_code_convertersrecognize_fontextract_colorsname_coloroptimize_svgsvg_to_dataurisearch_fonts1 field changedInput schema / properties / styleAdded value: +{
+ "description": "Comma-separated style tags, e.g. 'handwriting,condensed' — ALL must match. One of: handwriting, script, display, slab, rounded, condensed, expanded, stencil, pixel, blackletter, outline, retro.",
+ "type": "string"
+}check_contrastconvert_codedetect_codeget_color_shadesget_fontget_font_download_urlget_font_filesget_fonts_cssget_palettelist_code_convertersminify_codeoptimize_svgsearch_fontssearch_palettessvg_to_datauriClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Curated design references for AI — real CSS values, typography specs, and color palettes.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Design intelligence for coding agents: audits, design systems, and a taste profile agents consult.
Turn any live website into brand colors, fonts, design tokens, SVGs, Lottie and paste-ready code.
Add one secure layer between your agents and this server.
Each tool targets a distinct operation within the color, font, or code utility domains. Descriptions clearly differentiate retrieval, search, and action tools, so an agent can reliably select the right one without ambiguity.
All names use snake_case and are readable, but there's a mix of direct verb_noun patterns (check_contrast, extract_colors) and a get_ prefix for retrieval tools (get_font, get_palette). The inconsistency is minor and the pattern remains predictable overall.
15 tools is at the upper end of the well-scoped range, but each tool serves a clear, distinct purpose across three focused domains (fonts, colors, code). No tool feels redundant or unnecessary for the server's mission.
The server provides a comprehensive lifecycle for its domains: font search, metadata, file access, CSS generation, and image recognition; color extraction, naming, shading, contrast checking, and palette search; and code detection, conversion, and minification. No obvious gaps exist.
