x402-triadic
Triadic: Generate a triadic (3-color) color harmony from a hue. Provide hue (0-360); returns three hues 120 degrees apart. 🆓 5 free trial calls per signed wallet
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hue | No |
Triadic: Generate a triadic (3-color) color harmony from a hue. Provide hue (0-360); returns three hues 120 degrees apart. 🆓 5 free trial calls per signed wallet
| Name | Required | Description | Default |
|---|---|---|---|
| hue | No |
Changes observed during successful MCP inspections.
Input schema / properties / hue / descriptionRemoved value: -"Hue to process"Input schema / properties / hueAdded value: +{
+ "description": "Hue to process",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does real work: it discloses the return value (three hues), the underlying rule (120 degrees apart), and the commercial model ('5 free trial calls per signed wallet'), which is useful cost/limit context. It omits what happens when hue is out of range or non-numeric, which is the main remaining behavioral gap.
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 short sentences, front-loaded with the core action and output, with no wasted wording. The pricing/trial line is slightly promotional but still conveys actionable quota 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 one-parameter pure function with no output schema and no annotations, the description covers what it does, what goes in, and what comes out, which is nearly everything an agent needs. The only gap is the string-vs-number input format and out-of-range handling.
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 0%, so the description must compensate, and it does by documenting the single parameter's valid range (0-360) and its meaning (hue). However, the schema types hue as a string while the description implies a numeric degree value, leaving a format ambiguity the agent must guess at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Generate a triadic (3-color) color harmony from a hue') and states the exact output shape ('three hues 120 degrees apart'), which cleanly separates it from siblings like x402-complementary, x402-split-complementary, and x402-tetradic.
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 gives clear selection context by naming the harmony type and the required input, so an agent can tell this is the tool for 3-color 120-degree harmonies. It stops short of explicitly naming alternatives or stating when not to use it, so it falls just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.