x402-crypto-brief
Crypto Brief: Crypto brief in one call: coin prices (optional), fear-and-greed index and gas. Provide optional coins list (default bitcoin,ethereum).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No |
Crypto Brief: Crypto brief in one call: coin prices (optional), fear-and-greed index and gas. Provide optional coins list (default bitcoin,ethereum).
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No |
Changes observed during successful MCP inspections.
Input schema / properties / coins / descriptionRemoved value: -"Coins to process"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the content the tool returns (prices, fear-and-greed, gas), which is meaningful behavioral context, but it says nothing about auth requirements, rate limits, or whether the call is a read-only data fetch.
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 sentence, front-loaded with the returned data and the parameter guidance. Slight redundancy in restating the title ('Crypto Brief: Crypto brief in one call') but nothing is wasted beyond that.
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 one optional parameter, no annotations, and no output schema, the description covers the essentials: what data comes back, that the coins argument is optional, and its default. Absent an output schema, it correctly enumerates the returned components.
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% and the schema only declares coins as a bare string, so the description must compensate. It does: it identifies the parameter as optional, indicates it is a list, and supplies the default value 'bitcoin,ethereum' — information absent from the schema entirely.
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 exactly what the tool returns: coin prices, fear-and-greed index, and gas, framed as a single-call bundle. That scope clearly separates it from single-purpose siblings like x402-crypto-price, x402-fear-greed, and x402-gas, though it never names those alternatives.
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 phrase 'in one call' implies the intended use case is bundling the three data points rather than fetching them individually, and the default coins list is useful. However, it never explicitly says when to prefer this over the granular sibling tools or states any prerequisites, so usage is only implied.
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.