Get one tool's full score breakdown, component history, and recent real health checks from Wicked Registry.
Works unauthenticated via x402, or with a free-tier key set via
REGISTRY_API_KEY.
Args:
tool_id: The tool's Wicked Registry id, from registry_search_tools
or registry_featured_tools.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses two authentication paths (x402 payment flow or free-tier key) that an agent must resolve before calling. It does not cover rate limits, pricing details of x402, or error behavior, leaving some gaps for an unannotated tool.
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?
Purpose is front-loaded in the first sentence, auth behavior second, parameter provenance third. Sized appropriately for a one-parameter tool with a small amount of prose padding around the Args block.
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?
An output schema exists, so return contents needn't be spelled out; the description still names the main components returned. Auth, parameter source, and resource scope are all covered, leaving only minor operational details (rate limits, failure modes) unstated.
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's 0% coverage means the description must supply meaning, and it does: tool_id is defined as the Wicked Registry id and its provenance is given (registry_search_tools / registry_featured_tools). That is exactly the context needed to supply a valid value.
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 ('Get') and resource ('one tool's full score breakdown, component history, and recent real health checks from Wicked Registry'), and it distinguishes the tool from the sibling registry_search_tools and registry_featured_tools by scoping it to a single tool id.
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 tells the agent where tool_id comes from (registry_search_tools or registry_featured_tools) and how the call authenticates (x402 unauthenticated vs REGISTRY_API_KEY free tier). It does not explicitly say when to prefer this over registry_tool_badge or other registry siblings, but the single-tool detail use case is clear.
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.