Realizability-gated Hyperliquid & Polymarket wallet copyability, risk & smart-money signals.
Scored across 4 tools
Each tool targets a distinct entity and action: wallet lookup, Hyperliquid traders, Polymarket traders, and Hyperliquid vaults. There is no functional overlap.
All tool names follow a consistent verb_noun pattern in snake_case (analyze_wallet, find_copyable_traders, find_pm_traders, find_vaults), making them predictable and easy to understand.
With 4 tools, the server is well-scoped for its purpose of wallet analysis and copy trading signals. Each tool provides a distinct and necessary function.
The tools cover core operations: wallet lookup, listing copyable traders, Polymarket research, and vault analysis. A minor gap is the lack of detailed follow-up on individual traders or vaults beyond the list, but the main workflows are supported.
Look up a specific wallet's worth-copying read (copyability / Realizability Score / risk) by address. venue 'hl' (Hyperliquid) or 'pm' (Polymarket).
| Name | Required | Description | Default |
|---|---|---|---|
| venue | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns score types and is a lookup (read-only), but no details on side effects, auth, or rate limits. Adequate given no annotations.
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?
Single sentence, front-loaded with purpose, no wasted words.
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?
Covers key inputs and output concept, but could mention that return is a score. Good for a simple tool.
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?
Adds meaning to 'venue' by explaining enum values (Hyperliquid, Polymarket). 'address' is not explained beyond schema. With 0% schema coverage, partial compensation.
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?
Clearly states it looks up a wallet's score (copyability/Realizability Score/risk) by address, with venue options. Differentiates from sibling tools that find lists of traders.
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?
Implies use for single wallet analysis vs siblings for finding traders, but no explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Hyperliquid traders that are actually copyable AND realizable for a follower, pre-gated by copy-lag decay, de-leverage, and alpha-vs-beta (NOT raw leaderboard PnL). Returns copyability tier, Realizability Score 0-100, risk grade, PnL, return, copy-lag tolerance. Use when you need vetted copy candidates, not noisy 'top trader' lists.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows, <=100 | |
| min_realizability | No | minimum Realizability Score 0-100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the output fields and gating criteria, implying a read-only listing operation, but does not explicitly state non-destructiveness, authentication needs, or rate limits. It is adequate but not thorough.
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?
The description is under 60 words, front-loads key differentiators, and every sentence adds value. It is efficient and well-structured.
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?
Given the tool's simplicity (2 params, no output schema), the description fully explains what the tool does, what it returns, and when to use it. It is complete enough for an agent to select and invoke correctly.
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 100% with both parameters described. The description does not add new parameter-level detail beyond the schema; it restates the realizability score range. Per guidelines, baseline 3 is appropriate as extra semantic value is marginal.
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 clearly states the tool lists Hyperliquid traders that are 'copyable and realizable', using specific gating criteria like copy-lag decay, de-leverage, and alpha-vs-beta, distinguishing it from raw leaderboard PnL lists. It also specifies the returned fields.
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 description explicitly advises use when needing 'vetted copy candidates, not noisy top trader lists', providing a clear use case. It does not explicitly mention alternatives or when-not-to-use scenarios beyond this, but it contextually implies the tool is for filtered, actionable results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Polymarket wallets with copyability classification (edge-family), PnL, edge-per-dollar, drawdown, category, invisible-maker volume. PM is structurally near-uncopyable; useful for edge-family research.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 lists the output fields, which is good, but it does not mention the 'limit' parameter, authentication needs, rate limits, or pagination. For a query tool, the absence of parameter discussion is a notable 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?
Two sentences, front-loaded with the main action and output spec. No redundant information; every sentence adds value.
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?
The description lists the output fields, helping with output understanding since there is no output schema. However, it omits the limit parameter and does not fully explain the context for using this tool versus siblings. The mention of 'edge-family research' provides some context, but it is incomplete.
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% because the description does not mention the 'limit' parameter at all. The parameter is optional but its purpose and usage are completely undocumented. The description should at least indicate that limit controls the number of results.
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 clearly states the verb 'List' and the resource 'Polymarket wallets', and specifies the metrics returned (copyability classification, PnL, edge-per-dollar, drawdown, category, volume). It distinguishes from sibling tools by noting that PM is structurally near-uncopyable, contrasting with find_copyable_traders.
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 description mentions 'useful for edge-family research,' suggesting usage context. It also hints at differentiation from find_copyable_traders by stating PM is near-uncopyable. However, it does not explicitly state when not to use or name alternatives, leaving some gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Hyperliquid vaults ranked by allocation-worthiness (Sharpe, drawdown, operator skin-in-game, concentration, fees). Vaults are deposit products. Returns verdict, risk score, CAGR, max drawdown, TVL, APR.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. Discloses a read operation with ranking and multiple return fields. Does not explain limit parameter behavior, pagination, or data freshness. Adequate but not thorough.
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 sentences, front-loaded with purpose. Efficient but could be more structured with separated purpose and output details.
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 simple list tool with one parameter and no output schema, description covers ranking criteria and return fields. Missing limit semantics and output format, but overall adequate given low complexity.
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 has one integer parameter 'limit' without description. Schema coverage is 0%. Description does not mention 'limit', providing no added meaning. Parameters are left entirely unexplained.
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?
Description specifies verb 'List', resource 'Hyperliquid vaults', ranking criteria ('allocation-worthiness' with specific metrics), and return fields. Clearly distinguishes from sibling tools (wallet, copyable traders, PM traders).
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?
Implied usage for evaluating vault allocation decisions based on ranking criteria. No explicit when-not or alternatives, but siblings are distinct enough that context is clear.
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.
analyze_walletfind_copyable_tradersfind_pm_tradersfind_vaultsLive Polymarket data for agents: markets, insider-scored whale trades, leaderboards, wallet P&L
Classify Polymarket wallets as human or bot, score their trading edge, read open positions.
Polymarket + Hyperliquid + macro for AI agents. 38 tools, signal backtest, SSE streaming. Free tier.
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
