Get prediction market profile and track record for a wallet.
Returns the prediction score (0-100), win/loss record, volume, ROI,
score breakdown, and recent market events.
Args:
address: Prediction market wallet address (0x-prefixed, 42 chars)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Prediction market wallet address (0x-prefixed, 42 chars) |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Input schema / properties / address / descriptionAdded value: +"Prediction market wallet address (0x-prefixed, 42 chars)"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes this is a safe read, so the description only needs to add context. It does add the content of the result (score, win/loss, volume, ROI, breakdown, recent events), but repeats what the output schema likely already declares and says nothing about freshness, caching, or behavior for unknown wallets.
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?
Front-loaded summary sentence followed by a return-value list and one arg line; no filler. The Args block is redundant with the schema, which keeps it from a 5.
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 documented parameter, readOnly annotations, and an output schema covering the return shape, the description is sufficient to invoke it correctly. Only the routing against mt_prediction_leaderboard 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?
There is one parameter with 100% schema description coverage, and the description restates that same address text verbatim. Nothing extra is added, but the schema already carries the meaning, 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?
States a specific verb and resource: 'Get prediction market profile and track record for a wallet.' An agent can tell this is a per-wallet lookup. It does not distinguish itself from the closest sibling, mt_prediction_leaderboard, which likely also returns prediction-market data.
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 by the parameter: pass an address to get that wallet's profile. There is no explicit when-to-use, no exclusion, and no pointer to mt_prediction_leaderboard or mt_prediction_link for the other prediction-market queries.
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.