338 traditional colors (188 Japanese, plus Chinese, Korean, Indian, Western and more) with HEX/RGB and sources. Look up a color by name, find the nearest traditional colors to a HEX code (CIEDE2000), and list by culture or hue.
Scored across 4 tools
Each tool has a distinct purpose: find_color does name-based lookup, list_colors does filtered enumeration, list_cultures enumerates the dataset's cultures, and nearest_colors does hex-based reverse lookup. There is no meaningful overlap between them, so an agent can select correctly without hesitation.
All names are snake_case with a verb/noun shape (find_color, list_colors, list_cultures), which is highly predictable. nearest_colors breaks the verb_noun pattern slightly with an adjective, but it remains readable and consistent in style.
Four tools is well-scoped for a color reference dataset: one lookup, one enumeration, one metadata, one reverse-search. Each tool clearly earns its place with no redundancy.
The surface covers the key workflows (name lookup, filtering, culture metadata, nearest-color reverse lookup) for the stated domain. Minor gaps like RGB/nearest-by-value input or bulk detail retrieval are absent but can be worked around via hex conversion.
Look up traditional colors by name and get hex/RGB with sources. Accepts Japanese kanji (浅葱色), reading in hiragana or katakana (あさぎいろ), English (Asagi, Prussian Blue), with or without 色. Exact name matches come first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Color name. | |
| culture | No | Culture id from list_cultures (e.g. japanese, chinese, western) or its name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description still adds real behavior: exact name matches rank first, and results include source attribution. It omits what happens on no match and how limit/culture affect results.
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 tight sentences with the core action and output front-loaded, followed by input formats and ranking rule. Every sentence carries information; nothing is padded.
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 and three parameters, the description covers what is returned (hex/RGB plus sources), accepted input languages, and result ordering. Missing only edge-case behavior such as empty results and how culture/limit shape the response.
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 67%, and the query parameter's schema text is only 'Color name.' The description compensates well by enumerating accepted scripts and the optional 色 suffix. Limit and culture are not elaborated, but culture's schema description already points to list_cultures.
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?
States a specific verb and resource ('look up traditional colors by name') and names the return payload ('hex/RGB with sources'). This implicitly separates it from list_colors and nearest_colors, though no sibling is called out by name.
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?
Accepted input forms (kanji, kana, English, optional 色) imply when the tool applies, but there is no explicit when-to-use, when-not-to-use, or routing to nearest_colors for fuzzy/approximate lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List colors filtered by culture, category (e.g. 青系, 赤系), era (e.g. 平安, 江戸) or tag. At most 50 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| era | No | Part of the era text, e.g. 平安, 江戸, 19世紀. | |
| tag | No | ||
| limit | No | ||
| offset | No | ||
| culture | No | Culture id from list_cultures (e.g. japanese, chinese, western) or its name. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds the 'at most 50 per call' cap, which is useful behavioral context, but says nothing about pagination behavior or ordering beyond that.
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 tightly packed sentences with the filter options front-loaded and the result cap immediately after. No redundant or filler 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 zero-required-parameter browsing tool with no output schema, the description covers the main filter axes and the result limit but omits any note on tag/offset semantics or what a returned color record contains. Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate. It supplies concrete examples for category (青系, 赤系) and era (平安, 江戸) and names culture, but leaves tag and offset entirely unexplained in both schema and description, leaving half the parameters opaque.
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 a specific verb (List) and resource (colors) plus the filterable dimensions, so the intent is unambiguous. It does not, however, distinguish this browsing tool from the sibling find_color or nearest_colors, leaving the agent to infer the boundary.
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?
Listing the filter dimensions (culture, category, era, tag) implies usage as a browsing/filtering tool, but there is no explicit when-to-use guidance and no comparison to alternatives like find_color. The agent must infer that this is the enumeration path rather than a search path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the cultures covered, with color counts and categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the description's added value is on the return side: it discloses that results include color counts and categories, which matters because there is no output schema. It stops short of describing ordering, completeness guarantees, or result size.
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?
A single short sentence with zero waste, front-loaded with the action and resource and trailing only the genuinely informative payload details. Nothing could be removed without losing content.
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 no-argument, read-only enumeration with no output schema, the description covers what is returned (cultures plus color counts and categories) and the annotations cover safety and idempotency. The only minor gap is that it never explicitly says it requires no arguments or how the color counts relate to the color-focused sibling tools.
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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly implies no input is required, matching the empty properties object with additionalProperties=false.
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?
States a specific verb ('List') and resource ('cultures') and even names the payload contents (color counts and categories), so the agent knows exactly what this returns. Sibling differentiation is unnecessary here since find_color, list_colors and nearest_colors are all color-oriented and cannot be confused with a cultures listing.
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?
Usage is only implied: the zero-parameter signature makes it obvious this enumerates the full set of cultures with no filtering, and no alternative sibling competes for that job. However, there is no explicit when-to-use statement, no mention that it takes no arguments, and no stated relationship to the color tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a hex code, return the closest traditional colors by CIEDE2000 color difference (delta_e). Use it to answer "what is this color called in Japanese tradition?".
| Name | Required | Description | Default |
|---|---|---|---|
| hex | Yes | #RRGGBB or #RGB | |
| limit | No | ||
| culture | No | Culture id from list_cultures (e.g. japanese, chinese, western) or its name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real behavioral value beyond them by disclosing the ranking method (CIEDE2000 delta_e), telling the agent results are deterministically ordered by perceptual distance. It does not mention rate limits or result-shape details, keeping it from a 5.
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 tight sentences: the mechanism is front-loaded and the usage example follows. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but 'return the closest traditional colors' plus the default limit of 5 conveys the shape (a ranked list). What is missing is whether each entry includes a color name, its hex, and delta_e, and how culture falls back when omitted.
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 67%: hex and culture are described in the schema, while limit (default 5, 1-20) is only constrained, not explained. The description hints at culture via the Japanese-tradition example but adds no syntax or semantics beyond what the schema already provides, so baseline 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?
States a specific verb+resource: maps a hex code to the closest named traditional colors, and even names the distance metric (CIEDE2000 / delta_e). This implicitly contrasts with find_color (name-to-hex direction), but no sibling is named explicitly, so it stops short of a 5.
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 quoted example ('what is this color called in Japanese tradition?') gives a concrete usage context, which is better than nothing. However, it never states when NOT to use this tool or that find_color / list_colors are the alternatives for the reverse or enumeration cases.
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.
find_colorlist_colorslist_culturesnearest_colorsEvery UK paint colour, matched across brands by ΔE and priced; palettes, planner projects, trends.
Convert colours between hex, RGB, HSL, OKLCH and CMYK, and compute harmonies.
18 color tools: OKLCH, WCAG and APCA contrast fixes, palettes, gradients, color blindness, tokens.
Color Pizza MCP — names hex colors using human-friendly color-name lists.
Add one secure layer between your agents and this server.