Coinversaa Pulse

Official

by Coinversaa

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.11.0
Disambiguation3/5
Many tools have similar purposes (e.g., multiple cohort tools, multiple OI tools, multiple outcome detail tools). While prefixes help organize, the high number of overlapping tools makes it difficult for an agent to choose the correct one without deep understanding of nuances.
Naming Consistency4/5
Tools follow a consistent snake_case pattern with clear prefixes (hip4_, list_, live_, market_, pulse_). However, within groups the verb-noun order varies (e.g., hip4_daily_volume vs list_asset), and there is a deprecated alias (pulse_market_overview) that breaks consistency.
Tool Count2/5
55 tools is excessive for a single server. While the domain is broad, many tools are redundant or overly granular (e.g., multiple cohort history tools). This volume increases cognitive load and latency for agents.
Completeness4/5
Covers a wide range of Hyperliquid data: assets, markets, positions, liquidations, outcomes, trader analytics, and cohorts. Minor gaps exist (e.g., raw trade history per market), but the surface is largely comprehensive for trading analysis.
Average 4/5 across 53 of 55 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'includes outcome/question metadata when available' but does not state whether the operation is read-only, what happens if no data is available, or any rate limits. This is insufficient for a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous text. The core action and result are front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should provide more details on the return structure. It only vaguely mentions 'outcome/question metadata' without specifying fields or format. The description is not complete enough for an agent to understand what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description's mention of 'recent window' maps to the hours parameter, but it adds no additional semantic meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the most active HIP-4 outcomes ranked by fill count over a recent window, including metadata. It distinguishes the tool's focus on activity ranking from sibling tools like hip4_outcomes or hip4_outcome, but could be more specific about what 'activity' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. For example, it doesn't contrast with hip4_outcomes or hip4_outcome_recent_trades.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the tool returns 'real-time' positions, but does not mention any other behavioral traits such as authentication requirements, rate limits, response format, or what happens when no positions exist. The minimal disclosure is insufficient for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the core action. Every word earns its place. The example immediately clarifies the kind of cohorts available. Ideal conciseness for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description omits details about the output (no output schema), the 'useToonFormat' parameter, and the 'limit' parameter. It does not explain how 'tierType' interacts with 'tier'. For a tool with 4 parameters and no annotations, the description is too sparse to be fully self-contained, leaving the agent to infer too much from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by giving real-world examples ('apex', 'heavyweights') that map to the 'tier' enum, but it does not explain the 'tierType' parameter or the 'limit' default. It does not complement the schema's own parameter descriptions significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves live positions for a specific trader cohort, using a concrete verb ('see what...is holding') and resource ('positions'). The example with 'apex' and 'heavyweights' adds clarity. However, it does not explicitly differentiate from sibling tools like 'pulse_cohort_recent_positions' or 'pulse_cohort_summary', missing an opportunity to stand out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it, nor does it reference sibling tools that could serve related purposes (e.g., 'pulse_cohort_trades' for trade history, 'pulse_cohort_bias' for directional bias). The example is illustrative but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'recently' and 'real-time alpha' but does not disclose idempotency, rate limits, data freshness, pagination behavior, or whether the tool is read-only. A mutation or heavy query with no behavioral cues increases risk for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus an example) and front-loaded with the purpose. Every sentence contributes (purpose, example, value proposition). It could be slightly more structured (e.g., bullet points), but the conciseness is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, pagination, or default behavior of `useToonFormat`. The example helps but leaves significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds no additional meaning beyond the schema; it merely illustrates usage with an example. This is adequate but does not exceed the schema's contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ("See every trade") and the resource ("a specific cohort has made recently"), and provides a concrete example with 'apex (Apex) tier' and 'last hour'. This clearly differentiates from sibling tools like `pulse_cohort_summary` (summary stats) and `pulse_cohort_positions` (positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., `pulse_trader_trades` for individual traders, `pulse_recent_trades` for all trades). There is no mention of when NOT to use it, or scenarios where a different cohort tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the data is historical and hourly, but lacks details on data freshness, error handling, rate limits, or what happens with invalid parameters. The description is too sparse to fully inform the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly packed with essential information: purpose, scope, and constraints. No unnecessary words, and the most critical details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description provides a reasonable overview but falls short in explaining the return format or data structure. It covers the core purpose and constraints but omits details that would help an agent fully understand the tool's output and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it merely restates the filtering options. No new parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'historical hourly open interest snapshots (notional USD)', and mentions per-coin filtering vs global aggregation. It does not explicitly differentiate from sibling tools like live_oi_history, but the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the supported filtering options and the 30-day max range, which gives some context. However, it does not explicitly state when to use this tool over alternatives (e.g., live_oi_history for real-time data), leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that response payloads use legacy slugs (money_printer, leviathan, etc.), which is a behavioral insight. However, it does not mention whether the tool is read-only, idempotent, requires authentication, or has rate limits. Given the simple boolean parameter, the description adds some value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about four sentences, front-loaded with the main purpose and key details. It lists tiers and metrics efficiently, though the parentheses with slashes and underscores are slightly messy. Overall, it is reasonably concise with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's complexity (multiple tiers and metrics), the description covers the main return structure and mentions legacy slugs. However, it omits ordering, pagination, error conditions, and any limits on data returned. For a data query tool, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one boolean parameter 'useToonFormat' already documented. The description adds no additional meaning about the parameter format, behavior, or trade-offs. It mentions legacy slugs but that relates to the response, not the parameter. Baseline 3 is appropriate when schema covers the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function as retrieving behavioral cohort analysis across all tracked wallets on Hyperliquid. It lists the tier categories and metrics returned, distinguishing it from sibling pulse_global_stats by noting that tool should be called first for total wallet count. However, it does not explicitly differentiate from other cohort tools like pulse_cohort_positions or pulse_cohort_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage guideline: 'For the current tracked-wallet total, call pulse_global_stats first.' This implies a prerequisite but does not specify when to use this tool versus other cohort or pulse tools, nor does it mention exclusions or alternative scenarios. The guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only lists returned fields but omits details like pagination, ordering, data freshness, or whether results are limited. This lacks transparency for a listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence adds value—lists purpose, data fields, and usage hint. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should cover typical concerns like result limits or ordering. It mentions 'recently' but relies on the hours parameter for window. Missing details about pagination or completeness. Moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described (hours with default/max, useToonFormat with default). The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active HIP-4 outcome contracts that traded recently, with specific fields returned. It distinguishes from siblings like hip4_outcome (single outcome) and hip4_outcome_recent_trades (trades for a specific outcome).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct usage hint: 'Use when users ask what prediction/outcome markets are active.' This gives clear context, though it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only lists returned fields but does not disclose safety (e.g., read-only), side effects, or authentication needs. It is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence covering key points without unnecessary words, though it could be restructured for improved readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description adequately lists returned fields, though it uses 'including' suggesting possible incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the sole parameter. The tool description adds no further semantic value beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists HIP-4 question metadata and enumerates specific fields (IDs, descriptions, outcomes, etc.), distinguishing it from sibling tools that focus on outcomes or trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus related siblings like hip4_outcome or hip4_outcomes, nor any context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the cohort is defined by 'LAST-30-DAY tier' and that data is 'real-time alpha', but does not disclose key behaviors such as data freshness, pagination, rate limits, or whether the tool is read-only. Critical behavioral traits beyond the input schema are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and uses no filler. Every word adds value, clearly stating the resource, the cohort definition, and the real-time alpha focus. It is an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description explains the cohort definition and intent but does not describe the return format, data fields, or how results are ordered. Given the complexity (5 parameters, many sibling tools), more context about the output would improve completeness. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds context about the cohort definition ('LAST-30-DAY tier') but does not elaborate on parameter semantics beyond what the schema already provides. No additional meaning is added for parameters like limit, since, or useToonFormat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows 'recent trades by a cohort defined by its LAST-30-DAY tier' using specific verbs ('shows') and resources ('trades by cohort'). It distinguishes from sibling tools by emphasizing 'real-time alpha weighted to who is hot NOW, not all-time', making it unique among pulse_cohort_* and pulse_recent_trades tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for real-time alpha from currently-printing wallets, but does not explicitly state when to use it versus alternatives like pulse_cohort_trades or pulse_recent_trades. No 'when not to use' or exclusion criteria are provided, leaving the agent to infer usage from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only mentions filtering criteria but does not disclose read-only behavior, data freshness, side effects, or response format limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and contains no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description adequately explains the filtering dimensions but omits details about output format, pagination, error handling, and result ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions, so baseline is 3. The tool description reinforces the three filtering categories but does not add significant new meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers underrated high-performing traders that are not commonly surfaced. It uses specific verbs ('Discover', 'Filters') and distinguishes from siblings like pulse_leaderboard and pulse_biggest_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding hidden-gem traders, but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses exclusions (settlement, pair-redeem, auction-phase fills) and lists returned fields, but does not state whether the operation is read-only, has auth requirements, or any side effects. This is a moderate effort but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently deliver the purpose, exclusions, and return fields with no waste. The key information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a tool without annotations or output schema: it states exclusions and lists return fields. It lacks information about authentication, rate limits, and output structure details (e.g., array vs. object), but covers the core functionality well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and parameters are well-described in the schema with defaults and constraints. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent real fills for one HIP-4 outcome', providing a specific verb and resource. It excludes settlement, pair-redeem, and auction-phase fills, which distinguishes it from sibling tools like hip4_recent_settlements or hip4_outcome_summary that might include those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only implies its purpose by listing exclusions, but fails to mention when not to use it or suggest superior alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It correctly identifies the tool as read-only (historical retrieval) and describes the output as hourly net-bias snapshots. It lacks details on error cases, rate limits, or data availability guarantees, but for a simple query tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core function, and provides examples efficiently. It is concise without being terse, though it could be slightly more structured (e.g., seperating purpose and usage more clearly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description adequately states the return format (hourly net-bias snapshots). It does not explain how to interpret bias values or mention the default tierType or useToonFormat, but the schema handles those. Overall, it is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds minimal additional meaning beyond the schema (e.g., it implies the 'hours' parameter via 'hourly' and 'over time', but does not explain 'tierType' or 'useToonFormat'). A score of 3 reflects that the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves historical cohort bias data for a specific coin and provides example user queries, making the purpose specific. However, it does not distinguish this tool from the sibling 'pulse_cohort_bias_history', which may serve a similar role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives use cases with natural language queries, e.g., 'were smart-money cohorts accumulating or exiting?', helping agents select when to invoke. It does not, however, mention when not to use it or contrast it with alternatives like 'live_cohort_bias' for current data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds value by stating the data is 'Cached up to 120s' and 'exchange-wide' (no user/workspace filtering). However, it does not mention auth requirements, rate limits, or whether the output is paginated. The caching info is useful but minimal for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence states the core data, the second provides the nickname and caching behavior. Front-loaded, clear, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description is sufficiently complete. It covers the data nature (wallets, match count), time window (last 24h), scope (exchange-wide), and caching. Minor missing details: what 'wallets' means (addresses? usernames?) and whether there is a limit on returned wallets. But overall adequate for a simple metric tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'useToonFormat' is fully described in the input schema). The tool description does not add any extra meaning beyond the schema. Per guidelines, baseline is 3 when coverage is high and description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns distinct wallets that filled perp trades in the last 24h plus total match count, with the nickname 'daily active traders'. It distinguishes itself from sibling tools like 'pulse_global_stats' (aggregate stats) and 'pulse_trader_profile' (individual focus) by specifying exchange-wide scope and a specific metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description only states what it does, without mentioning when it is appropriate, when it is not, or suggesting sibling tools for different use cases (e.g., filtering by trader or using other pulse tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies a read-only operation but does not explicitly state safety, side effects, or rate limits. The key requirement is the only behavioral clue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver purpose, return fields, and a prerequisite. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 parameters and no output schema, but the description leaves ambiguity about the ranking criterion ('recent outcome activity' is vague). Return field types or order are not specified, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning parameters are already well-documented. The description adds no additional parameter-level context beyond the schema, but also does not conflict. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Rank top HIP-4 outcome traders by recent outcome activity' and lists the specific data fields returned. This distinguishes it from sibling tools like hip4_trader_outcomes and hip4_outcome_recent_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear purpose but does not explicitly state when to use this tool versus alternatives like hip4_most_active or hip4_trader_outcomes. The key requirement is noted, but no contextual guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool is read-only ('See what... returns the net long/short bias') and real-time ('RIGHT NOW'), but it does not disclose authentication needs, rate limits, data freshness guarantees, or what happens on missing data. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and includes a helpful example question. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the main purpose and use case. However, it lacks details on possible error conditions, the exact output structure (e.g., list of tiers with bias values), and any limitations. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add details about the parameters beyond what the schema already provides—it mentions the coin symbol and format implicitly via the example, but does not elaborate on valid values for 'useToonFormat' or the structure of the returned bias data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('See what each trader cohort is doing') and clearly identifies the resource (cohort bias on a given coin). It distinguishes from the sibling 'live_cohort_bias_history' by emphasizing 'RIGHT NOW', and provides concrete examples of tiers (Apex, Sharps, Middleweights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a concrete use case question ('are the Sharps traders long or short ETH?') that tells the agent when to invoke this tool. However, it does not explicitly mention when not to use it or contrast it with alternatives like 'live_cohort_bias_history' or 'pulse_cohort_summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool's output (liquidation clusters) but does not disclose frequency of updates, computational cost, or side effects. It implies read-only but lacks explicit behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence defines action and scope; second explains value. Front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not specify the return structure (e.g., list of price levels and amounts). It mentions compact format in parameters but not in description. For a tool with 4 parameters and no output schema, more detail on output would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions that are clear. The description adds context about the heatmap's significance but no additional parameter-specific meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a liquidation heatmap for any coin'), the resource (liquidation clusters across price levels), and differentiates from siblings by claiming unique data. This is specific and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use for identifying support/resistance and squeeze zones but does not explicitly state when to use over alternatives or when not to use. No direct comparison to sibling tools like live_liquidation_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully shoulders the behavioral disclosure burden. It fails to mention any traits like permissions, rate limits, or response format details beyond mentioning 'current mark price'. The parameter useToonFormat implies a compact format but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. First sentence states purpose, second provides symbol format guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain returned data format. It mentions 'compact toon format' implicitly via parameter but does not elaborate. The description is adequate for a simple price check but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value for the symbol parameter by giving examples, but does not mention the useToonFormat parameter or its effect, leaving it to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get current mark price for any trading pair on Hyperliquid', specifying verb and resource. It also provides distinct symbol formats, distinguishing it from sibling tools like list_asset or market_orderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes explicit guidance on symbol formats with examples (standard and builder dex). However, it does not mention when to prefer this tool over siblings like market_orderbook for depth data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only lists output fields but does not disclose behavioral traits such as data freshness, side effects, or pagination limits beyond what is obvious from input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear structure: first states what it does, second lists returns, third provides use case. Concise and front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description enumerates return fields (coin, lifecycles, etc.), adequately covering what to expect. However, it does not explain pagination behavior or format defaults beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (useToonFormat, limit, offset). The description adds no additional meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps per-coin profit pools split into winners vs losers vs net, and the specific use case 'which coins are net wealth creators vs destroyers?' distinguishes it from 50+ sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('which coins are net wealth creators vs destroyers?'), but does not explicitly state when not to use or name alternatives, though the focused question implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It correctly implies a read-only operation and mentions ranking criteria. However, it omits details like whether data is real-time or historical, and does not disclose any side effects. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the function, the second suggests usage. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is functional but incomplete. It does not describe the output structure (e.g., ranked list with coins, trade count, volume) or the data source (e.g., real-time vs. snapshot). This leaves the agent with uncertainty about what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (limit, useToonFormat) with descriptions, achieving 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the most actively traded coins on Hyperliquid, ranked by trade count and volume. This is specific and distinguishes it from sibling tools that focus on different aspects (e.g., pulse_biggest_trades for largest individual trades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use to understand what the market is focused on right now,' providing context for when to use it. However, it does not explicitly differentiate from similar tools like pulse_market_overview or pulse_biggest_trades, leaving the agent to infer the best use case without alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lists return fields but does not disclose behavioral traits like mutations, auth needs, or rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no wasted words. Efficiently communicates purpose and return content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists return fields (metadata, side tokens, fills, wallets, notional USDH, timestamps). Good coverage for a simple tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds no extra meaning beyond what is in the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details for one HIP-4 outcome contract by outcome ID,' specifying the verb, resource, and identifier. It distinguishes from siblings like hip4_outcomes (list) and hip4_outcome_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing details for a specific outcome by ID, but does not provide explicit when-to-use or alternatives. No mention of when not to use or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the returned fields and notes 'winning side when determinable' as a caveat. However, it does not explicitly state the operation is read-only or mention any side effects, rate limits, or data freshness. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists return fields. Extremely concise with no wasted words. Front-loaded with the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a good overview of returned fields but lacks type information or structure details. It covers the core functionality well, but could benefit from a note about data ordering or pagination behavior beyond the limit parameter. Still, it is sufficiently complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (hours, limit, useToonFormat) have descriptions in the schema, covering 100% of parameters. The description adds no new meaning beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent HIP-4 settlements and enumerates the returned fields (outcome ID, settlement time, winning side when determinable, etc.). The verb 'List' and resource 'recent HIP-4 settlements' are specific, and the tool distinguishes itself from siblings like hip4_outcome by focusing on settlement data rather than current outcomes or trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The name implies it's for recent settlements, but without comparing to siblings (e.g., hip4_outcome_recent_trades, hip4_outcome_summary), the agent must infer usage context. Minimal viable guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to explicitly state that the tool is read-only or non-destructive; while 'get' implies a query, agents benefit from explicit safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff, front-loading the core purpose and useful examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return fields (wallet, coin, penalty fee, closed PnL) and covers the main usage context, though it lacks notes on pagination, rate limits, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions; the tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes the tool as getting real liquidation events from the syncer, with specific examples that distinguish it from related tools like live_liquidation_heatmap or live_liquidation_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example queries that indicate appropriate usage scenarios, but does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists return fields but does not comment on idempotency, rate limits, data freshness, or side effects. The tool is read-only, but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, usage guidance, and output summary. No extraneous details, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, and outputs. It lacks explicit return format details but is adequate for an overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one boolean parameter described in schema. The description adds no additional information beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an 'exchange-wide market risk snapshot' and gives example questions ('what looks fragile?', 'which coins are most crowded?'). It distinguishes itself from per-coin risk tools like 'live_coin_risk_snapshot' by emphasizing the overview nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Best for questions like...' which provides clear usage context. It does not explicitly state when not to use or mention alternatives, but the examples are helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as data freshness, rate limits, authentication requirements, or side effects. It only describes the basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core purpose, and contains no unnecessary information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no output schema), the description is largely complete. It could mention that depth is optional and defaults to 10, but this is covered by the schema. Overall, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds no extra meaning beyond the schema's parameter descriptions, which adequately explain symbol, depth, and useToonFormat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'order book (bid/ask depth)', and the scope 'any trading pair on Hyperliquid'. It is specific and distinguishes from sibling tools like market_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: 'Essential for understanding liquidity, spread, and potential support/resistance.' It implies the context but does not explicitly mention when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 not disclose any behavioral traits such as read-only nature, destructive potential, rate limits, or data freshness. The name 'pulse_capital_titans' hints at a query but lacks explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three sentences that front-load the purpose, followed by usage and a note on parameters. Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core functionality, return fields, and filtering. It lacks details on pagination handling and output formatting options beyond the toon format, but overall it's sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds the context that minPnl/minFees act as noise filters, but overall it adds minimal value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding fee-efficient traders based on realized PnL per dollar of fees. It specifies returned fields and distinguishes itself from sibling tools that focus on different metrics like volume or top traders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the use case ('who extracts the most edge per dollar spent on fees?') and explains that minPnl/minFees gates filter out noise. While it doesn't provide when-not-to-use guidance or compare to alternatives, the given directive is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool returns historical data aggregated by day, covering PnL, trade count, and activity. However, it does not mention the compact toon format default (useToonFormat), potential pagination, or any constraints like rate limits or authentication. The core behavior is transparent but lacks depth on response format and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second gives a concrete example of use. Every word is meaningful; there is no redundancy or filler. The structure is front-loaded with the most important information, making it easy for an agent to quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema, yet the description does not explain the return format (e.g., time series structure, fields included, how compact toon format differs from standard JSON). While the example provides a trend context, important details like the role of the 'days' parameter or the default true for 'useToonFormat' are omitted. The description is incomplete for an agent to fully understand the tool's behavior without inspecting the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters in detail. The description adds no further parameter guidance beyond the example referencing 'sharps' tier. It does not explain the meaning of 'days', 'tierType', or 'useToonFormat', or how they affect the output. Given the high schema coverage, a baseline of 3 is appropriate, but the description could have added context on parameter interplay.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('historical performance data for a specific trader cohort'), clearly stating the tool returns day-by-day aggregate PnL, trade count, and activity. It distinguishes from sibling cohort tools like pulse_cohort_summary or pulse_cohort_positions by focusing on historical trends over time, and provides an example usage that grounds the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case ('spot trends like the sharps tier being increasingly bearish over the last month'), which implies when to use this tool. However, it does not explicitly contrast with alternatives (e.g., pulse_cohort_bias_history for bias direction, pulse_cohort_performance_daily for daily metrics) or state when not to use it. The guidance is clear but could be more explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It is a query tool, but the description does not mention that it is read-only, how data freshness is handled, or define key terms like 'lifecycles' or 'wins/losses.' The lack of behavioral detail beyond the purpose leaves the agent guessing about side effects, caching, or definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and a usage hint. No wasted words; every sentence adds value. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and medium complexity, the description lists the returned metrics (lifecycles, wins, losses, etc.) and the cohort definition, which is helpful. However, it lacks details on the output structure, ordering, pagination behavior, and definitions of lifecycles/wins. It is mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the cohort being defined by the last 30 days and the 'per-wallet' nature, but the schema already provides detailed descriptions for all parameters (tier, tierType, limit, offset, useToonFormat). Thus the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns per-wallet lifecycle stats for a cohort defined by a LAST-30-DAY tier, listing specific metrics (lifecycles, wins, losses, etc.). This verb+resource combination is specific and distinguishes it from sibling tools like pulse_cohort_summary (aggregate) or pulse_cohort_positions (positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool for 'position-level analysis of who is currently printing,' which gives clear context. However, it does not explicitly contrast with alternatives (e.g., when to use pulse_cohort_summary instead) or state when not to use it, so some implicit guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals that the tool returns data from 'currently-printing wallets' and filters by 'last-30-day tier', and lists the output fields. This gives a clear indication of what the tool does and its read-only nature. However, it does not mention rate limits, authentication requirements, or whether the output is sorted. The level of detail is good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and output. It is front-loaded with the key idea and avoids filler words. However, it is slightly dense and could benefit from breaking into shorter sentences for readability without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and many siblings, the description provides a good overview of what the tool returns and the cohort-filtering logic. However, it does not mention pagination (limit and offset) or output format options (useToonFormat). These are covered in the schema but the description could hint at them for a complete mental model. The listing of output fields partially compensates for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add new meaning to the parameters beyond the schema, but the schema itself already provides detailed descriptions for all five parameters, including enums and defaults. The description's focus is on output rather than input, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'top closed position lifecycles' for a cohort defined by its 'LAST-30-DAY tier', and explicitly lists the metrics included (entry/exit VWAP, hold duration, realized PnL, fees, liquidation flag). It distinguishes itself from sibling tools like pulse_cohort_positions (which likely returns all positions) and pulse_lifecycles_recent (general lifecycles without cohort filter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving top closed positions for a specific cohort based on tier and recency, but does not provide explicit guidance on when to use this tool versus alternatives such as pulse_cohort_positions or pulse_lifecycles_recent. No exclusions, prerequisites, or caveats are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description lists return fields and implies selection logic, but does not explain how 'giveback' is computed or if tool is read-only. Adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences without fluff, front-loaded purpose and returns. Could be more structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations; description lists returns but omits selection algorithm details, pagination, and giveback definition. Partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% so baseline 3. Description adds no extra meaning about parameters (e.g., minBestMonth, limit).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds traders with a single big winning month then giveback, names return fields, and gives a query example. Distinguished from siblings like pulse_survivors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case 'who had one great month then faded?' provided. No exclusions or alternatives mentioned, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output fields and filtering criteria (minPnl, minCapturePct). No annotations present, so description carries full burden. Could mention default format (useToonFormat) but still provides good behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: 4 sentences, front-loaded with purpose. No redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return fields. Covers main functionality and filtering. Lacks mention of useToonFormat parameter effect on output, but overall sufficient for a paginated list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal context beyond schema (e.g., 'material positions' for minPnl, 'capped at 100' for MFE capture). Not significantly enhancing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds perp positions that exited near the top based on MFE capture percentage. It uses specific verbs like 'Find' and 'Returns', and distinguishes from siblings by focusing on well-timed exits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over related sibling tools (e.g., pulse_recent_closed_positions, pulse_trader_closed_positions). Does not provide context for alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains default/max hours and optional output format, but lacks details on data accuracy, caching, or response structure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, no redundancy. The most critical information (what, purpose, defaults) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema, the description adequately covers purpose, usage, and parameter semantics. It does not discuss the response format or pagination, but that is partially compensated by the compact structure and default values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that omitting 'coin' returns global OI, and that 'hours' defaults to 7 days (168 hours) with a 30-day max. This goes beyond the schema's bare parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves historical open interest data per coin or globally. The use cases are described (accumulation/distribution, conviction shifts). However, it does not explicitly distinguish from sibling tools like market_historical_oi or live_official_oi, though the 'historical' aspect implies a distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear best-use case: identifying market sentiment via OI changes. Also mentions default and max duration. Does not explicitly advise against use in other contexts or list alternatives, but the guidance is effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the tool queries cumulative realized PnL data and returns specific fields. It does not explicitly state that this is a read-only operation with no side effects, which would be beneficial for transparency. However, the description accurately describes the behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. The first sentence states the purpose and output; the second gives a usage hint. There is no extraneous text. The informal tone ('blew up', 'rekt') is acceptable and aids clarity. It is slightly less formal than ideal but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values. It states: 'Returns wallet, trough depth, and current cumulative PnL.' This covers the main outputs. It does not mention pagination or ordering, but those are handled by input parameters (limit, offset). For a list query tool, the description is sufficiently complete given the parameter richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter. The schema descriptions are already clear (e.g., 'Trough must be at least this deep (negative)'). The tool's description does not enhance parameter understanding further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding wallets that have experienced a deep trough in cumulative realized PnL and are still underwater. It specifies the output fields (wallet, trough depth, current cumulative PnL). The verb 'find' and resource 'wallets' with the specific condition distinguish it from siblings like pulse_survivors, which likely finds the opposite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'who got rekt and stayed rekt?' This implies when to use the tool. However, it does not explicitly mention when not to use it or name alternative tools (like pulse_survivors). The context is sufficient for an AI to understand typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only query but does not explicitly state behavioral traits like idempotency, permissions, or side effects. Lists what it returns but not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the key information. No wasted words, efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists metrics but lacks full output structure details. It covers purpose and parameters adequately but could be more complete about expected results and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters. The tool description adds overall context but does not provide new parameter-specific details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool compares 2-5 wallets side-by-side using lifecycle summaries, lists specific metrics, and gives an example use case. It distinguishes from siblings by specifying multiple-wallet comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for head-to-head trader comparison', providing clear context. Does not mention when not to use or alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the parameters and their defaults, but does not mention if the operation is read-only, any rate limits, pagination behavior (beyond limit), or response format details (beyond useToonFormat).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy, efficiently conveys core purpose and key features. Well front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and key parameters, it lacks details on output structure (e.g., what fields are returned per trader). Given no output schema and 5 parameters, the description is adequate but not comprehensive for an agent to fully understand behavior without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description lists sort options and filters, which overlaps with schema descriptions (e.g., 'day/week/month/allTime'). It adds no new semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a ranked trader leaderboard, enumerates sort criteria (PnL, win rate, volume, score, risk-adjusted returns) and filters (time period, minimum trades). It distinguishes from sibling tools like pulse_trader_profile by focusing on rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to find the best traders on Hyperliquid,' giving a clear context for use. However, it does not mention when not to use it or suggest alternatives among the many pulse_ sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only GET operation and lists returned data, but lacks details on side effects, rate limits, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first packs all key info (what, metrics), second gives usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (2 optional params, no nested objects), and description covers output contents and use case. With no output schema, description adequately fulfills completeness needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. Description adds no additional parameter semantics beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns 'daily HIP-4 volume trajectory' with specific metrics (fills, unique trades, wallets, contracts, notional). This clearly distinguishes it from sibling tools like hip4_outcome or hip4_top_traders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage hint: 'Use for outcome-market activity trends.' While it does not explicitly mention when not to use or name alternatives, the context among siblings is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It mentions authentication requirement (key tier). But lacks disclosure of side effects (none expected), rate limits, or data mutability. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose and output fields. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists output fields and key requirement, compensating for missing output schema. Lacks details on error handling, pagination, or sorting. Could mention response format (implied by useToonFormat param). Overall good but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description does not add new meaning to input parameters beyond schema's own descriptions. However, it does list return fields which aids overall understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'one wallet's HIP-4 outcome history', listing concrete fields. Clearly distinguishes from siblings like hip4_outcomes (likely all outcomes) and hip4_outcome (single outcome).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisite 'Requires a Starter-or-higher key' and implies usage context (specific wallet). Does not explicitly compare to siblings or provide when-not-to-use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the output but does not explicitly state whether it is a read-only operation, or mention authorization, rate limits, or data freshness. For a data retrieval tool, the behavioral traits are reasonably implied, but additional details would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose and best-use context, the second lists the key outputs. No wasted words, and the most important information is front-loaded. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 optional parameters, no required parameters, and no output schema. The description covers the high-level return fields and filtering options. It does not address pagination, limits, or performance for large time windows, but for a summary tool, the given information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context by explaining the return format (compact toon format vs standard JSON) and listing the summary components, which helps understand the parameter effects. However, it does not significantly extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get an aggregated liquidation summary over a time window' and lists specific outputs (event count, penalty fees, closed PnL, per-coin rollups, liquidation timeline). It also claims it's 'the best liquidation tool for summaries, rankings, and trend analysis,' which distinguishes it from siblings like live_liquidation_heatmap and live_recent_liquidations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating it is 'best for summaries, rankings, and trend analysis.' However, it does not explicitly mention when not to use it (e.g., for individual liquidation events) or suggest alternative tools. This is still adequate for guiding an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full weight. It describes a read operation without side effects but lacks details on error behavior, data freshness, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words: first states the action and resource, second lists returned fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose and returned fields but omits structure details like the toon format vs standard JSON, which is relevant to the useToonFormat parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no new information beyond what the schema already provides, meeting but not exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all open positions for a wallet address, specifying the data shown (entries, sizes, unrealized PnL, leverage), which distinguishes it from siblings like pulse_trader_closed_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (for any wallet address) but does not explicitly mention alternatives or when not to use it among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool covers all of Hyperliquid and the criteria for biggest trades, but lacks details on data freshness, rate limits, or performance characteristics. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise, front-loaded sentences. It efficiently conveys purpose and usage without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description provides enough context to understand what the tool does and when to use it. It briefly mentions the return format (toon format) via the schema, but could be more explicit about output structure. Overall, it is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a minor elaboration on the type parameter (market sentiment) and the use case, but does not significantly enhance the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the biggest winning or losing trades across all of Hyperliquid, with explicit examples using type='wins' or 'losses'. It distinguishes itself from sibling pulse_* tools by focusing on extreme trades for market sentiment and narrative analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool—market sentiment and narrative analysis—and explains the type parameter's role. It does not explicitly state when not to use or mention alternatives, but the context is clear enough for the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool returns historical daily stats and has a range limit, but it does not disclose authentication requirements, rate limits, potential side effects (none expected), or data volume considerations. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and returns, and contains no redundant information. Every sentence adds value, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains the return values (PnL, volume, trade counts, active trader counts per tier) and the time scope. It is fairly complete, though it could clarify the definition of 'cohorts' or 'tiers' and whether the data is aggregated per day. Still, it covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description adds context by noting the max range as 30 days, which relates to the 'since' parameter, but it does not provide additional semantic detail beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get historical daily performance statistics') and specifies the resource ('all trader cohorts') and the returned metrics (PnL, volume, trade counts, active trader counts per tier). It distinguishes itself from sibling tools like pulse_cohort_summary or pulse_cohort_positions by focusing on daily performance across all cohorts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'track the consistency and profitability of different groups over time.' It also mentions a constraint (max range 30 days). However, it does not explicitly list when not to use this tool or offer specific alternatives among siblings, though the context is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains that the tool returns 'live positions' and 'currently-printing wallets,' which implies a read-only, real-time query. However, it does not disclose details such as rate limits, data freshness, or error handling. The description adds value by explaining the cohort definition (last-30-day tier) but could be more explicit about behavioral traits like caching or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose in the first sentence and adding a critical differentiator in the second. Every word earns its place; there is no redundancy or fluff. It is concise and well-structured for an AI agent to quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 well-documented parameters and no output schema, the description sufficiently explains what the tool does and its key differentiator from the all-time sibling. It is complete enough for a user to decide when to use it. However, it could be slightly improved by explicitly naming the sibling `pulse_cohort_positions` and mentioning that the output is a list of positions (though that is implied by 'positions held').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level information beyond what the schema already provides. The schema's parameter descriptions are detailed (e.g., enum values, defaults, meaning), so no additional context is needed from the description. The tool's description focuses on the overall purpose, not individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves live positions for a cohort defined by its last-30-day tier, not lifetime tier. It explicitly distinguishes from the sibling `pulse_cohort_positions` (all-time) by noting it catches regime changes the all-time version misses. The verb 'surfaces' paired with 'positions' and 'wallets' makes the resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when the user wants positions based on recent 30-day behavior rather than lifetime tier. It contrasts with the all-time version by mentioning regime changes. However, it does not explicitly list alternatives or state when not to use this tool, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well. It discloses the gross both-sides convention ('Gross both-sides convention (matches HyperTracker/hl.eco headlines; halve for one-sided OI)') and a caching behavior ('Cached up to 120s'). These are critical for interpreting the data correctly. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the data returned, explaining a key behavioral detail, and offering usage guidance. It is front-loaded with the primary purpose and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema. The description covers the data scope (exchange-wide OI by DEX, long/short split), the reporting convention (gross both-sides), and caching behavior. It does not describe the output structure, but the agent can infer it from the context. It is nearly complete for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'useToonFormat' with 100% description coverage, so the baseline is 3. The description does not add any additional meaning or context about the parameter beyond what the schema provides. It could have explained what 'toon format' entails, but it did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current open interest for the whole exchange with long/short split by DEX. It uses specific terms ('current open interest', 'by dex', 'long/short notional split') and addresses the resource exactly. However, it does not explicitly differentiate from siblings like 'market_historical_oi' or 'live_official_oi', which could cause confusion for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use for 'what's the OI on Hyperliquid / on xyz?', market-size questions, and long-vs-short balance checks.' This gives clear context for when to invoke the tool. It does not mention when not to use it or list alternatives, but the provided guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that data is by UTC hour and lists output fields, but omits details like date range scope, data recency, or if aggregation is over all time. The optional boolean parameter is mentioned but behaviorally the tool seems read-only; no destructive hints are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and output fields, the second gives usage guidance. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains the return structure (per-hour data with listed metrics). It does not specify the exact JSON format or whether all 24 hours are always present, but it is fairly complete for a simple heatmap tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter, and the tool description repeats the schema description without adding extra meaning. Thus, the description adds no value beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a global PnL heatmap by UTC hour, listing the specific fields returned (lifecycle count, total PnL, avg PnL, wins, losses). This distinguishes it from sibling tools that focus on other aspects like trade outcomes or volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a use case: 'Use for 'what time of day is most profitable to close?' / session-bias analysis.' This tells the agent when to use the tool. It does not explicitly mention when not to use it or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists the returned fields (coin, lifecycles, liquidations, etc.) and the metric used, but does not disclose whether the tool is read-only, whether it requires authentication, or any side effects. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the purpose and immediately state the output fields. Every word adds value; no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return fields. The parameters are well-documented in the schema. However, it does not mention the sorting order (presumably descending by liquidation rate), which is a minor gap. Overall, it is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with all parameters having descriptions and defaults. The description does not add any additional meaning beyond what the schema provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool identifies coins with the highest per-lifecycle liquidation rate, which is distinct from sibling tools like pulse_survivors or pulse_hidden_gems. The verb 'Find' and explicit use case 'which coins blow people up most often?' leave no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides a clear usage scenario ('Use for...'), but does not mention when not to use it or list alternative tools. With many sibling tools, adding exclusions or comparisons would be beneficial, but the provided context is sufficient for basic use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it returns positions, entry/MAE/exit prices, realized PnL, max drawdown %. Implicitly read-only with no side effects. Lacks details on data source or time range but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-loaded with core purpose, then output specifics and filter criteria. No redundant words. Ideal length and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists expected fields. Covers filtering (minPnl, drawdown). Does not specify time range or exchange, but sufficient for a data query tool. Minor gaps prevent 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% descriptions for all 5 parameters. Description adds general context ('material positions', 'bounded drawdowns') but does not significantly extend schema meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Find' and clearly identifies resource as 'biggest survived drawdowns' with explicit criteria (closed perp positions, high MAE, still profitable). Distinct from sibling tools like pulse_anti_survivors and pulse_backstop_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States purpose clearly: find diamond hands winners. Lists output and filters (minPnl, bounded drawdowns). Does not explicitly exclude use cases or name alternatives, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the main behavior (profitable month count over 90 days) and return fields, but omits details on pagination behavior, sorting order, or edge cases like no results. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core function, then output fields, then use case. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the time window, return fields, and key parameter (minMonths). Without an output schema, it provides essential return information. However, it could mention pagination (limit/offset) and sorting to be fully complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description reinforces the meaning of minMonths but does not add significant new semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding consistently profitable wallets based on profitable months. It uses specific verbs and resources ('Find consistently profitable wallets') and distinguishes from siblings by focusing on multi-month consistency rather than single-month luck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a use-case hint ('who is consistently good, not just lucky once?'), which guides the agent on when to use this tool. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers sorting behavior and real-time scope. Lacks details on edge cases (e.g., empty results) or limitations, but adequate for simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Front-loaded with key action and result. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, description explains sorting, purpose, and timeframe. Could mention response format or pagination, but covers essential context for tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds minimal extra meaning beyond the schema. Implies timeframe via 'last N minutes/hours' but does not enrich parameter understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get', resource 'biggest trades on Hyperliquid', and specifics like sorting by absolute PnL and timeframe. Differentiates from siblings by focusing on 'biggest trades' and real-time activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests usage context: 'Use this to see what's happening right now on the exchange.' Does not provide when-not-to-use or alternatives, but context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output fields but does not mention if it is read-only, any permissions needed, or data freshness. This is adequate but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first succinctly describes function and outputs, the second gives a usage example. No redundant language. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and no annotations, the description is fairly complete. It explains what is returned and when to use it. Lacks details on time range or data limits, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter already documented. The description does not add any information about the parameter beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool splits PnL by trading style (HFT, swing, holder) bucketed by lifecycle hold duration, and lists the returned metrics. The usage example 'do scalpers or swing traders make more money on Hyperliquid?' makes the purpose concrete and distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to compare profitability across trading styles. It does not mention alternatives or when not to use, but the stated usage is clear and contextually sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return fields (PnL, trade count, win rate, volume) but omits data freshness, performance, or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, example questions, return fields. No redundant information, front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately lists return fields. Could specify result format (list) but sufficient for agent to understand tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds example values for coin but no other semantic enhancement beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'get the top traders for a specific coin' with examples (BTC, SOL), clearly differentiating from general leaderboard siblings like pulse_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example questions ('who are the best BTC traders?') implying usage context, but lacks explicit when-not-to-use or alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates the tool returns data (implied read-only) but does not disclose behavioral traits such as data freshness, rate limits, or permissions. The absence of contradiction with annotations is neutral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that state the purpose, list return fields, and give a usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately explains the tool's output and purpose. It could mention ranking criteria or time frame, but overall covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described in schema). The description does not add new meaning beyond the schema for the three parameters (useToonFormat, limit, offset), so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds wallets that profit from liquidating forced closes, lists specific return fields, and provides a concrete use case ('who is the biggest backstop/liquidation player?'). This distinguishes it from sibling tools like pulse_backstop_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct use case for the tool, but does not explicitly mention when to avoid using it or suggest alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the return fields but does not mention data freshness, pagination, rate limits, or any limitations. For a tool returning daily data, it would be helpful to know the time range covered (e.g., last 30 days) or if it requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first sentence states purpose and resource, second lists returned fields, third gives usage guidance. No fluff, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stats tool with 2 well-described parameters and no output schema, the description is mostly complete. It explains what is returned and when to use. However, it could be improved by mentioning the structure of the returned data (e.g., an array of daily objects) or any limits like number of days returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for 2 parameters. The description adds value by listing the return fields (daily PnL, trade count, win rate, volume) which are not in the schema, helping the agent understand what the tool outputs. The parameter descriptions in schema are adequate, and the description does not repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'day-by-day performance breakdown for any trader', and lists the returned fields (daily PnL, trade count, win rate, volume). This distinguishes it from siblings like pulse_trader_performance (which likely provides aggregate stats) and pulse_trader_trades (which lists individual trades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage context: 'Use for deep due diligence and identifying consistency patterns.' However, it does not explicitly state when not to use this tool or compare it to alternatives, such as when to use pulse_trader_performance instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output data (comparison metrics) but does not discuss side effects, data freshness, access restrictions, or how trend direction is computed. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no wasted words. It front-loads the purpose and provides immediate use context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two well-documented parameters and no output schema, the description is largely complete. It explains the return data (30-day vs all-time) and the trend direction. Minor omissions include the address format requirement (covered in schema) and an explicit statement about the return format being JSON-like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it does not mention the parameters or their roles. The schema already adequately describes address and useToonFormat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get performance comparison'), specifies the resource ('a trader'), and details the output fields (30-day vs all-time PnL, trade count, win rate, trend direction). It distinguishes itself from sibling tools like pulse_trader_profile and pulse_trader_daily_stats by focusing on comparative performance over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to evaluate if a trader is currently hot or cooling off.' While it doesn't explicitly list when not to use or mention alternatives, the context from sibling tools makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It transparently explains the attribution undercount relative to ledger revenue, the legacy slug format, the 'untracked' handling for missing wallets, and the Pro tier requirement. It also describes the output composition (largest cohort first, with specific fields). While it doesn't mention error handling or rate limits, the description provides substantial behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes value: it covers purpose, tier semantics, output fields, limitations, and usage examples in under 100 words. It is front-loaded with the core purpose and then fills in necessary caveats. While long, the complexity of the tool justifies the length; nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return values (largest cohort first, fields included). It covers the tier definitions, the untracked wallet handling, and the attribution caveat with a pointer to dataNotes. It also mentions the Pro tier requirement. It doesn't mention pagination or response size limits, but for this analytical tool the description provides enough for an agent to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters have descriptions in the schema. The description repeats the period options but doesn't add new parameter-specific semantics beyond the schema. It provides context about the tier meaning (lifetime vs 30d) which relates to the output, not the parameters directly. Given high schema coverage, a baseline of 3 is appropriate; the description does not meaningfully enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('split by' tiers), resource ('builder's attributed users'), and details about output fields. It also distinguishes itself from sibling pulse cohort tools by explicitly noting it uses LIFETIME tiers, not the 30d-rolling tiers, which is a key differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit examples of when to use the tool ('is builder X's user base smart money or exit liquidity?' and 'do whales or shrimp pay most of its fees?'). It also implicitly indicates when not to use it by contrasting with pulse cohort tools, though it does not name specific alternative tools or give an exhaustive when-not list. The Pro tier requirement is also mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that data is 'based on attributed fills, which slightly undercount (trigger-order fills — see the response's dataNotes)', explains the output structure (activeUsers denominator, per-row fields including builderName omission when unknown), and mentions the Pro tier requirement. This provides substantial transparency about data quality and response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose, then explains output details, caveats, and use cases. Each sentence earns its place, and the structure moves from 'what' to 'how' to 'why'. It is somewhat long but appropriately detailed for a tool with no output schema, and it remains focused without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain the return values, and it does: it describes activeUsers, per-row fields (builder address, builderName, sharedUsers, share, feesUsd), and notes the dataNotes caveat. It also covers the Pro tier requirement and the compact toon format option. It lacks details on error conditions or pagination, but for a small top-10 result, those are less critical. Overall, it contains everything needed to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes each parameter (builder as fee-receiving address, period enum, useToonFormat default). The description adds only minor contextual detail (e.g., emphasizing builders are 'frontends/bots/dexes') without introducing new parameter semantics. This meets the baseline for full schema coverage but doesn't go beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'top 10 OTHER builders this builder's active users also traded through...', clearly identifying what it does and distinguishing it from builder_leaderboard, builder_profile, and similar siblings. It explicitly names the metric (shared users) and the scope (period), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'who is builder X's closest competitor?' and 'where else does its audience trade?'. It also notes the 'Requires Pro tier' access constraint. While it doesn't explicitly name alternative tools, the use-case framing makes the intended context clear. It could be improved by explicitly stating when NOT to use this tool, but the use cases are specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it does so well. It discloses the undercounting nuance with its root cause (trigger-order stop/TP fills not yet attributed), flags the dataNotes field, explains builderName comes from a curated registry and is omitted when unknown, and states the 404 behavior and tier requirement. The only gaps are minor (no rate-limit or pagination note), which is acceptable given the disclosure depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the body is a dense, single run-on sentence that piles every output field into a comma-separated clause list. A structured enumeration would greatly improve parseability. It carries a lot of information but with poor scannability — the 404 and tier details are buried mid-paragraph, and the use-case sentence comes last. Appropriately sized content, weak organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description thoroughly enumerates the returned data and their semantics: revenue source (on-chain builder-fee ledger), the undercounting caveat and its cause, the dataNotes pointer, the registry fallback, the 404 failure mode, and the tier requirement. Sibling differentiation is handled via the 'overview' framing. Nothing an agent needs to call and interpret this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter (period, builder, topCoins, useToonFormat) already has a solid schema description. The tool description re-states period as '(day/week/month)' which matches the schema enum and adds no new meaning; the feeTenthsBp 'tenths of a basis point' clarification is output-related, not parameter-related. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Single-builder overview for a 0x-hex builder address') and enumerates the exact fields returned (revenue, fee accrual timestamps, fee tokens, fee rate, daily series, top coins, profitable wallets). It distinguishes itself from the builder_* sibling family by framing the output as a per-builder overview, contrasted implicitly with builder_leaderboard (comparative) and builder_fills (transaction-level). No ambiguity about what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides two explicit, concrete use cases ('how is builder X doing?' or 'what do people trade on frontend Y?') plus behavioral constraints (404 for addresses with no revenue, requires Starter tier or higher). However, it never names an alternative sibling or states when NOT to use this tool in favor of builder_leaderboard or builder_traders — the routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It lists the returned fields and mentions the prerequisite, but does not disclose side effects, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that front-loads the purpose and lists fields, but it is slightly long. It is well-structured overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description is fairly complete: it explains what is returned, the prerequisite, and a parameter hint. Minor gaps exist in explaining output format variations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the encoding for side-token coins for the outcomeId parameter, which goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'full HIP-4 summary for one outcome', specifying the fields included. It distinguishes from sibling tools like hip4_outcome by emphasizing the summary across both sides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires a Starter-or-higher key', but does not explicitly contrast with sibling tools or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the deduplication behavior, exclusion of system/protocol accounts, and requires Pro tier. However, it does not describe whether this is a read-only operation, any rate limits, or the response structure beyond a brief list of fields. For a ranking tool with no annotations, this is acceptable but could be more transparent about performance or auth details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured, with the core purpose and key differentiator front-loaded. It could be slightly more efficient by combining the first two sentences, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters, full schema coverage, no output schema, and no nested objects, the description provides enough context for an agent to understand the tool's purpose and differentiate it from siblings. It lacks explicit return value details or examples, but the field list ('entity master address, wallet count, open position count, gross entry notional') partially compensates. The absence of an output schema means the description could be more explicit about the expected JSON structure, but it still rates above average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by contextualizing the parameters implicitly (e.g., providing defaults and ranges that help understand the tool's output window). It does not explicitly detail each parameter beyond the schema, but since the schema already covers them fully, this is a strong baseline. The description's focus on the tool's purpose rather than parameter details is appropriate given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Top entities (owners, NOT wallets) ranked by combined gross open entry notional across all their sub-accounts.' It distinguishes itself from a wallet-level leaderboard by explicitly noting it provides a deduplicated view aggregated at the entity level, which differentiates it from similar sibling tools like 'pulse_leaderboard'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for entity-level, not wallet-level, analysis) and states that system/protocol accounts are excluded. It lacks explicit 'when-not-to-use' guidance or mention of alternatives like 'pulse_leaderboard' for wallet-level data, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly warns that MAE/MFE may be null for very recent closes due to risk backfill lag—an important behavioral trait. No contradictions with missing annotations. It could mention authentication needs or rate limits, but the transparency about data freshness is commendable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 sentences, front-loaded with the core purpose and followed by relevant details (data source, behavior, filters, caveat). It is efficient but could be slightly tighter by merging the lineage note into the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 8 parameters, the description explains the key output fields (MAE/MFE, liquidation flag, optional spot) and the data source. It also clarifies the useToonFormat parameter's impact on output format. This is adequate for an agent to understand what the tool provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the input schema (100% coverage), so baseline is 3. The description does not add significant per-parameter details beyond the schema; it provides overall context about the feed and the caveat about null MAE/MFE, but that is general context rather than parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a global feed of recently closed position lifecycles across all wallets, explicitly distinguishing it as a cross-wallet successor to pulse_recent_closed_positions. The specific verb 'feed' and resource 'closed position lifecycles' combined with the scope 'across ALL wallets' makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is a cross-wallet successor to pulse_recent_closed_positions, providing alternative guidance. It also lists available filters (coin, minNotional, duration range, time window) which imply use cases. However, it does not explicitly state when not to use this tool or describe contraindications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It correctly implies a read-only, data retrieval operation with no side effects, and specifies output fields. However, it does not mention rate limits or any potential latency, but for a simple query tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose and output, second states a requirement. Every word is essential, and the most important information is front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, full schema coverage, and no output schema, the description adequately covers what the tool does and its prerequisites. It does not explain edge cases or interpretation of percentages, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have descriptions. The description adds no extra meaning beyond the schema; it does not elaborate on 'compact toon format' or other details. Baseline 3 is appropriate since the schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures overlap between HIP-4 outcome traders and perp traders over a window, naming the specific counts returned. This distinguishes it from sibling tools that focus on single categories or other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the requirement 'Pro-or-higher key' as a usage constraint, but does not explicitly compare to alternatives or explain when to choose this over similar tools like hip4_outcome_summary. The unique purpose is clear, but guidance on when-not-to-use is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses the operation (join), output fields, and key requirement. It does not detail potential side effects or data freshness, but these are minimal for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph that conveys necessary information without excessive verbosity, though breaking into sections could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description thoroughly covers the join logic, output fields, and usage context, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, and the description does not add additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it joins HIP-4 outcome holders to perp positions and lists the specific return fields, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes use cases (e.g., 'whether outcome traders are already exposed to the same asset') and notes key requirement (Pro-or-higher key), but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It clearly states the function is read-only (no destructive effects), lists exact return components (hourly OI, long/short history, etc.), and implies real-time or historical data aggregation. It does not claim any rate limits or authentication requirements, but this is acceptable given the context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but packs essential information: purpose, usage examples, and return data composition. No extraneous content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description does a good job covering what data is returned. It does not specify return format beyond listing components, but this feels sufficient for a data-retrieval tool. Missing details like pagination or data ordering are minor given the concise nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining what the tool returns (e.g., 'hourly OI, long/short history, cohort rotation'), which gives context for how parameters like 'hours' affect the data scope. However, it doesn't elaborate on 'coin' or 'useToonFormat' beyond the schema, which is acceptable since the schema already has clear descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('historical risk lane for a coin'). It distinguishes itself from siblings by naming multiple data components (hourly OI, long/short history, cohort rotation, etc.) that are unique to this tool. The example questions further clarify its distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example questions to guide when to use this tool ('how did this setup become fragile?' or 'did the Sharps rotate before the move?'). However, it does not explicitly state when not to use it or offer alternative tools. Siblings like live_coin_risk_snapshot or market_historical_oi could be confused, but no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns timestamped mark price, oracle price, and basis percentage over the last 30 days. Although no annotations exist, the description implies a read-only operation, and it clearly states the output structure, leaving no major behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and resource, second provides usage example and return summary. Every word earns its place, no fluff, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three well-documented parameters and no output schema, the description sufficiently explains what is returned (mark price, oracle price, basis percentage) and the time range. It lacks explicit field names for the output, but the examples and parameter descriptions compensate, making it complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with comprehensive parameter descriptions. The main description does not add new meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical mark/oracle dislocation data for a specific coin, using a specific verb 'Get' and resource. It includes example questions to illustrate usage, effectively distinguishing it from sibling tools that focus on other metrics like risk history or cohort bias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context with example questions ('did basis stress or oracle drift show up before liquidations?'). While it does not explicitly state when not to use this tool or list alternatives, the example sufficiently guides the agent to appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states that the tool is read-only ('Get historical...'), is hourly aggregated, has a 30-day max range, and supports per-coin or aggregate. However, it doesn't mention rate limits, data freshness, or any destructive behavior, but for a historical data retrieval tool, the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: first sentence defines the tool's output, second explains its purpose and cohorts, third lists key parameter options. No fluff, all relevant information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate parameter count (5) and simplicity of the tool (historical data retrieval without nested objects), the description covers its purpose, usage, and key behavioral traits well. No output schema is present, but the return value is described at a high level (net long/short notional and counts per tier), which is sufficient for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description's job is to add context. It does so by explaining the coin parameter's dual usage (omit for aggregate, prefix for builder dex), the since parameter's format and max range, and the useToonFormat parameter's default and alternative. This adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving historical hourly bias snapshots for trader cohorts, specifying the return type (net long/short notional and account counts per tier) and mentioning coin or aggregate filtering. This distinguishes it from siblings like 'live_cohort_bias' (current) and 'pulse_cohort_history' (non-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to see how cohorts' positioning shifted over time) and the maximum range (30 days). It doesn't explicitly say when not to use or alternative tools, but the purpose is clear enough that an agent can infer it's for historical hourly bias, not real-time or daily granularity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It lists the return fields (band, wallet count, band PnL, % of tier PnL, tier total wallets), indicating a read-only analysis. It does not mention data freshness, rate limits, or computation details (e.g., how percentile bands are defined), but the core behavior is sufficiently described for a non-mutative tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero wasted words: first sentence defines the tool, second lists return fields, third provides a concrete usage example. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists the return fields and explains the purpose. However, it omits context about the meaning of 'recent' in the cohort, how percentile bands are computed, or any prerequisites (e.g., does the tier need to be populated?). Still, for a focused analysis tool with many siblings, it provides enough context for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter descriptions, covering tier, tierType, and useToonFormat. The tool description does not add additional semantic information about these parameters (e.g., clarifying how tierType affects the cohort selection). Baseline 3 is appropriate since the schema handles the definition; the description adds no extra value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures profit concentration within a recent-tier cohort using percentile bands and PnL shares, with a concrete use case example ('within the hot apex cohort, do a few wallets carry everything?'). This is specific, actionable, and distinguishes the tool from sibling cohort tools that likely provide aggregate stats or positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case example, implying when to use this tool (to analyze concentration in a tier cohort). However, it does not explicitly state when not to use it or compare it to alternatives like pulse_cohort_summary or pulse_market_concentration. The example compensates partially, but explicit exclusions would strengthen it further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses a caching behavior ('Cached up to 120s'), which is important for timeliness expectations. It also describes the return data structure (split gross profits/losses). While it does not explicitly state read-only semantics or authentication needs, the description of a query returning aggregated stats strongly implies a safe read operation, and the provided details are sufficient for the agent's decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences plus a parenthetical about caching. Every word adds value: it defines the scope ('by dex'), enumerates data fields, provides example questions, and notes caching. No fluff. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers essential aspects: purpose, data returned, caching, and usage context. It lacks explicit mention of which exchanges are supported (implied by 'by dex' but not enumerated) and could clarify what 'whole exchange' means. Still, it is largely complete and leaves little ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the single parameter (useToonFormat) with 100% coverage, including default and behavior. The human description does not mention this parameter at all, adding no extra meaning. According to the rubric, when schema coverage > 80%, baseline is 3. The description adds no parameter guidance beyond the schema, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('vitals by dex') and resource ('positions'), and enumerates exact data points: open positions, wallets, 24h flow, closed positions, liquidations, total realized PNL. Example questions ('how many positions open on Hyperliquid?') ground the purpose. It distinguishes from siblings like pulse_global_stats (broader) and market_positions (per-market) by specifying 'exchange-wide' aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when needing exchange-level open positions, wallet counts, and 24h PNL flow. The example questions ('how many positions are open on Hyperliquid?') further guide the agent. However, it does not explicitly state when *not* to use it or mention alternative sibling tools for more granular data, which would elevate the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the output fields (band label, wallet count, band PnL, % of total profits, rank range) and the aggregation structure. No side effects or rate limits are relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two highly informative sentences: first explains what the tool does and returns, second gives a usage scenario. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple analytics tool with one optional parameter, the description is complete: it covers the concept, output fields, and use case. Could mention default format but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter well-documented in the schema. The description adds no further semantics beyond implying output format, but the schema already handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing power-law shape of trader profits with percentile bands and share of total profits. It includes a concrete use case question, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests when to use the tool ('how concentrated is alpha...'). While it doesn't mention when not to use or alternatives, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It correctly identifies that this involves realized PnL on closed positions (mutating? No, it's a read operation) and includes position counts and liquidation flags. However, it doesn't disclose whether pagination applies or what happens if no positions are closed in 24h. Returns are also not described, but with no output schema, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with three informative sentences. The first sentence fronts the core purpose, the second clarifies the time window and differentiation from similar tools, and the third provides a usage example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no nested objects, no output schema), the description is almost complete. It explains the tool's purpose, usage window, and sibling distinction. The only minor omission is a brief note on what happens if no positions are closed (empty result), but this is generally understood.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by implying that both winners and losers are capped by 'limit', and the default and max/min values are in the schema. The description doesn't explicitly mention the parameters, but the schema is sufficient, and the useToonFormat parameter is well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('realized winners AND losers') and clarifies the resource ('wallets ranked by summed realized PnL on positions CLOSED in the last 24h'). It explicitly distinguishes this tool from portfolio leaderboards that rank account value over longer windows, addressing the sibling tool pulse_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool ('who made/lost the most money today?') and distinguishes it from portfolio leaderboards. It does not explicitly list when NOT to use it or provide alternative sibling tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description carries the full burden. It states the data comes from a legacy table, implying potential staleness but does not explicitly declare read-only behavior or other safety characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that cover purpose and deprecation. It is front-loaded with the primary purpose and then provides actionable guidance, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the presence of many sibling tools, the description effectively communicates the tool's role and its relationship to the preferred alternative, making it complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all 7 parameters with meaningful descriptions. The tool-level description does not add additional parameter semantics beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a global feed of recently closed positions across all traders. It also distinguishes itself from the sibling tool pulse_lifecycles_recent by noting it is superseded and why.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer pulse_lifecycles_recent over this tool and explains the reasoning (adds MAE/MFE + spot coverage). This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description conveys the tool is a read-only query that returns specific metrics. Without annotations, it adequately discloses the behavior: it finds wallets based on PnL troughs and recoveries. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three-sentence description front-loads the purpose and is free of redundancy. Every sentence adds value: what it does, what it returns, and a usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with 4 parameters and no output schema, the description is complete enough. It covers purpose, returned fields, and usage context. Minor gap: no mention of data freshness or pagination specifics, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add significant meaning beyond the schema's parameter descriptions; it mentions returned fields but not parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds 'comeback traders' with specific condition: wallets whose cumulative realized PnL hit a deep trough and recovered to positive. It lists returned fields, distinguishing it from siblings like pulse_anti_survivors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct use case: 'Use for who blew up but recovered?' and specifies it uses 'Realized-PnL drawdown only.' Lacks explicit when-not-to-use or alternative tools, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so burden falls on description. Mentions legacy table but does not disclose specific behavioral traits like pagination behavior, performance implications, or data completeness beyond noting it is superseded. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a distinct purpose: purpose and usage guidance. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 parameters but no output schema. Description covers purpose and usage well but lacks description of return format or data structure. Parameter descriptions are detailed, slightly compensating. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 5 parameters. Description does not add additional context beyond schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states verb (history) and resource (closed positions for a wallet), with specific data fields listed. Clearly distinguishes from sibling pulse_trader_lifecycles by labeling itself as legacy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring pulse_trader_lifecycles for better data, and notes backward compatibility reason to keep this tool. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 reveals the tool reads from a legacy table and is superseded, but does not explicitly state side effects or permissions. However, it is implied to be a read-only statistical query. Some behavioral details like error handling or rate limits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the purpose, the second provides usage guidance and context. Efficient, no fluff, and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists the specific stats returned (avg hold duration, win rate, etc.), which sets clear expectations. It also provides context about the legacy table and superseding tool. For a stats tool with good sibling differentiation, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add new parameter semantics beyond what the schema already provides (e.g., 'address' pattern and 'useToonFormat' default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Aggregate stats for a wallet's closed positions' listing specific metrics (avg hold duration, win rate, etc.). It also distinguishes itself from the sibling tool pulse_trader_lifecycle_summary by noting it is superseded and reads from a legacy table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Prefer pulse_trader_lifecycle_summary; kept for backward compatibility.' This tells the agent when to use it vs. the alternative, and explains the reason (legacy vs. corrected table).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation by stating 'fast wallet briefing' but does not explicitly address safety, permissions, or side effects. The description provides moderate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every sentence adds value. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains the return content ('lifecycle summary plus recent top wins and losses'), which is sufficient for a demo/triage tool. It could list specific fields, but the high-level description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The tool description does not add significant meaning beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a fast wallet briefing for demos and agent triage: lifecycle summary plus recent top wins and losses.' It uses a specific verb (get) and resource (wallet briefing), and distinguishes from sibling tools by emphasizing it's for quick triage before deeper analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user wants a quick read on a trader before deciding whether to run deeper lifecycle, drawdown, or token-level analysis,' providing clear context and naming alternatives for deeper analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the 90-day rolling window and enumerates all returned statistics (wins, losses, PnL, hold duration, fees, etc.), but does not explicitly state permissions, rate limits, or that it is a read-only operation, though 'Get' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three well-structured sentences: the first lists outputs, the second links to a sibling tool, and the third gives the use case. It is front-loaded with the main action and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description compensates by listing all output metrics and the rolling window. However, it does not explain the return format (toon vs. JSON), which is left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are fully described in the input schema (coverage 100%), so the baseline is 3. The description adds no additional parameter-level detail beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get a wallet's aggregate position-lifecycle stats' and lists specific metrics (total/closed/open count, wins, losses, liquidations, etc.), clearly distinguishing it from sibling tools like pulse_trader_lifecycles which returns individual lifecycles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use to size up a trader's position-level performance in one call,' providing clear context for when to use. It also notes the shared 90-day window with pulse_trader_lifecycles, but does not explicitly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes the tool as a read operation returning token-level P&L, win rate, and volume. No destructive behavior is implied, and the example clarifies output interpretation. However, it does not mention potential rate limits or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines function and outputs, second provides a usage example. No unnecessary words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately conveys what it does and why. It could mention the return format more explicitly, but the useToonFormat parameter covers that. Sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (address, useToonFormat) well-documented. The description adds no additional meaning beyond the schema, but the schema itself is clear. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource 'token-by-token P&L breakdown for any trader'. It details the metrics (PnL per coin, win rate, volume), distinguishing it from sibling tools that focus on aggregate trader stats or cohort data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use to understand a trader's edge' with a concrete example. It does not explicitly state when not to use or list alternatives, but the purpose is well-defined and the context from siblings implies this is for per-token granularity versus overall performance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explains the output (percentages per closed perp lifecycle) and scope (perp only). It does not mention auth or rate limits, but for a read-only data tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with the core function, followed by use case and constraint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return concept (percentages) and format hint (toon format). It covers the essential context, though it could mention ordering or pagination details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning to parameters like address, limit, offset, or useToonFormat. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('per-position drawdown (MAE) and run-up (MFE) curve'), clearly distinguishing it from sibling tools by stating 'perp-only (spot has no MAE)'. It exactly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use to judge a trader's pain tolerance and exit timing'. It also implies when not to use by stating 'Perp-only (spot has no MAE)', but does not explicitly name alternative tools for spot or other metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains that the tool returns data but does not disclose any side effects, permissions, rate limits, or dependencies. For a read-only operation, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the two modes (global vs per-coin) and mentions historical data. It also hints at output format (toon vs standard). However, it does not describe the exact structure of the response. For a data retrieval tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds meaningful context for all three parameters: coin (examples, prefixed coin builder dex format, omit for global), hours (max 168), and useToonFormat (compact vs standard JSON). This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get long/short ratio data' with a specific verb and resource. It distinguishes between global (no coin) and per-coin scenarios, and optionally includes historical data. This uniquely identifies the tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool with or without the coin parameter, and mentions the optional hours parameter for historical data. While it does not explicitly state when not to use it or compare to siblings, the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: returns 1-minute candles, capped at 12 hours, and mentions the compact toon format option. It adds context beyond the schema, explaining reasoning behind the cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff, front-loading the purpose and immediately following with behavioral guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool without output schema, the description covers purpose, usage, and key behavioral traits thoroughly. It explains what is returned and the available output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions already cover each parameter. The tool description adds overall context (e.g., cap reasoning) but does not enhance individual parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent 1-minute candle history for a market, specifying its use for intraday structure, momentum, and pullback analysis. It distinguishes from sibling tools like market_price or market_historical_oi by focusing on high-frequency minute data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: best for short intraday checks and micro-pullback analysis. It explains the 12-hour cap to prevent excessive data fetching, but does not explicitly mention when not to use or name alternative tools for longer timeframes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions synonym resolution and return fields, but does not state whether the operation is read-only, data freshness, rate limits, or error handling. The tool name suggests read-only, but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus example usage; every sentence earns its place. Information is front-loaded and efficient without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description lists all return fields and usage scenarios, compensating well. For a complex cross-market tool, it provides sufficient context for an agent to correctly select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet description adds value by providing examples for 'canonical' and explaining synonym resolution. It also clarifies default behavior for 'useToonFormat'. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs cross-market aggregation for a single asset, listing specific return fields (per-venue longs/shorts, notional, net bias, etc.) and a cross-venue total. It distinguishes from sibling tools by focusing on cross-venue data for one asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage examples like 'is gold crowded?' and 'total OI on ETH across all venues?', clearly indicating when to use this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses that the tool resolves wallets to entities, aggregates sub-accounts and linked wallets, includes combined open positions, provides a 'verified vs chain' stamp, and notes that vaults appear as named sub-accounts. It also states the requirement for Pro tier. No contradictions exist. The description is rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is front-loaded with the main action. Each sentence adds value, from the resolution purpose to the note about vaults and the Pro tier requirement. However, it is somewhat verbose and could be tightened slightly without losing clarity. Still, it is well-structured and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (resolving wallets to entities with sub-accounts, combined positions, etc.) and the absence of an output schema, the description provides a good overview of what the tool returns. It lists the key components and the two main questions answered. However, it lacks details on the exact output format (beyond toon/JSON), error handling, or what happens for unknown wallets. It is mostly complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the input schema already provides. The address parameter is well-described in the schema, and the useToonFormat parameter is also covered. The tool description focuses on the output and purpose, not on parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Resolve ANY wallet to its owner entity' and lists exactly what it provides (master account, sub-accounts, open positions, verification stamp). It also explicitly answers two questions ('who owns this wallet?' and 'what is this trader's real total book?'), making the purpose unambiguous. This distinguishes it from sibling tools like pulse_trader_profile, which focus on a single trader's stats rather than entity resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: it answers 'who owns this wallet?' and what the trader's total book across all accounts is. It also provides context that per-wallet views undercount multi-account traders, implying this tool is better for those cases. However, it does not explicitly mention alternatives or when not to use it, such as comparing it to pulse_trader_profile or other tools that might also provide ownership info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains what data is returned (traders, trades, volume, PnL, coverage period) and implies a read-only operation. No side effects or restrictions mentioned, but sufficient for a simple data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and data points, second gives usage guidance. No redundant words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one optional boolean parameter, no output schema), the description is complete. It lists all returned data points and provides usage guidance, meeting the needs for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter fully described. The description does not add extra semantics beyond the schema's description of 'useToonFormat'. Baseline 3 as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets global Hyperliquid trading statistics and lists specific data points (total traders, trades, volume, PnL, data coverage period). It distinguishes from sibling tools which focus on specific assets or cohorts, making the global scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly says 'Use this to understand the overall scale of the market', providing clear context. However, it does not explicitly exclude cases or mention sibling alternatives, though the purpose implicitly sets it apart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes a read-only operation ('Returns'), which is consistent with the lack of destructive hints. However, it doesn't mention rate limits, authentication requirements, or that the data is historical/live, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence captures the purpose and key outputs; the second provides a usage case. Perfectly sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, input parameters, and output fields comprehensively. With no output schema, the listed fields (total PnL, trade count, etc.) give a complete picture. The two parameters are well-explained in the schema, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters documented). The description adds context: 'by wallet address' clarifies the address parameter, and 'compact toon format' explains useToonFormat. It also lists the returned fields, enriching the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a full profile for any Hyperliquid trader by wallet address, listing specific metrics (PnL, trade count, win rate, etc.). It distinguishes from sibling trader-specific tools (e.g., pulse_trader_performance) by covering a comprehensive profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies 'due diligence on any wallet' as usage context. While it doesn't explicitly exclude alternatives, the context implicitly directs users to this tool for a broad overview, and the sibling list shows many trader tools from which it could be differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns 'every buy, sell, size, price, and PnL' within a time window, indicating a read operation. However, it does not explicitly state it is non-destructive, has rate limits, or requires authentication. Still, it is fairly transparent given the context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core purpose and immediately conveys what the tool returns and its typical use. The structure is compact and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should cover return structure, error handling, and authentication needs. It mentions return fields (buy, sell, size, price, PnL) but not the JSON shape or pagination. It is adequate for a simple tool but leaves gaps for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by stating 'See exactly what a trader has been doing in the last minutes/hours' and mentioning 'compact toon format', which complements the schema descriptions. It does not deeply explain 'coin' or 'since', but the schema already provides that context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'recent trades for a specific wallet address', and the scope 'per address'. It distinguishes from siblings like 'pulse_recent_trades' by specifying wallet-level introspection and mentions copy-trading and due diligence, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Essential for copy-trading and due diligence', implying when to use it. However, it lacks explicit exclusions or alternatives among the 28 sibling tools, such as when to use 'pulse_recent_trades' instead. This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers. It discloses an attribution undercount (trigger-order fills not included), points to dataNotes for details, explains the 'verified' stamp meaning, lists exact data per row, mentions the curated registry behavior, and states the tier requirement. This is far beyond typical descriptions and gives the agent a realistic expectation of results and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but efficiently packs in essential details without fluff. It leads with the core purpose, then provides supporting context in a logical order. While not a short two-liner, every sentence contributes meaningful information about the data, limitations, or usage—so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers all critical aspects: what data is returned (revenue, trade metrics, deltas, fee rate, builderName), known caveats (undercount), data provenance (verified block), and access requirements (Starter tier). Pagination is in the schema, so nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with 100% description coverage, including defaults and enums, so the schema already provides full parameter semantics. The description adds no extra parameter-level material (it doesn't reference limit, offset, period, or useToonFormat), but since schema coverage is complete, a baseline of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opening sentence names the exact verb and resource: 'Builders (HIP-3 dexes, frontends, bots) ranked by exact revenue from Hyperliquid's on-chain cumulative builder-fee ledger over the requested period.' This fully explains what the tool does and distinguishes it from the many sibling pulse/live/builder tools by targeting the specific topic of builder revenue. The use-cases ('which builders earn the most?' or 'is builder X growing?') add further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the intended queries: 'Use for "which builders earn the most?" or "is builder X growing?".' This gives clear context for when to call it. It doesn't name alternative tools or say when not to use it, but given the tool's unique scope, the guidance is sufficient for an agent to select it over siblings like builder_profile or pulse_leaderboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it delivers: it discloses the sentinel 'latest equity (0 if untracked)', the 'null if untracked' tier behavior, the semantic difference between lifetime and 30d-rolling tiers, and a substantive caveat that attributed fills undercount ledger revenue because trigger-order stop/TP fills are not yet attributed (pointing to response dataNotes). It also notes the Pro tier auth requirement. This is rich, honest behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place and there is no filler, with the primary purpose front-loaded in the first clause. However, it is presented as a single dense run-on paragraph with several parenthetical asides (tier slugs, undercount nuance, dataNotes) that make it harder to scan. Good density but limited structural formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully carries the return-value burden by enumerating each row's fields and clarifying sentinel/null behavior. It covers the coverage gap explicitly (undercount caveat and dataNotes pointer), explains tier semantics, supplies use cases, and states the auth prerequisite. For a 6-parameter, moderately complex tool with no output schema, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all six parameters (sort enum, limit max 500, period enum, builder pattern, useToonFormat default). Baseline is therefore 3. The description adds marginal framing — it ties the sort options ('builder fees paid, volume, or realized PnL') to the scale of an agent's question and clarifies the builder as the fee-receiving address — but it does not substantially go beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Wallets that traded via a builder (0x-hex address) in the window, sortable by builder fees paid, volume, or realized PnL.' It enumerates every returned field per row and explicitly contrasts its lifetime tier semantics against the 30d-rolling tiers used by pulse cohort tools, clearly distinguishing it from the many pulse_* and builder_* siblings. Without opening any schema an agent can tell what this returns and how it differs from builder_leaderboard/builder_fills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Two concrete interrogative use cases are given verbatim: 'who are builder X's biggest fee payers?' and 'are smart-money wallets using this frontend?'. It also explains when the result will differ from pulse cohort tools (lifetime vs 30d tiers, memberships can differ), which is valuable routing context. However, it never names an alternative sibling tool to use instead nor states an explicit when-not-to-use condition, so the guidance stops short of being fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description reveals return fields (OI, wallet count, L/S posture, etc.) implying a read-only operation with no side effects. Could explicitly state it's non-destructive, but the listed outputs strongly suggest a snapshot view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first delivers core purpose, second provides usage triggers and return summary. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 parameters and no output schema, the description adequately covers purpose, usage context, and return fields. Might omit notes on rate limits or authentication, but not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meanings are already fully documented. The description adds no extra detail beyond what the schema provides for either 'coin' or 'useToonFormat'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource (Get risk snapshot) for a single coin. Distinguishes from siblings like live_coin_risk_history and live_risk_overview by specifying 'single coin' and 'current snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists example questions ('is BTC crowded?', etc.) that trigger usage, providing clear when-to-use guidance without needing to reference alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data source, not derived from live positions, returns hourly snapshots with specific fields, and gives time range limits. Lacks details like pagination or empty result behavior, but overall transparent for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence defines tool and source; second sentence gives usage guidance and constraints. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, source, data fields, usage scenarios, and time constraints. Lacks explicit mention of return data structure (array vs object) but is adequate given lack of output schema. Could be more precise but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for all 4 parameters. Description adds overall context but does not significantly enhance parameter semantics beyond what schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states tool returns 'Official per-dex open interest for a coin', sourced from Hyperliquid's Info API, and explicitly says it is 'not derived from live_positions'. It distinguishes from sibling tools like live_oi_history by specifying authoritative source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use when an agent needs venue-reported ground truth, per-dex breakdown, or wants to cross-check computed OI against official numbers.' Also mentions default 7 days and max 30 days, providing clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that the tool returns specific fields (wallet, coin, side, entry VWAP, etc.) and defaults to $10k+ losses. It does not mention rate limits or other behavioral traits, but the description is transparent about the data scope. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three well-structured sentences: first states purpose and scope, second lists return fields, third gives use case and default. No redundant information; every sentence is informative. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description adequately explains what the tool does and the key filter (default loss threshold). It could mention pagination behavior, but that is covered by the schema parameters (offset/limit). Overall, it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default of maxRealizedPnl ("Default returns $10k+ losses") and gives context for the default filter. This clarifies the parameter's meaning beyond the schema description, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the most catastrophic individual liquidations across Hyperliquid — large forced closes ranked by loss.' It specifies the resource (liquidations), action (get), and ranking (by loss). It implicitly distinguishes from siblings like pulse_top_liquidators and live_recent_liquidations by focusing on catastrophic losses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use for "who got wrecked hardest?" and post-mortem analysis.' It does not explicitly state when not to use or compare to alternatives, but the purpose is clear enough to guide selection among sibling tools. A slight improvement would be contrasting with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the return fields (coin, wallet, coin PnL, fees, lifecycle count, rank), indicates it's a read operation (top earners), and explains the effect of perCoinRank. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with front-loaded purpose. No fluff. Every sentence adds value: purpose, parameter behavior, return fields, use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists what is returned. Parameters are well-documented in schema. The description covers the essential behavioral aspects for agent invocation, though it could mention pagination behavior explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-defined. The description adds value by explaining the perCoinRank parameter's behavior (top-N vs king) and the optional useToonFormat. The limit/offset pagination is not elaborated beyond schema defaults, but the description focuses on the key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Find the top earner(s) per coin within the window' with a specific verb-resource combination. It explains the perCoinRank parameter and gives example queries ('who owns BTC?'), distinguishing it from sibling tools like pulse_leaderboard or pulse_top_traders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided ('Use for 'who owns BTC?' / 'who is the best trader of each market?'), guiding the agent on when to invoke this tool. It does not explicitly state when not to use, but the purpose is sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that data is aggregated and cached up to 120s, which is important for an agent to understand freshness. It does not explicitly state read-only safety, but the nature of a volume query implies no destructive side effects. A minor gap is not mentioning if large queries could be rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding distinct value: what, how to use, and a behavioral caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately hints at the return structure (volume by DEX with match counts and traders). For a single-parameter boolean tool, the description is thorough. A perfect 5 might include a note about return format or units, but the current description is sufficiently complete for an agent to understand what comes back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides (default true for toon format). This is acceptable given the simple boolean parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the 24h trading volume for the whole exchange, split by DEX (native Hyperliquid and builder dexes), including per-dex match counts and distinct traders. This specific verb (volume) and resource (exchange) distinguish it from siblings like pulse_global_stats or pulse_exchange_oi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit use case: 'how much volume does Hyperliquid do?' and a critical note that builder dexes (~43%) are often omitted by public trackers. This guides the agent to use this tool when needing total exchange volume with DEX breakdown, versus other volume-related siblings that may not provide this granularity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns trade fills with fields like timestamp, side, size, price, PnL, fee, tx hash, joined from the trades table within the open->close window. This gives insight into behavior and data sources. However, it does not mention edge cases (e.g., if ID not found) or performance implications, which prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The first sentence states the core function and output, and the second provides usage context. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description is fairly complete. It explains the return data (trade fills) and usage workflow. Missing details like pagination or error handling are minor and not critical for this simple lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds context by mentioning the numeric ID comes from 'pulse_trader_lifecycles' and that toon format is compact. However, it does not add substantial meaning beyond the schema—e.g., explaining what 'toon format' means—so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Look up one position lifecycle by its numeric ID', specifying the resource and action. It distinguishes from sibling 'pulse_trader_lifecycles' by indicating it is for drilling into a single position after obtaining a list. The verb 'look up' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after pulse_trader_lifecycles to drill into exactly how a single position was built and unwound', providing clear guidance on when to use this tool versus its sibling. This establishes a workflow context, satisfying the guidelines dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively conveys the tool's behavior: it queries for wallets meeting criteria, returns specific fields, and suggests parameter adjustment if no results. It could mention pagination or ordering but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a brief usage hint. Front-loaded with purpose, then return fields, use case, and tip. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists all return fields, which is adequate. It covers the essential context for a query tool. Could mention default ordering, but not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters (100%), but the description adds value by explaining the concept of 'new big players' and providing actionable advice to adjust minNotional. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds 'new big players' with specific criteria: recent first lifecycle and large notional. It lists the return fields, making the purpose concrete and distinguishing it from sibling tools like 'pulse_capital_titans'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use case ('who just showed up and is already trading big?') and a troubleshooting tip to lower minNotional. However, it does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes reconstructed nature from on-chain fills, output fields, and defaults/constraints (90-day window, spot excluded). With no annotations, description adequately covers safety profile (read-only implied) and behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-loaded with action and key details. No redundancy, every sentence adds value (what it returns, comparison to sibling, use case).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output fields, time window, filtering defaults, and purpose. Lacks explanation of pagination or sorting order, but schema handles pagination parameters. Reasonably complete for a read tool with well-documented schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds context for includeSpot (default exclusion of spot pairs) and mentions default status 'closed' indirectly through example fields. Adds slight value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'wallet's position lifecycle history', lists output fields (VWAP, PnL, etc.), and distinguishes from sibling tool 'closed-positions' by noting it returns full lifecycle data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for 'deep position-level due diligence and timing analysis' and notes defaults (90-day window, spot excluded). Does not explicitly contrast with alternative tools beyond the 'Richer than closed-positions' hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It discloses the attribution undercount caveat (trigger-order stop/TP fills not yet attributed), the default '30d' lookback clamped to 90d, ordering by fees, and the presence of dataNotes. It does not state authentication or rate limits, but covers the key behavioral nuances relevant to a read query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is several sentences but each serves a purpose: the core logic, output fields, a caveat, relationship to sibling, use cases, and tier requirement. It is structured and front-loaded with the main action, avoiding fluff. Slightly long but appropriately informative for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description provides enough context: full field list, ordering, default/clamping behavior, attribution caveat, tier requirement, and relationship to inverse tool. An agent can call it correctly without additional information. No pagination/limits are mentioned, but this is not critical for a per-wallet builder listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well documented (e.g., address pattern, since pattern with default and clamp, useToonFormat default). The description repeats the '30d' default and clamping but adds little new meaning beyond the schema. Baseline for full schema coverage is 3, and the description does not significantly exceed that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists builders (frontend, bot, HIP-3 dex) for a given wallet address, with attributed fills in a lookback window, ordered by fees paid. It specifies the resource (wallet), the output fields, and the inverse relationship to builder_traders, distinguishing it from an obvious sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides use cases ('which apps does this trader use?' and 'how much has wallet X paid frontend Y in fees?'), notes it is the inverse of builder_traders, and mentions the Starter tier requirement. This gives clear guidance on when and how to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool returns venues, collateral tokens, open interest, and synonyms. As a read-only lookup with no annotations, this is adequate for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with purpose and contain no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly states what is returned, making it complete for a simple lookup tool with only two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds examples and explains synonym resolution and default toon format, going beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lookup one asset by canonical name or synonym,' specifying the verb, resource, and scope. It contrasts with siblings like list_assets which likely return multiple assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user mentions a specific asset and you need its venue availability,' providing clear context and distinguishing from other tools. Does not explicitly exclude alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes that the tool groups by economic exposure, lists synonyms, venues, aggregated open interest, and cross-market flag. This is good behavioral disclosure, though it could mention that it's a read-only query (implied) and any performance or rate-limit traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first delivers purpose and output details, the second provides usage guidance. No filler, every sentence earns its place. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains what each asset entry contains (synonyms, venues, OI, cross-market flag). For a directory/list tool, this is sufficiently complete to inform the agent about return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented. The description adds minimal information beyond the schema; it implies crossMarketOnly behavior via the 'cross-market flag' mention but doesn't elaborate. Baseline 3 is appropriate as the schema handles the param semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every canonical asset traded on Hyperliquid or builder dexes, grouped by economic exposure, not venue ticker. It distinguishes from siblings like list_markets by specifying asset-level vs market-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to prefer this tool: 'Prefer this over list_markets when the user asks...' with concrete examples like 'what assets are available?', 'which venues is GOLD on?', or 'show me cross-market assets'. This provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits fully. It discloses the returned data fields and includes a calculation formula for funding APR. While it doesn't mention auth or rate limits, the tool is a simple read-only alias, and the description covers the key behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. It front-loads the deprecation warning and then provides the payload details and usage guidance, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a deprecated alias with two optional parameters, no output schema), the description is complete. It explains what the tool returns, provides a calculation hint, and references the preferred alternative. No additional information is needed for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter details beyond what the schema already provides; it only reiterates the overall purpose. Thus, it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a deprecated alias for list_markets and lists the exact payload returned (24h volume, open interest, mark price, raw hourly fundingRate decimal, 24h change for every pair). It distinguishes itself from siblings by explicitly calling out the deprecation and directing users to list_markets for new integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users to prefer list_markets for new integrations and indicates this tool is kept for backward compatibility only. This provides clear when-to-use and when-not-to-use guidance, along with the alternative tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description thoroughly explains the returned data fields and includes a formula for funding APR. It does not mention pagination or limits, but for a list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative and well-structured with front-loaded purpose. It could be slightly more concise, but every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 optional parameters and no output schema, the description is complete: it lists all returned fields, explains a key calculation, and gives clear usage guidance. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning to both parameters: dex filter with examples of each enum value, and useToonFormat explained as compact vs standard JSON. Goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns all trading symbols with specific fields (dex, mark price, volume, funding rate, etc.) and positions itself as the canonical market discovery tool. It differentiates from siblings like list_assets and pulse_market_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: user asks 'what markets are available?', mentions commodities, stocks, or builder-dex markets. Also says to prefer this over pulse_market_overview and to use list_assets for asset-level grouping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It discloses the tool is read-only (show), explains what data it returns (tier, rate limits, tier comparison, upgrade link), and notes that live quota info is also available via headers. This is thorough, but a minor gap exists: it doesn't specify whether the tool is destructive or has side effects, but the explicit 'show' verb makes that clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero waste. It front-loads the core purpose, then usage guidelines, then extra context. Every sentence earns its place, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional boolean parameter, no output schema needed), the description is fully complete. It explains purpose, when to use, what data is returned, and related header information. There are no gaps for an agent to make mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one boolean parameter with a default. The description adds value by explaining the overall output (compact toon format vs. standard JSON) and the context of the tool, which goes beyond the schema. A score of 4 reflects that the description enhances understanding of the param's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the current API key's plan, including tier, rate limits, and a comparison of every tier with an upgrade link. This is specific and explicit about the resource (plan) and verbs (show, call). It differentiates from siblings like pulse_global_stats or market statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: when the user asks about their plan, when a request was rejected due to tier or rate-limit reasons, or before recommending an upgrade. It also mentions live remaining-quota headers as an alternative source, providing clear guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so comprehensively: it explains cohorting (YYYY-MM, UTC), the activeWallets[k] definition, the 12-month window, the ORDERS plane vs fills, and points to dataNotes for the attribution caveat. It also states the Pro tier requirement. This is rich, non-obvious behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but every sentence carries essential information—methodology, definitions, contrasts, use case, and access requirement. It is front-loaded with purpose and then logically details the behavior. No fluff, so it earns a high score despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex retention tool with no output schema, it explains the response shape (activeWallets[k], cohorts, time coverage) and points to dataNotes for caveats. It also covers the measurement plane, prerequisites, and the intended use case, making it sufficient for correct invocation without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3, but the description adds meaning beyond the schema: it clarifies the builder address is the fee-receiving address and notes that only the builder is needed for the core logic (the useToonFormat is format only). It also explains the builder's role in the context of first builder-fee orders, which helps the agent use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Monthly retention matrix for a builder's users' with a specific verb and resource. It differentiates from siblings by naming builder_cohorts/builder_overlap and explaining the ORDERS-plane measurement difference, so an agent can distinguish it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides a use case: 'Use for "does builder X retain users month over month, or churn them?"' and contrasts with the attributed-fill counts on builder_cohorts/builder_overlap, giving clear when-to-use-and-when-not guidance. The Pro-tier requirement is also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries behavioral disclosure. It notes the lookback is clamped to 90d, that trigger-order fills are not attributed (undercounting vs ledger revenue), and that the response contains dataNotes. It also explicitly lists all output fields and the order id null case, leaving few surprises. The Pro tier requirement is also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: main function, parameter context, field list, caveat, use cases, and tier requirement. It is well front-loaded, leading with the core purpose, and structured logically. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description covers the essential operational details: how to construct calls (window, filters), what the response contains (field list), caveats (undercount, clamping), and use cases. Combined with the rich schema descriptions, an agent has everything needed to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description still adds value by clarifying the builder parameter ('the fee-receiving address a frontend/bot/dex registers on Hyperliquid') and giving concrete examples for coin formats (BTC, xyz:GOLD, @123 spot, #10010 HIP-4). It does not repeat schema details but enriches meaning beyond the schema, warranting a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns individual fills attributed to a builder address within a time window, with optional coin and wallet filters. It explicitly enumerates the returned fields, making the resource and action unambiguous. It also distinguishes itself from aggregate builder tools (e.g., builder_leaderboard) by emphasizing 'individual fills'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'Use for show me the flow going through frontend X right now or auditing one wallet's activity via a builder.' It also discloses the Pro tier requirement and the limitation that trigger-order fills are not included, implicitly guiding when an alternative tool may be needed. This gives clear context for selection among the many builder_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/Coinversaa/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Coinversaa/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/Coinversaa/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Coinversaa/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Coinversaa/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server