0xarchive-mcp

Server Quality Checklist

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

Latest release: v1.9.0
Disambiguation4/5
Tools follow clear scope+data_type patterns, but the sheer number of variations (e.g., multiple orderbook levels for each venue) could confuse an agent. Descriptions clarify distinctions, but misselection is possible if not read carefully.
Naming Consistency5/5
All tools use a consistent `get_<scope>_<data_type>` pattern, with uniform use of underscores and descriptive suffixes (e.g., _history, _recent, _current). Even admin tools use `web3_` prefix. Naming is exemplary.
Tool Count2/5
With 111 tools, the surface is bloated. Many tools are redundant across venues and tiers (e.g., L2 vs L4 orderbook for each venue). The count overwhelms the server's purpose, making navigation difficult for agents.
Completeness5/5
The tool set covers nearly every data type for all venues: orderbook (multiple depths), trades, candles, funding, OI, liquidations, order flow, and system status. Web3 tools for account management are also included. No obvious gaps.
Average 4.1/5 across 100 of 111 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds 'periodic full order-level snapshots' and 'Hard cap limit=10 per request', but the limit claim directly contradicts the input schema's limit parameter (max 1000). This inconsistency harms transparency.
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 description is relatively concise with two main parts, but the contradictory hard cap statement adds confusion. It could be more concise by removing the misleading limit and focusing on the checkpoint nature.
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 5 parameters and existence of output schema, the description omits usage guidelines and contains a factual contradiction. It does not explain pagination beyond mentioning cursor, nor does it clarify the 'checkpoints' frequency. Incomplete for a history 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 the schema already documents all parameters comprehensively. The description adds minimal extra meaning beyond repeating coin format and mentioning the hard cap (which is contradictory). 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 retrieves HIP-4 L4 orderbook checkpoints for a coin, using specific verb and resource. It distinguishes from sibling tools like orderbook diffs by mentioning 'periodic full order-level snapshots'. However, the hard cap limit statement is confusing and may mislead about the tool's actual behavior.
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 versus alternatives like get_hip4_l4_orderbook or get_hip4_l4_diffs. The description implies it is for historical snapshots, but does not specify context 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minor context: 'Derived from L4 data' and 'Build+ tier' (access tier). No contradictions; the description does not reveal additional behavioral traits like rate limits or auth requirements beyond what annotations imply.
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, concise and front-loaded with the core function. The phrase 'Build+ tier' is slightly jargon-heavy but not overly verbose. Could be slightly clearer about depth default, but overall 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?
Output schema exists, so return values are defined. Annotations cover safety. The description mentions derivation from L4 and tier, but omits default depth behavior (if depth omitted, presumably full depth) and does not clarify if 'full-depth' implies unlimited levels. Adequate but has minor gaps relative to the tool's complexity (3 params, non-trivial market data).
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 (coin with examples, timestamp for historical, depth for levels). The description adds no extra parameter information; it only restates that symbols are case-sensitive, which is already in the schema. Baseline 3 is appropriate since 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 the HIP-3 L2 full-depth orderbook, including case sensitivity and derivation from L4 data. It distinguishes from other orderbook tools by name and mentions 'Build+ tier', but does not explicitly differentiate among sibling tools like get_hip3_l2_diffs or get_hip3_l4_orderbook.
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 such as get_hip3_l2_diffs for real-time updates or get_hip3_l2_orderbook_history for historical snapshots. The description implies it is for current or historical full-depth snapshots, but lacks explicit when-to-use or when-not-to-use instructions.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool returns full order-level data with order IDs, user addresses, prices, and sizes. It does not disclose limitations like historical range or rate limits, but provides some behavioral context beyond annotations.
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 front-loads the purpose and return contents. It is efficient with no redundancy, but could be slightly more structured.
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 output schema exists and all parameters are documented, the description provides enough context for the tool's purpose and return format. It does not miss critical information for a snapshot read operation.
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. The description adds no additional meaning to the parameters beyond what the schema provides, so baseline 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 it gets Hyperliquid L4 orderbook reconstruction at a specific timestamp, listing returned fields. It specifies the resource but does not explicitly differentiate from sibling orderbook tools like get_l2_orderbook or get_l4_orderbook_history.
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 versus alternatives. It implies usage for a snapshot at a specific timestamp, but does not address prerequisites, tier restrictions, or why one would choose this over L2 or other L4 endpoints.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds useful behavioral context: case sensitivity, data availability from February 2026, and output fields (total, long, short USD volumes). No contradictions with annotations.
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), front-loaded with the main action and output. It efficiently communicates key details without extraneous information, though could include a brief note on when to use.
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 presence of an output schema (not shown) and detailed annotations, the description adequately covers key aspects. It mentions time-bucketed intervals and data availability, but does not explain pagination (though cursor param exists) or clearly differentiate from similar siblings. Sufficient 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%, so the schema already documents all six parameters with descriptions. The description briefly mentions case sensitivity and an example symbol, but does not add significant meaning 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.
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 aggregated HIP-3 liquidation volume for a coin in time-bucketed intervals, returning total, long, and short USD volumes. It specifies case sensitivity and data availability, distinguishing it from non-HIP-3 counterparts, but does not explicitly differentiate from sibling 'get_hip3_liquidations' which likely provides raw events.
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 like get_hip3_liquidations or get_liquidation_volume. It implies use by describing aggregated volume, but lacks explicit when-to-use or when-not-to-use statements.
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?
Annotations already mark the tool as readOnly and idempotent, so the description adds value by detailing return fields, aggregation intervals, and data availability. However, it does not disclose any behavioral traits beyond the 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 brief and efficient, using two sentences to convey the tool's purpose and key characteristics without 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 input schema descriptions and annotations, the description adequately covers the tool's purpose and output. However, it does not mention pagination or the fact that limit defaults exist, though those are in 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 coverage is 100% with all parameters described. The description does not add additional meaning beyond the schema; it simply summarizes the same information.
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 mark/oracle price history for a coin, specifying the returned data fields (mark, oracle, mid price). It mentions aggregation intervals and data availability, but does not explicitly differentiate from sibling tools like get_hip3_price_history or get_lighter_price_history.
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 such as get_candles or other price history variants. The description does not mention prerequisites, context, or exclusions for 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?
Annotations already indicate read-only, non-destructive, idempotent, open world. Description adds Pro+ tier requirement and case-sensitivity warning, but does not clarify timestamp necessity (schema marks it optional) or data freshness/rate limits.
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 action and key constraints. Every sentence adds value.
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 output schema exists, return values are covered. However, lacks comparative context with many siblings (e.g., when to use L4 vs L2, HIP-3 vs HIP-4). Pro+ tier mentioned but not elaborated.
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 has 100% description coverage, so parameters are already well-documented. Description reinforces case-sensitivity for 'coin' but adds no new meaning for 'timestamp' or 'depth'.
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 a HIP-3 L4 orderbook reconstruction, specifying it is for Pro+ tier, symbols are case-sensitive, and returns full order-level data at a given timestamp. This distinguishes it from siblings like get_hip3_l2_orderbook and get_hip3_orderbook.
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 alternatives (e.g., L4 vs L2, real-time diffs vs historical reconstruction). Does not mention prerequisites or context for choosing this tool.
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?
Annotations already provide safety profile (read-only, idempotent). Description adds return fields but no additional behavior like authorization or rate limits. Adequate but not extra value.
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-loaded with purpose. 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 one-parameter tool with output schema and annotations, the description is sufficiently complete. Could add examples or expected usage 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 covers 100% of parameters with enum and description. Description adds minor context (venue scope) but doesn't elaborate on enum values. Baseline is 3.
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 gets data coverage for a specific venue scope and lists return fields. It distinguishes from siblings like get_data_coverage (likely all venues) and get_symbol_coverage, but could explicitly differentiate.
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?
Implied usage for a single venue, but no explicit guidance on when to use it vs. alternatives like get_data_coverage or get_symbol_coverage. Lacks when-not-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?
The description adds value beyond annotations by specifying that the tool shows last update time and current lag for each data type. The annotations already indicate readonly and idempotent behavior, and the description does not contradict them. No side effects or error conditions are mentioned, but the core behavior is 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 exceptionally concise at two sentences, with the purpose front-loaded in the first sentence and detail in the second. There is no redundant or 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 the presence of an output schema, the description does not need to detail return values. It adequately describes the input and high-level output. However, it could be more complete by explicitly situating this tool among the many freshness variants (e.g., noting it is for the standard market).
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 only parameter, 'coin', is fully described in the input schema with examples. The tool description does not add any further semantics about the parameter, so it meets the baseline expectation given 100% schema coverage. No additional parameter context is needed.
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's purpose: getting data freshness for a coin across multiple data types. It lists the data types and explains what the output shows. However, it does not explicitly differentiate this base freshness tool from its many variants (e.g., get_hip3_freshness, get_spot_freshness) based on market context.
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 instead of similar sibling tools. The description does not mention any prerequisites, when to prefer this over market-specific freshness tools, or any limitations. The openWorldHint is set but not explained.
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?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds that it returns the latest funding rate, premium, and timestamp, providing context beyond annotations. Could mention edge cases like missing coin data.
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 sentence with no filler. 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 that an output schema exists, detailed return value explanation is not required. The description covers the essential return fields. For a one-parameter tool, it is sufficiently 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 a clear description of the 'coin' parameter. The description does not add extra meaning beyond what the schema provides, so it meets the baseline.
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 gets the current funding rate for a coin, specifying the three return fields. However, does not differentiate from sibling tools like get_hip3_funding_current or get_lighter_funding_current, which have similar purposes.
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 such as get_funding_history or variants. The description implies usage for current data but lacks explicit context 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context such as 'Symbols are CASE-SENSITIVE' and the tier requirement, but these are minor. It does not disclose potential side effects or performance characteristics beyond what annotations provide. The added value is moderate, so a score of 3 is appropriate.
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 concise sentences with no filler. The first sentence front-loads the core purpose and tier, and the second adds critical usage notes and output description. Every word is efficient and informative.
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 essential purpose, tier, case-sensitivity, and output metrics. Given that the input schema is fully documented and an output schema exists, the description is nearly complete. It could mention pagination or time range options, but those are covered in the schema, so this is not a major 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?
The input schema has 100% description coverage, so the baseline is 3. The description repeats the case-sensitivity note and mentions interval default, both already present in the schema. It adds no new semantic meaning beyond the schema, thus no improvement over 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's action: 'Get HIP-3 order flow aggregation'. It specifies the resource (HIP-3 order flow) and the kind of data returned ('aggregated order placement, cancellation, and fill metrics'). It also includes the tier requirement (Build+) and a concrete symbol example, making the purpose unambiguous. The name itself differentiates from siblings like get_hip4_order_flow.
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 mentions 'Build+ tier' which implies a usage restriction, but it does not explicitly state when to use this tool over alternatives. There is no mention of when not to use it, nor are sibling tools like get_order_flow or get_hip4_order_flow referenced for comparison. The single usage hint (tier) is insufficient for guiding an agent on tool selection.
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?
Annotations already indicate read-only, idempotent, and open-world. The description adds value by detailing the return content (placements, fills, cancellations, modifications) and clarifying coin format acceptance. It also notes user attribution behavior and tier requirement, going beyond the structured 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, directly stating the core functionality and coin format. Every word serves a purpose, with no fluff or repetition. It is 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?
Given the tool has 8 parameters and an output schema, the description covers the essential purpose and return types. It explains the coin format and tier requirement. However, it lacks details about pagination or how the user field relates to attribution, leaving minor gaps 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%, so parameters are well-documented. The description's mention of coin forms and event types adds some context but largely overlaps with parameter descriptions. No new parameter semantics are introduced beyond what the schema provides, resulting in a baseline score.
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 HIP-4 order lifecycle events with user attribution for a specific coin, listing the event types. However, it does not explicitly differentiate from siblings like get_order_history or get_hip3_order_history, leaving the agent to infer the HIP-4 specificity and Pro+ tier requirement.
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 versus alternatives such as get_order_history or get_hip3_order_history. The description mentions 'Pro+ tier' which implies a usage constraint but does not help an agent choose between similar 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so description's burden is lower. It adds that results are OHLCV with specific fields, but does not discuss pagination behavior, time range defaults (e.g., start defaults to 24h ago) beyond the schema, or any rate limits. 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 that front-load the core purpose and key options (intervals, fields). Every word earns its place; no 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?
For a data retrieval tool with output schema (not shown), description covers main purpose, intervals, and fields. It omits explicit mention of pagination or time range defaults beyond '24h ago', but given the tool's simplicity and the presence of annotations and schema, it is largely sufficient. Could be improved by noting that cursor is for pagination.
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 lists intervals (1m to 1w) and default interval, and mentions returned fields, which adds some context. However, it does not explain each parameter beyond what the schema provides, such as the cursor for pagination or the meaning of start/end timestamps. No significant extra 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?
Description clearly states it retrieves Lighter.xyz OHLCV candle data, listing fields (open, high, low, close, volume) and intervals. Distinguishes from sibling tools by specifying 'Lighter.xyz', which differentiates from other candle sources like get_candles or get_hip3_candles.
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 versus siblings (e.g., get_candles, get_hip3_candles). While it mentions intervals and defaults, it does not compare or contrast with alternatives, leaving the agent without direction for source selection.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate safe, idempotent read. Description adds that it returns OI, mark price, and oracle price, which provides additional behavioral context beyond annotations. 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?
Single sentence that is front-loaded with the action and results. No wasted words; every element contributes to understanding.
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 presence of an output schema and clear annotations, the description adequately specifies the tool's purpose and return fields. Some minor guidance on when to choose this over sibling OI tools would improve completeness, but it is sufficient for a simple read 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% and includes a clear description for the single parameter 'coin' with examples. The description does not add additional semantic value 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 it retrieves current Lighter.xyz open interest for a coin and specifies the returned fields (OI, mark price, oracle price). This distinguishes it from history tools and other platform-specific OI tools 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 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 like get_lighter_open_interest_history, get_open_interest, or platform-specific OI tools. The description implicitly limits to current data but does not explicitly state exclusions or comparative usage.
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?
Annotations already declare read-only, safe, idempotent behavior. Description adds value by noting data availability from April 2023 and cursor pagination, which are beyond structured fields.
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 clear front-loading of main action. No wasted words; every sentence adds useful 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 rich annotations and output schema, description covers purpose, return fields, data availability, and pagination. Lacks mention of ordering or rate limits but is sufficient for typical use.
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 fully describes all 5 parameters (100% coverage). Description references time range and pagination but adds no new semantics beyond the schema.
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 Hyperliquid trade/fill history for a coin over a time range, listing return fields. However, it does not differentiate from many similar trade tools (e.g., get_hip3_trades, get_lighter_trades) which share the same purpose.
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?
Provides no guidance on when to use this tool versus alternatives. It describes basic functionality but omits context like preferred use cases or prerequisites.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the tool's safety is clear. The description adds valuable behavioral context: symbols are case-sensitive and returns the latest funding rate and timestamp. This goes beyond what annotations provide.
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-loaded with the core action. Every word earns its place. No redundancy or fluff.
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, single-parameter tool with an output schema (not shown but present), the description covers what the tool does, its key behavioral quirk (case sensitivity), and what it returns. No gaps identified.
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 has 100% coverage with a detailed description of the 'coin' parameter including case sensitivity and examples. The tool description adds only a single example ('km:US500') and reinforces case sensitivity, which adds marginal value over the schema. Baseline 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 gets the current HIP-3 funding rate for a coin, with a specific verb and resource. The case-sensitivity note adds precision. However, it does not explicitly differentiate from siblings like get_hip3_funding (which may return history) or get_funding_current (non-HIP3), relying on naming conventions alone.
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 implies 'current' suggests latest data, but does not mention tools like get_hip3_funding for historical data or get_funding_current for non-HIP3. The agent receives no strategic selection advice.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns 'the latest funding rate and timestamp,' which aligns with read-only behavior but does not disclose caching, update frequency, or rate limits.
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 main action. Every word contributes meaning; no superfluous content.
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 single-parameter tool with full schema coverage and an output schema, the description adequately explains what the tool returns and the data source. No missing critical information.
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 sole parameter 'coin' is fully described in the schema with examples. The description does not add additional meaning beyond the schema, so baseline 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 current Lighter.xyz funding rate for a coin, specifying the exchange and return fields. It distinguishes itself from sibling tools like get_funding_current (generic) and get_hip3_funding_current (HIP3-specific).
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 when to use this tool versus alternatives like get_funding_history or get_lighter_funding (historical). No exclusions or context about other exchanges or data types is given.
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?
Annotations already indicate readOnly, non-destructive, idempotent, open-world. Description adds that it's 'live since 2026-05-05' and mentions dashed symbol resolution, but no additional behavioral traits beyond annotations. No contradiction.
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, front-loaded with purpose, then symbol format, then behavioral note. No fluff, 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 output schema exists, description need not detail return values. It correctly identifies scope (Spot, pair) and distinguishes from siblings. Could explicitly mention when to prefer this over get_spot_trades, but adequate for simple endpoint.
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 both parameters (coin format, internal resolution; limit defaults and max). Description adds minor context about dashed symbols and 'without time range' but does not provide new semantics 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 gets the most recent Hyperliquid Spot trades for a pair, using dashed canonical symbols. Distinguishes from siblings like get_spot_trades (which likely requires time range) and get_trades (perpetual).
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?
Description says 'returns the latest trades without needing a time range,' implying when to use but does not explicitly state when not to use or compare with alternatives like get_spot_trades. No explicit guidance on context.
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?
Annotations already convey non-read-only, non-destructive, and non-idempotent behavior. The description adds detail about requiring a generated challenge and signature format, but does not discuss error cases, idempotency effects, or rate limits.
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 effectively convey the action, prerequisites, and output with no unnecessary words. Very concise and well-structured.
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?
Provides sufficient context for a simple two-parameter tool with an output schema. Covers the purpose, prerequisites, and result. Could mention that the API key should be stored securely, but current content is adequate.
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 already covers both parameters with descriptions. The description adds context by linking the message to web3_challenge and the signature to personal_sign, clarifying the workflow beyond what the schema provides.
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 creates a free-tier account and returns an API key, specifying the required inputs. However, it does not explicitly distinguish from sibling tools like web3_list_keys or web3_revoke_key, leaving some room for ambiguity.
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?
Specifies the prerequisite of a challenge from web3_challenge signed with personal_sign, but does not provide exclusions or mention when to use alternatives (e.g., if the user already has an account).
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal behavioral context (latest trades) but does not disclose any additional traits beyond what annotations provide.
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 primary action, and every sentence adds useful information 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?
Given the presence of an output schema and detailed annotations, the description sufficiently covers the tool's purpose and coin parameter, making it complete for a simple recent-trades retrieval tool.
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%. The description adds value by explaining the coin format with examples and legacy forms, which enhances meaning beyond the schema's 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 retrieves the most recent HIP-4 trades for a coin, with an example. It distinguishes itself from time-range-based queries by noting 'without needing a time range', but does not explicitly differentiate from sibling tools like get_hip4_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 indicates when to use (to get latest trades without a time range) but does not provide explicit guidance on when not to use or alternatives like get_hip4_trades for historical data.
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?
Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds behavioral context: returns 'aggregated price levels with total size and order count per level', 'Derived from L4 data', and a temporal limitation. This enriches the agent's understanding of the tool's behavior and data provenance.
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 with four sentences, each adding unique value: purpose, output specification, data derivation, and temporal scope. No superfluous information; front-loaded with essential details.
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 presence of an output schema (context indicates it exists) and well-documented input schema, the description sufficiently covers the tool's functionality. It explains the output format, data source, and tier requirement. Minor improvement could be clarifying the meaning of 'Build+ tier' or the relationship to sibling tools.
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% coverage with clear descriptions for all three parameters (coin, timestamp, depth). The description does not add new meaning beyond the schema, which already adequately documents parameter usage. 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 'Get Hyperliquid L2 full-depth orderbook' with specific verb and resource. It mentions 'Build+ tier' and 'Derived from L4 data' to contextualize, but does not explicitly differentiate from sibling tools like get_orderbook or get_hip3_l2_orderbook, leaving some ambiguity.
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 fetching the current L2 orderbook with the 'Build+ tier' requirement and temporal constraint ('Data from March 2026+'), but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_l2_orderbook_history for historical data) or any when-not scenarios.
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?
Annotations already confirm read-only and idempotent behavior. The description adds useful details like cursor pagination and aggregation intervals, enhancing understanding beyond 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?
Two clear sentences, front-loaded with purpose, no filler. Every word 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?
Given the complexity (6 params, pagination, intervals) and existence of an output schema, the description covers key aspects. Could mention defaults but schema handles them.
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 6 parameters. The description summarizes pagination and intervals but does not add significant new 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?
The description explicitly states 'Get Lighter.xyz funding rate history for a coin over a time range', with a specific verb and resource, and distinguishes from siblings like get_lighter_funding_current by focusing on history.
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 such as get_funding_current or get_funding_history, leaving the agent to infer from context.
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?
Annotations already indicate read-only, safe, idempotent behavior. Description adds that it returns individual order details but does not mention rate limits, pagination, or data freshness. 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?
Single sentence that front-loads the purpose and includes tier info. No wasted words; efficient and clear.
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 purpose and return content. With output schema present, return details are defined. Could clarify that depth parameter limits price levels, but schema covers that. Missing mention of current vs historical data.
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 documented. Description does not add additional meaning beyond the schema; it lists return fields but does not elaborate on input 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?
Clearly states it gets Lighter L3 order-level orderbook with specific return fields (order IDs, user addresses, prices, sizes). Distinguishes from sibling orderbook tools by specifying 'L3' and 'order-level' and noting 'Pro+ tier'.
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?
Implies usage via 'Get Lighter L3 order-level orderbook' but does not explicitly differentiate from similar tools like get_lighter_l2_orderbook or get_lighter_orderbook. No when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds that it returns specific price types and supports intervals, but does not disclose additional behavioral traits like pagination limits or data freshness.
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 purpose, and every sentence adds value. 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 the tool's simplicity, annotations, and schema coverage, the description adequately covers the tool's purpose and key features. However, it could mention that it's for Lighter.xyz specifically to distinguish from siblings, but the name implies that.
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 context beyond schema names by specifying return fields and interval support, enhancing 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 retrieves mark/oracle price history for a specific platform (Lighter.xyz), specifies the returned fields, and mentions aggregation intervals. This distinguishes it from general price history tools.
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 compared to similar tools like get_price_history or get_hip3_price_history. The context signal includes many siblings, but the description does not differentiate 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds minor context about data availability (May 2023) and output content (timestamped OI snapshots with mark/oracle prices). No contradictions with 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 three sentences with no wasted words. First sentence states purpose, second describes output, third provides data availability and intervals. 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's complexity (6 params, output schema exists), the description covers purpose, output, data range, and intervals. It does not explain pagination or defaults, but those are in the schema. Adequate for a read-only history 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 parameters are well-documented. The description adds value by explaining output includes mark/oracle prices and mentioning aggregation intervals, but this is tangential to parameters. 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 verb 'Get' and the specific resource 'Hyperliquid open interest history for a coin over a time range'. It distinguishes from siblings like get_open_interest by emphasizing time range, OI snapshots with prices, and aggregation intervals. Data availability from May 2023 adds further specificity.
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 historical OI data with timestamps and prices, but does not explicitly state when to use this tool versus siblings like get_hip3_open_interest_history or get_lighter_open_interest_history. No exclusions or alternative recommendations are provided.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that results include severity, duration, etc., but does not disclose additional behavioral traits like rate limits or auth requirements. No contradiction with 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?
Two concise sentences with front-loaded purpose, filtering options, and return details. Every sentence adds value 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?
With a complete output schema and 5 optional parameters (2 with enums), the description sufficiently covers the tool's functionality. No critical gaps remain for a list endpoint.
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 all 5 parameters described. The description reinforces filtering by status, exchange, and time but does not add new semantic meaning beyond what the schema provides. Pagination parameters (limit, offset) are omitted from the 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 'List' and the resource 'data quality incidents', providing concrete examples (outages, gaps, degradations) and mentioning return fields. It distinguishes from siblings like get_data_coverage by focusing on incidents specifically.
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 filtering capabilities but does not explicitly state when to use this tool vs alternatives like get_incident (singular). No 'when not to use' or comparative guidance is provided.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value beyond this by specifying that it returns take-profit and stop-loss orders with trigger prices and triggered status, and that it accepts legacy coin forms. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is brief (two sentences). It efficiently conveys the core functionality without unnecessary verbosity, though it could be slightly more structured for 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 the presence of an output schema, the description does not need to detail return values. It covers input coin format, output content (TP/SL orders with trigger prices and status), and mentions pagination only implicitly via the cursor parameter in schema. The description is adequate for this type of read-history 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 baseline is 3. The description adds minor semantic value by clarifying that 'bare numeric coins are canonical' and legacy forms are accepted, but does not elaborate on other parameters 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 the action ('Get'), resource ('HIP-4 TP/SL order history'), and tier ('Pro+ tier'), distinguishing it from sibling tools like get_hip3_tpsl or get_tpsl. The example '0' helps immediately identify the coin format.
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 HIP-4 Pro+ tiers via the name and tier mention, but it does not explicitly state when to use this vs alternatives (e.g., for legacy HIP-3 or non-tiered TP/SL). No 'when not to use' or direct sibling comparison.
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?
Annotations already convey readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context about returning price-level changes over a time range, which is consistent and informative beyond annotations.
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?
One sentence with key info (function, level, tier, output). No wasted words. Could be slightly more structured, but effective.
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 output schema exists and annotations are rich, the description covers the core functionality. However, it lacks mention of pagination (cursor/limit) or that diffs are incremental, which could be useful for an agent. Otherwise 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?
Input schema has 100% description coverage, so the description does not need to add much. It mentions 'time range' aligning with start/end, but no additional parameter semantics 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?
The description clearly states it retrieves L2 orderbook diffs (price-level changes) over a time range, distinguishing it from siblings like get_l2_orderbook (snapshot) and get_l2_orderbook_history (historical snapshots).
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 'Pro+ tier' indicating access restriction, but does not explicitly guide when to use this tool over siblings (e.g., differences from get_l2_diffs vs get_l2_orderbook). No when-not-to-use or alternative recommendations.
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?
Annotations already indicate read-only and idempotent behavior. The description adds specific return fields (bids, asks, mid price, spread) and the depth limitation tied to subscription tier, going beyond the structured metadata.
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 and output, followed by optional parameter and requirement. No redundant information.
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 tool with complete input schema and output schema present, the description covers all essential aspects: what it returns, optional parameter, and access requirement. No 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 clear descriptions for both parameters. The description only reiterates that depth is optional and specifies price levels per side, adding no new semantics beyond the schema.
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 the current L2 orderbook snapshot for a coin, listing returned data (bids, asks, mid price, spread). However, it does not differentiate from many sibling orderbook tools like get_l2_orderbook or get_spot_orderbook.
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?
Mentions the Pro tier requirement for full depth, providing a usage constraint. Lacks explicit guidance on when to use this tool vs alternatives or 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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds detail on return fields but does not disclose additional behavioral traits (e.g., caching, rate limits).
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, front-loaded sentence that covers the key purpose and return fields without extraneous information. Slightly dense but 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?
With annotations covering safety and an output schema existing, the description adds necessary context about the return structure. The tool is well-documented given its simplicity.
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 input schema has zero parameters, so the description correctly adds no parameter details. Baseline score of 4 applies per guidelines.
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 current system status for venue APIs and data types, listing specific return fields (overall health, per-scope status, etc.). It is distinct from sibling tools like get_data_coverage or get_data_incidents.
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 is for a high-level status overview but does not explicitly state when to use it instead of more specific sibling tools (e.g., get_data_latency). No exclusions or alternatives 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns OHLCV data and interval details but does not disclose behavioral traits like pagination behavior or rate limits beyond what annotations provide.
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 front-loaded with the main purpose, followed by key details (case-sensitivity and intervals). 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately omits return value details but covers purpose, symbol format, and intervals. It does not mention pagination (cursor parameter), but the schema handles that. Overall fairly complete for a simple data 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?
Input schema has 100% description coverage, so the baseline is 3. The description reinforces case-sensitivity and intervals but does not add significant 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 'Get HIP-3 OHLCV candle data', specifying the exact resource (HIP-3 candles) and differentiating from sibling tools like get_candles (non-HIP-3) and other get_hip3_* tools for different data types.
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?
It provides clear usage context (case-sensitive symbols, intervals) but does not explicitly mention when to use this tool vs alternatives like get_candles or other candle tools. This is a minor gap for an otherwise clear purpose.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by stating 'Symbols are CASE-SENSITIVE' and 'Returns periodic aggregated snapshots', which are behavioral details not covered by annotations. 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?
Two concise sentences plus a key note. Front-loaded with main purpose. No redundant or filler content. Every sentence provides 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?
Output schema exists, so return format is covered. Required parameters and optional params are clear. The description explains the main purpose, case sensitivity, snapshot nature, but could mention pagination (cursor) or the tier's limitation. Still adequate for a historical data 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 each parameter described. The description only repeats the case-sensitivity note for 'coin', which is already in the schema. No additional 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?
Description clearly states 'Get HIP-3 L2 full-depth orderbook checkpoints' with specific verb and resource. It distinguishes from siblings like get_hip3_l2_orderbook (current snapshot) and get_hip3_l2_diffs (changes) by mentioning 'history' and 'periodic aggregated snapshots'. The tier 'Build+' adds context.
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 like get_hip3_l2_orderbook or get_hip3_l2_diffs. The description implies historical data but doesn't compare or contrast. The case-sensitivity note is helpful but doesn't address selection criteria.
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?
Annotations already declare readOnly, destructiveHint, idempotent. The description adds that it returns mark, oracle, mid prices and supports aggregation intervals, providing some behavioral context beyond annotations, but does not cover pagination or data retention.
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 front-loaded with purpose, case-sensitivity warning, return values, and interval support. No fluff or repetition.
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 output schema exists, the description covers core functionality well. Could mention pagination (cursor) and clarify difference from get_hip3_candles, but still fairly complete for a price history 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 detailed parameter descriptions (e.g., coin examples, start/end defaults, interval enum). The description adds minimal parameter-specific semantics (mentions case-sensitivity for coin but that's already in 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 'Get mark/oracle/mid price history for a HIP-3 coin over a time range', specifying the verb (Get), resource (price history), scope (HIP-3 coin, time range), and return values (mark, oracle, mid price). It distinguishes from siblings like get_hip3_candles (OHLCV) by focusing on price types.
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 implies usage for HIP-3 price history and notes case-sensitivity, but does not explicitly state when NOT to use it (e.g., for candles use get_hip3_candles). However, the context and sibling names make differentiation possible.
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?
Annotations (readOnlyHint, idempotentHint) are consistent, and the description adds that it returns price, size, side, timestamps over a time range with cursor pagination. No contradictions and good additional context beyond 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 concise, using only two sentences to convey the core purpose, supported formats, and features like time range and pagination. 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 the output schema exists, the description adequately covers the tool's function, coin format, time range, and pagination. It does not need to detail return values, but could mention error handling or rate limits.
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%, providing baseline 3. The description adds coin format details already present in the schema, offering no new parameter semantics 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 it retrieves HIP-4 trade/fill history for a coin, specifying the verb 'Get' and resource 'trade/fill history'. It also distinguishes coin format and mentions cursor pagination, differentiating it from siblings like get_hip4_trades_recent.
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 does not explicitly state when to use this vs. siblings. While it mentions pagination and coin format, it lacks guidance on when to prefer this over get_hip4_trades_recent or other trade-related 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds that results are periodic aggregated snapshots, but does not expand on behavior beyond annotations. No contradiction.
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 that front-load the core function and add key context. 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 many sibling orderbook history tools, description clarifies this is for L2 historical snapshots with Build+ tier. Output schema exists. Could further differentiate from get_orderbook_history or explain pagination, but sufficient for most use 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?
Input schema has 100% description coverage with detailed parameter explanations. Description does not add additional parameter meaning beyond the schema. 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 clearly states the verb (Get), resource (L2 full-depth orderbook checkpoints), and scope (over a time range). It distinguishes from siblings like get_l2_orderbook (current snapshot) and other orderbook history tools of different levels.
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?
Mentions 'Build+ tier' (access) and 'periodic aggregated orderbook snapshots over a time range' but does not explicitly compare to alternatives like get_orderbook_history. Siblings are numerous and naming provides some guidance, but more explicit when-to-use would help.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description adds context about the return content (raw order-level changes) and mentions the Pro+ tier requirement. It does not contradict 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?
Two sentences, front-loaded with the main purpose, followed by return details. 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 the presence of a rich output schema and annotations, the description covers the essential purpose and return type. It mentions tier restrictions. It could briefly mention pagination but that is covered in 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%, and the description does not add additional meaning beyond the schema. The parameter details are clear in the schema itself.
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 'Hyperliquid L4 orderbook diffs', and specifies it returns raw order-level changes over a time range, distinguishing it from siblings like get_l4_orderbook which likely returns snapshots.
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 retrieving order diffs over time but does not explicitly state when to use this tool versus alternatives (e.g., get_l2_diffs, get_l4_orderbook) or mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that it returns periodic full order-level snapshots over a time range, adding behavioral context beyond annotations. No contradiction with readOnly, idempotent, or openWorld hints. Does not mention pagination or rate limits, but schema covers cursor.
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, 18 words, front-loaded with essential information. No redundant or verbose phrasing.
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 key aspects: tier, data type (order-level snapshots), time range. Missing mention of pagination despite cursor parameter, but output schema likely handles return details. Adequate for a well-structured tool with annotations.
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 parameters. Description adds context about 'time range' and 'reconstruction', but does not significantly enhance parameter understanding 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?
Clearly states it retrieves Hyperliquid L4 orderbook checkpoints, specifies the Pro+ tier, and indicates periodic full snapshots for reconstruction. Distinguishes from siblings like get_l4_orderbook which likely returns the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions Pro+ tier and reconstruction use case, but does not explicitly state when to use this tool versus alternatives like get_l4_orderbook or get_l4_diffs. Provides implied context but lacks clear when-not or sibling differentiation.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by detailing return content (order-level snapshots with IDs, addresses) and tier requirement (Pro+). Does not mention pagination or rate limits, but these are covered by schema 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?
Two sentences, no wasted words. First sentence states action and tier, second describes return fields. Front-loaded with key decision factors (historical, L3, Pro+).
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 6 params and an output schema. Description covers purpose, return content, and tier. Could mention pagination cursor or depth parameter behavior, but output schema likely covers return structure. Nearly 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 has 100% description coverage. Description's 'over a time range' loosely references start/end, but adds no structural meaning beyond schema. Baseline 3 as schema carries parameter info.
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 historical Lighter L3 orderbook snapshots' – specific verb, resource, and scope. It distinguishes from real-time (get_lighter_l3_orderbook) and other levels (L2, L4) by specifying L3 and historical nature. Lists returned fields (order IDs, user addresses, prices, sizes) for precision.
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?
Implied context: historical snapshots vs. current data, and Pro+ tier restriction. But no explicit when-to-use or when-not-to-use compared to siblings like get_lighter_l3_orderbook (real-time) or get_lighter_orderbook_history (likely L2). Alternatives not named.
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?
Annotations already confirm readOnly, non-destructive, idempotent, and open-world behavior. The description adds value by specifying output type (L2 snapshots with bids/asks) and granularity options, which are behavioral traits beyond the annotations. It does not contradict 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?
Two concise sentences that front-load the purpose and then add a key feature (granularity). Every sentence is necessary and 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 tool has an output schema (not shown but noted), the description properly covers functionality: historical L2 snapshots with time range and resolution. It does not mention pagination (cursor) but that is in the schema. The description is sufficient for an agent to understand the tool's role.
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 all parameters described. The description briefly restates the granularity enum but adds no new semantic 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 specifies the tool retrieves historical Lighter.xyz orderbook snapshots (L2 level) with bids/asks over a time range. This is a specific verb-resource combination that distinguishes it from other orderbook history tools for different exchanges or levels.
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 implicitly suggests use for Lighter.xyz L2 historical data, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like get_l2_orderbook_history or get_lighter_l3_orderbook_history. No exclusions or alternatives 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. The description adds only that it 'returns the latest trades' without time range, which does not contradict annotations but adds limited behavioral insight beyond them.
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, no unnecessary words. Every sentence provides essential information about the tool's function and key differentiator.
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 an output schema present, the description does not need to explain return values. It covers the core function (latest trades, no time range). Could be slightly more specific about what 'recent' means, but overall adequate for selection.
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 has 100% description coverage for both parameters. The description does not add meaning beyond the schema—it mentions 'for a coin' but no additional details. Baseline 3 due to high schema 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 verb 'Get', the resource 'most recent Lighter.xyz trades', and the scope 'for a coin'. It distinguishes from sibling tools like get_lighter_trades by noting 'without needing a time range', making its 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 implies use for retrieving the latest trades without a time range, contrasting with get_lighter_trades. However, it lacks explicit guidance on when not to use or alternatives like get_hip3_trades_recent. Still, the key differentiator 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?
Annotations already provide readOnly, idempotent, non-destructive hints. The description adds value by noting data availability from May 2025 and clarifying output volumes. 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?
Two sentences that are direct and front-loaded: first sentence states purpose and aggregation, second states output and data availability. 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 6 parameters, output schema, and annotations, the description covers the essential aspects. It omits disambiguation from the sibling get_hip3_liquidation_volume, but overall it is 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%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides, e.g., interval enum 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's function: 'Get aggregated liquidation volume for a coin in time-bucketed intervals' with specific output details (total, long, short USD volumes). It distinguishes from siblings like get_liquidations (raw events) by specifying aggregation.
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 aggregated time-series data but does not explicitly state when to use this tool over alternatives like get_liquidations or get_liquidations_by_user. No exclusions or comparison are provided.
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?
Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds that it returns aggregated metrics over intervals and notes the 'Build+ tier', providing context beyond the 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?
A single, well-structured sentence that front-loads the core purpose and includes a brief expansion on return content. No superfluous 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?
Given complete annotations and an output schema, the description is nearly sufficient. It lacks details on access restrictions (Build+ tier) and how to interpret the aggregated metrics, but overall meets 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%, so baseline is 3. The description only loosely maps to 'time intervals' for the interval parameter, adding minimal extra 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?
The description clearly states the tool aggregates order flow metrics (placements, cancellations, fills) over intervals, distinguishing it from sibling tools like get_order_history or get_trades that provide raw data.
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 for aggregated order flow analysis but does not explicitly compare to siblings (e.g., get_hip3_order_flow) or state when to prefer this tool. No prerequisites or exclusions are 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?
Annotations already confirm read-only, non-destructive, idempotent behavior. The description adds useful context: it returns specific event types, user addresses, and notes data is live from a specific date. Minor gap: no mention of pagination behavior or rate limits.
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 clear front-loading of purpose, then details on symbol format and data availability. 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?
With eight parameters and an output schema, the description covers purpose, symbol format, event types, user attribution, and data availability. It does not explain pagination or rate limits, but these are minor omissions given the output schema exists.
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 description does not need to explain parameters. It adds context on symbol format and event types but these are not parameter-specific. Meets baseline for high schema 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 retrieves spot order lifecycle events with user attribution, specifies symbol format (dashed canonical), lists event types, and mentions Pro+ tier and data availability date. This distinguishes it from siblings like get_order_history (perpetuals) and get_spot_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 spot order history with user attribution but does not explicitly state when to use this vs alternatives (e.g., get_order_history for perpetuals, get_spot_trades for trade-only). No when-not-to-use guidance is provided.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds value by specifying the data source ('L4 order stream') and start date ('2026-05-05'), which goes beyond what annotations provide.
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 purpose, followed by return fields and metadata. Every sentence adds value with 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 existence of an output schema and complete annotations, the description adequately covers purpose, data source, and temporal scope. It lacks explanation of TWAP status values but 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 coverage is 100% with detailed descriptions. The description adds minimal extra meaning (e.g., reinforcing dashed canonical format) but does not significantly enhance understanding 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 verb 'Get', the resource 'Hyperliquid Spot TWAP statuses', and the scope 'for a single pair' with dashed canonical symbols. This effectively distinguishes it from siblings like get_spot_twap_by_user.
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 a single symbol pair but does not explicitly state when to use this tool over alternatives (e.g., get_spot_twap_by_user for user-based queries). No when-not-to-use guidance is provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which describe the tool's safety profile. The description adds extra behavioral context: data source (L4 order stream) and a specific live start date. No contradictions with 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 three sentences, front-loaded with the primary action and resource. Every sentence adds value: purpose, returned fields, source and temporal scope. No redundancy or filler.
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 presence of an output schema, the description sufficiently covers purpose, source, and key returned fields. It omits details like pagination or default time ranges, but these are covered by the input schema. The description is adequate for a well-annotated 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?
Input schema has 100% description coverage, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema (e.g., only mentions 'address' implicitly as 'single user wallet'). No extra semantics provided.
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's purpose: retrieving Hyperliquid Spot TWAP statuses for a single user wallet across every spot pair. It specifies the returned fields and distinguishes from sibling tool get_spot_twap_by_symbol by focusing on user-level aggregation.
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 a single user wallet across all spot pairs, hinting at differentiation from get_spot_twap_by_symbol (by symbol). However, it lacks explicit when-to-use, when-not-to-use, or alternative tool guidance. The mention of live data from 2026-05-05 is useful for temporal 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?
Annotations already indicate a safe, read-only operation. The description adds value by detailing the returned data (mark price, oracle price, etc.), providing context beyond the 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?
Two sentences, front-loaded with the main purpose, followed by a concise list of fields. 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?
For a simple input with an output schema, the description lists the key return fields, providing sufficient context for an agent. Could mention output schema details, but that is covered by the schema itself.
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 single parameter 'coin' is fully described in the schema with examples. The description does not add new semantic meaning beyond what the schema provides (100% 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 it gets a 'combined market summary for a coin in a single call' and lists the specific returned fields, distinguishing it from sibling tools that return individual metrics (e.g., get_funding_current, get_open_interest).
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 it is a convenience for multiple fields but does not explicitly state when to use it versus alternatives or provide exclusions. Usage context is inferred but not stated.
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?
Annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) already indicate safe read behavior. The description adds value by detailing returned fields (trigger prices, user addresses, triggered status), which supplements the annotations with concrete output 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?
Single sentence, front-loaded with key information (verb, resource, tier, return fields). 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?
The output schema exists, so return value details are covered. The description mentions the returned fields and tier restriction. Missing explicit mention of pagination (cursor, limit) and filtering (user, triggered) but these are in the schema. Complete enough given structured fields.
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 has 100% description coverage for all 7 parameters, each with clear descriptions. The tool description does not elaborate on any parameter details beyond what the schema provides, so it neither adds nor detracts significantly. 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?
Clearly states the tool retrieves Hyperliquid TP/SL order history, lists the fields returned (trigger prices, user addresses, triggered status), and specifies the Pro+ tier requirement, distinguishing it from sibling tools like get_hip3_tpsl and get_hip4_tpsl.
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?
Mentions 'Pro+ tier' implying access restrictions but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are named among the many sibling tools, and pagination/filtering aspects are not mentioned.
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?
Annotations are sparse (readOnlyHint=false, destructiveHint=false, idempotentHint=false). Description does not disclose consequences of revoking (e.g., irreversible, immediate effect, related permissions). With destructiveHint=false but action being destructive, description should clarify; it doesn't. Lacks behavioral context beyond basic action.
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: first states purpose, second gives usage guidance. No redundant words, well-structured.
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?
Output schema exists, so return values are documented. Description covers prerequisites and source of key_id. It could mention that revoking is irreversible or that it invalidates the key immediately, but overall sufficient for a simple 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?
Input schema covers all 3 parameters with descriptions (100% coverage). Description reiterates that key_id comes from web3_list_keys, which adds minor context, but does not explain message/signature further. Baseline 3 due to high schema 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?
Clearly states 'Revoke a specific API key' which is a specific verb and resource. It distinguishes from sibling tools like web3_list_keys (list), web3_challenge (auth), web3_signup, web3_subscribe.
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 prerequisites: 'Requires a fresh SIWE challenge signed with personal_sign' and 'Use web3_list_keys first to get the key_id'. Clearly tells the user what to do before invoking this tool.
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?
Annotations already indicate readOnly, non-destructive, idempotent, and open-world behavior. The description adds value by specifying the exact metrics returned (e.g., current, 1h avg, 24h avg for WebSocket latency, REST API latency, and per-type data freshness). 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?
A single sentence that front-loads the core action and details. Every word provides value; 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?
With no parameters, annotations present, and an output schema, the description gives sufficient detail about what the tool returns. The rule states that if output schema exists, return value explanation is not needed, so completeness is high.
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?
Input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter semantics. Baseline 4 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 current latency metrics for venue APIs, listing specific metrics (WebSocket latency, REST API latency, data freshness lag per data type). This distinguishes it from sibling tools that focus on other data (candles, orderbooks, etc.).
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 siblings like 'get_freshness' or 'get_data_quality_status'. The description does not provide context about appropriate use cases 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, fully covering safety. The description adds useful context about returned fields (prices, funding rate, open interest) and case-sensitivity, but does not disclose additional behavioral traits beyond what annotations provide.
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 (two sentences) and front-loaded: first sentence states purpose, second adds key details. Every word contributes value with no redundancy or fluff.
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 a single required parameter, full schema coverage, and an output schema (context indicates exists), the description is complete. It explains what the tool does and what it returns, leaving no gaps for a simple summary 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%, and the description repeats the case-sensitivity note already in the schema. It does not add new semantic meaning for the 'coin' parameter 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 the verb 'Get', the resource 'combined HIP-3 market summary for a coin', and specifies it returns multiple metrics (mark price, oracle price, etc.). This distinguishes it from sibling tools that retrieve individual metrics, 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 implies efficiency by offering a combined summary in a single call, but it does not explicitly state when to use this tool versus separate tools for each metric. It provides examples and case-sensitivity hints, which aid usage, but lacks explicit when-not 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?
Annotations already declare readOnly, idempotent, non-destructive. The description adds useful behavioral traits: symbols are case-sensitive and the tool returns the latest trades without needing a time range. No contradictions with 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 extremely concise with three short sentences, no redundancy, and front-loaded purpose. Every sentence adds value: purpose, case-sensitivity, and key usage note.
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 simple tool with rich annotations and a full schema, the description covers basic purpose and key note. However, it lacks explicit differentiation from the sister tool 'get_hip3_trades' and does not define 'most recent' (e.g., time window). This is adequate but not 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 description coverage is 100%, so baseline is 3. The description repeats the case-sensitivity and example for 'coin' and default for 'limit', but does not add new meaning beyond what is already in the schema. The context about 'without needing a time range' is not a parameter but usage guidance.
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 'most recent HIP-3 trades', which is specific and distinguishes it from siblings like 'get_hip3_trades' (which likely requires a time range). The case-sensitivity note adds 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?
The description implies when to use (for latest trades without a time range) and differentiates from historical queries. However, it does not explicitly name the alternative tool (get_hip3_trades) or provide 'when not to use'. The context is clear but lacks explicit exclusion.
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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint; description adds that instruments are per side and the numeric format, which provides useful context beyond 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?
Two sentences, no fluff, front-loaded with purpose, and efficient in conveying essential information.
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 output schema exists, description fully covers the tool's purpose and format, enough for an agent to discover valid symbols without missing information.
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?
No input parameters required; schema coverage is 100% (empty schema). Description adds value by explaining output format (one row per side, numeric format), though parameter semantics are trivial.
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 lists all available HIP-4 outcome-market instruments, distinguishes from singular get_hip4_instrument by emphasizing 'list all' and discovery of valid symbols.
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?
Explicitly says 'Use this to discover valid HIP-4 symbols', implying when to use, but does not mention when not to or alternative tools; usage context is clear but limited.
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 adds the Pro+ tier requirement and confirms the return content (full order-level book with user addresses), complementing annotations that already declare readOnly, safe, and idempotent behavior. 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?
Two succinct sentences front-loading the core purpose and return structure, with no redundancy. 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?
Given the output schema exists, the description sufficiently covers the tool's purpose, return content, and the Pro+ tier requirement. No gaps for a snapshot retrieval function.
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. The description reinforces coin format but does not add significant new meaning beyond the schema. Adequate but not exceptional.
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 a HIP-4 L4 orderbook reconstruction with specific details (order IDs, user addresses, prices, sizes), distinguishing it from sibling tools like get_hip4_orderbook or get_hip4_l4_orderbook_history.
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 mentions 'Pro+ tier' as a prerequisite but does not explicitly guide on when to use this tool vs alternatives (e.g., L2 orderbook, history tools). Usage context is implied through the description of the data returned.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, so the description only needs to add context beyond these. It adds that the tool returns time-bucketed metrics and requires Pro+ tier, which is valuable behavioral context not covered by 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?
Two sentences: first states purpose and tier, second explains return types and legacy coin forms. No redundant words, information density is high.
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?
An output schema exists, so return values are already detailed. The description covers the main purpose, tier requirement, and data type. Pagination and parameters are handled by the schema. For a 6-parameter tool, this is 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 description adds little beyond what the schema already provides. It mentions legacy coin forms and default time range, but these duplicate schema descriptions. 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 ('HIP-4 order flow aggregation') with clear scope ('Pro+ tier', 'for a coin'). It distinguishes the tool from siblings by focusing on aggregated order flow metrics, not raw trades or order books.
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 Pro+ tier restriction but does not explicitly compare this tool to alternatives like get_hip4_trades or get_hip3_order_flow. There is no guidance on when to use this versus other order flow or HIP-4 tools, leaving the agent to infer from names.
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?
Annotations already indicate read-only, idempotent, and non-destructive. Description adds return structure details beyond annotations, but does not disclose potential edge cases or performance 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, no fluff. Key information is front-loaded: action, resource, return type.
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?
Tool is simple (single parameter, read-only). Output schema exists. Description covers core functionality and return fields adequately for agent 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% and describes outcome_id suffix logic. Description merely restates 'by outcome_id' without adding new semantic 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 it gets a single HIP-4 outcome by outcome_id and specifies the return fields (full Hip4OutcomeAggregate with aggregated_oi details). Distinguishes from sibling 'get_hip4_outcomes' by focusing on single item retrieval.
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 when-to-use or alternatives provided. While sibling list implies use for single outcome vs list, description does not guide selection or state prerequisites.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds behavioral context by listing returned fields (leverage, decimals, active status) and confirms a read operation, providing value beyond 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 a single, well-structured sentence with no extraneous text. It front-loads the core action and resource, making it efficient for an agent 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?
For a simple, single-parameter tool with full annotations and an output schema, the description is sufficient. It clearly states the purpose and key return fields, filling the gaps without over explaining.
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 parameter description. The description's 'by coin symbol' adds no new meaning beyond what the schema 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?
The description clearly states the verb 'Get details' and specific resource 'single Hyperliquid instrument by coin symbol', with return fields listed. It effectively differentiates from sibling `get_instruments` (plural) and other instrument tools by specifying singularity and coin symbol input.
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 for a single instrument but lacks explicit guidance on when to select this tool over alternatives like `get_hip3_instrument` or `get_instruments`. No when-not-to-use or alternative naming provided.
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?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds value by specifying that it shows last update time and current lag for multiple data types, providing behavioral context beyond the 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 that are front-loaded and concise. Every sentence adds value 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?
Given the tool has a single parameter with full schema coverage and an output schema exists, the description is complete. It explains the purpose, scope, and output nature sufficiently.
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 covers the coin parameter with a clear description (symbol, examples). The description mentions coin but does not add new semantic 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 uses a specific verb ('Get') and resource ('data freshness for a Lighter.xyz coin'), listing concrete data types (orderbook, trades, funding, OI) and what is shown (last updated and current lag). This clearly distinguishes it from siblings like get_freshness or other lighter-specific 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 usage for Lighter.xyz coins by naming the exchange, but it does not explicitly state when to use this tool over alternatives like get_freshness or other get_*_freshness tools. No when-not-to-use or prerequisites are 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?
Annotations already declare readOnly, non-destructive, idempotent, open-world. The description adds return field context, which is useful beyond annotations. 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?
Two sentences: first states purpose, second lists return fields. Every word earns its place, no fluff.
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 retrieval tool with one parameter and an output schema, the description covers purpose, return fields, and example inputs. Output schema likely documents field 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% and parameter 'coin' already described as symbol. Description reiterates 'e.g. 'BTC', 'ETH'' but adds no new 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?
The description clearly states the tool retrieves details for a single Lighter.xyz instrument by coin symbol, listing returned fields (market ID, fees, decimals, active status). It distinguishes from sibling tools like get_lighter_instruments (plural) and get_instrument (non-Lighter).
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 for single instrument lookup but does not explicitly state when to use alternatives (e.g., get_lighter_instruments for multiple) or provide any exclusions.
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?
Annotations already declare read-only, non-destructive, idempotent, and open-world hints. The description adds that it returns 'timestamped OI snapshots', which is useful context beyond annotations. 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?
Two concise sentences, front-loaded with the purpose, no unnecessary words. 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?
Given the rich annotations, output schema, and 100% parameter coverage, the description is complete enough. It briefly explains the output format, which is sufficient for this straightforward read 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 the description does not need to add much. It adds only the return format context but no parameter-level details 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?
The description clearly states 'Get Lighter.xyz open interest history for a coin over a time range' with a specific verb and resource. It distinguishes from siblings like get_lighter_open_interest (current) and get_open_interest_history (non-Lighter).
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 vs alternatives. The usage is implied by the name and description, but no when-not or alternative suggestions are provided.
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?
Annotations already indicate safety (readOnlyHint=true, destructiveHint=false). The description adds value by noting the Pro tier requirement, which is a behavioral constraint not captured in annotations. There is no contradiction.
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 covering purpose, returns, optional depth, and a constraint. Every sentence adds value without redundancy or fluff.
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 snapshot tool with an output schema, the description sufficiently covers purpose, parameters, returns, and a notable constraint (Pro tier). No gaps are evident.
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 minimal information beyond the schema: 'coin' is a symbol, 'depth' is number of price levels. No additional semantics are provided, 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 'Get the current Lighter.xyz orderbook snapshot for a coin' with specific verb and resource. It explicitly lists returned fields (bids, asks, mid price, spread) and mentions optional depth. The name and description distinguish it from sibling orderbook tools by specifying 'Lighter.xyz'.
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 context for usage by noting the optional depth parameter and the Pro tier requirement for full depth. However, it does not differentiate this tool from similar siblings like get_lighter_l3_orderbook or get_lighter_orderbook_history, nor does it indicate when to use this over others.
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?
Annotations already declare read-only, non-destructive, idempotent, and open-world hints. The description adds that results include both user-as-victim and user-as-liquidator, which is useful but not extensive beyond 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?
Two sentences, front-loaded with the core action, no fluff. 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?
Given the simple read-only retrieval nature, rich annotations, and full schema coverage, the description is complete. It covers user filtering and optional coin filter, which is 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?
All 6 parameters are described in the input schema (100% coverage). The description only mentions the optional coin filter, adding no significant new 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?
The description clearly states the tool retrieves liquidation history for a specific user address, distinguishing it from general liquidation tools like get_liquidations. It also specifies that results include both sides (liquidated or liquidator) and optional coin filtering.
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 use for a specific user address, but does not explicitly compare to siblings like get_liquidations or get_liquidation_volume. However, the context is clear enough for an agent to infer appropriate usage.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying the exact output fields, which further clarifies the tool's behavior without contradicting 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 only two sentences, front-loaded with the core purpose, and includes essential return details. Every word is necessary and no filler.
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 tool with one parameter and a clear output schema, the description completely covers what the tool does and what it returns. No missing information.
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 fully describes the 'coin' parameter with examples. The description does not add any additional context or meaning beyond the schema, so it meets 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 it retrieves the current open interest for a coin and lists the specific return fields (OI, mark price, oracle price, 24h volume). This distinguishes it from sibling tools like get_open_interest_history.
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?
While the description implies it's for current data, it does not explicitly mention when to use alternatives such as get_open_interest_history or other HIP3/Lighter variants. No explicit 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?
Annotations already indicate read-only, idempotent, open world. Description adds valuable context beyond annotations: the live date (2026-05-05) and the Pro+ tier requirement for full depth, which are important behavioral details.
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?
Description is four sentences, front-loading the core purpose in the first sentence, then efficiently covering returns, optional parameter, and access requirement. No unnecessary words.
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?
With an output schema present, the description adequately covers the tool's purpose, return values, and key constraints (depth optional, tier requirement). No gaps given the simplicity of the 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 reiterates symbol format and depth description, adding no 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?
Description explicitly states it retrieves the current Hyperliquid Spot L2 orderbook snapshot for a pair, specifies symbol format, and lists returned data (bids, asks, mid price, spread). This clearly differentiates it from siblings like get_spot_orderbook_history or get_l2_orderbook.
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?
Description mentions optional depth and a Pro+ tier requirement for full depth, giving some context on when to use, but does not explicitly compare or contrast with siblings or state when not to use this tool.
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?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds valuable context: S3 backfill from 2025-03-22, live since, cursor pagination. No contradiction with 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?
Five concise sentences, each adding value: purpose, symbol format, returned fields, data source, pagination/filtering. No wasted words.
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 output schema exists and parameters are fully described, the description covers all important aspects: purpose, data source, returned fields, pagination, optional filter. Very 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 3. Description adds some detail on coin parameter format and default start/end, but largely repeats schema info.
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 Hyperliquid Spot trade/fill history for a pair over a time range', clearly stating verb, resource, and scope. It distinguishes from siblings like get_spot_trades_recent by mentioning time range and history.
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?
Description implies usage for historical spot trades with filtering and pagination, but does not explicitly state when to use vs. alternatives like get_spot_trades_recent or other trade 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?
Annotations already mark the tool as read-only and idempotent. The description adds behavioral context beyond annotations by specifying that it returns coverage gaps and cadence metrics, and implies analysis of data gaps. No contradiction with 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?
Two sentences, front-loaded with the core purpose, followed by detailed return information. No redundant or unnecessary text.
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 4 parameters, complete annotations, and an output schema, the description provides enough context about what the tool returns (earliest/latest, gaps, cadence) without needing to replicate the 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 description coverage is 100%, so the schema already documents all parameters. The description does not add new parameter-level information beyond what the schema provides. Baseline 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 verb ('Get'), the resource ('detailed data coverage for a specific symbol on a venue scope'), and lists specific return metrics (per-data-type coverage, earliest/latest, total records, completeness, gaps, cadence). This distinguishes it from siblings like get_exchange_coverage and get_data_coverage.
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 context for when to use the tool (when you need detailed per-symbol coverage on a venue), but does not explicitly state when not to use it or mention alternatives. It lacks exclusionary 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by detailing the exact data returned (earliest/latest timestamps, total records, symbol count, resolution, lag, completeness) and the scoping (per data type per venue). No contradictions with 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 a single, well-structured sentence that front-loads the main purpose ('Get data coverage across supported venue APIs') and immediately lists the return fields. Every word contributes meaning; no filler.
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 parameters and an existing output schema, the description covers the main return fields and scoping. However, it might benefit from mentioning if there are any limitations (e.g., date range constraints) or whether the data is real-time or cached. Still, it is fairly complete for a parameterless tool.
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 input schema has zero parameters, so schema coverage is trivial (100%). Description does not need to explain parameter semantics. Baseline for 0 params is 4, and the description appropriately omits parameter info.
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 the resource 'data coverage', and lists specific returned fields (timestamps, records, symbol count, etc.). It distinguishes from siblings like get_symbol_coverage and get_exchange_coverage by focusing on aggregate coverage per data type per venue.
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 does not explicitly state when to use this tool versus alternatives like get_symbol_coverage or get_data_quality_status. It implies usage for overall data coverage but lacks guidance on exclusions or when-not scenarios.
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?
Annotations already indicate read-only, non-destructive, idempotent. Description adds value by detailing the report contents (e.g., target vs actual, met/missed status) beyond annotations, providing context on what to expect.
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 purpose and key details. Every sentence serves a clear 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?
Description lists all key metrics and status information. Output schema exists so return format is covered. Lacks details on potential edge cases (e.g., missing month data) but overall sufficient 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?
Schema covers both parameters with descriptions; description only mentions 'given month' which adds little beyond schema. Baseline 3 applies as schema coverage is 100% and description does not significantly enhance parameter meaning.
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 retrieves an SLA compliance report for a month, listing specific metrics (uptime, data completeness, API latency P99) with target vs actual and met/missed status, plus incident count and downtime. This is distinct from siblings like get_data_latency or get_data_incidents which focus on individual 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 implies usage for monthly SLA overview but does not explicitly mention when not to use or name alternatives. Given siblings, the purpose is clear enough, but lacks explicit guidance for exclusion.
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?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds value by stating 'Returns price-level changes' and 'tick-level orderbook diffs', clarifying the output behavior beyond 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?
Two sentences, front-loaded with purpose and tier. No redundancy. Every sentence contributes meaningful 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 output schema exists, description doesn't need to detail return format. It adequately conveys that diffs are price-level changes. Missing explicit mention of pagination, but schema covers cursor. Overall complete.
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 has 100% description coverage. Description reinforces case-sensitivity and adds market context (125+ markets, 6 builders, examples). This adds value beyond the 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?
Description clearly states verb 'Get', resource 'HIP-3 L2 tick-level orderbook diffs', and notes Pro+ tier. It distinguishes from siblings like get_hip3_l2_orderbook by specifying 'diffs' and 'price-level changes'.
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?
Implied usage via 'Pro+ tier' and 'tick-level orderbook diffs', but no explicit when-to-use or when-not-to-use compared to alternatives like get_hip3_l2_orderbook. The coin parameter references get_hip3_instruments for listing symbols, which aids usage but is not a direct guideline.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful behavioral traits: Pro+ tier requirement and case-sensitive symbols. It does not mention rate limits or pagination behavior, but with annotations present, the bar is lower.
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. First sentence covers purpose and tier, second adds critical usage detail (case-sensitivity) and what is returned. Perfectly 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 presence of an output schema and rich annotations, the description covers the essentials: purpose, tier, case-sensitivity, time range. However, it omits mention of pagination (cursor parameter) and does not clarify how 'diffs' differ from full snapshots. Minor gap but sufficient for a well-annotated, schema-rich 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 adds the 'Pro+ tier' context and reinforces case-sensitivity with examples, but does not significantly augment the parameter meanings beyond what the schema provides. Hence 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 the verb ('Get'), resource ('HIP-3 L4 orderbook diffs'), and scope ('over a time range'). It distinguishes from siblings like get_hip3_l4_orderbook (full snapshot) and get_hip3_l4_orderbook_history (historical snapshots) by focusing on incremental changes.
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?
It provides clear context: Pro+ tier requirement, case-sensitive symbols, examples, and a reference to get_hip3_instruments for listing symbols. However, it does not explicitly contrast with alternatives like get_hip3_l4_orderbook or get_l4_diffs, leaving some guesswork for the agent about when exactly to choose this tool.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that tool returns periodic full order-level snapshots and notes case sensitivity. Does not contradict 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?
Two concise sentences front-loading key information: purpose, tier, case sensitivity, and return type. No unnecessary words or repetition.
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 full schema coverage, annotations covering safety, and presence of an output schema, the description is complete enough for a read-only historical query tool. Mentions the Pro+ tier requirement and case sensitivity, which are critical 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?
Input schema has 100% description coverage for all 5 parameters. Description adds no additional parameter information beyond what schema 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?
Clearly states the tool retrieves HIP-3 L4 orderbook checkpoints, specifies it's Pro+ tier, and mentions case sensitivity. Distinguishes from siblings like get_hip3_l4_orderbook (current snapshot) and get_hip3_l4_diffs (diffs) by emphasizing historical snapshots.
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?
Indicates usage for historical orderbook snapshots, implying not for real-time current book (use get_hip3_l4_orderbook). Mentions Pro+ tier and provides example symbol. Could be more explicit about when not to use, but adequate for basic 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?
Annotations already provide readOnlyHint, so the description adds value by stating it returns 'order lifecycle events with user addresses' and that symbols are case-sensitive. No contradiction with 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?
Two concise sentences, front-loaded with purpose and a key usage note. Every sentence adds value; 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 8 parameters, output schema existence, and many siblings, the description covers core purpose, a critical constraint (case-sensitivity), and tier. It does not elaborate on filtering or pagination, but those are documented in 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?
Input schema has 100% coverage, describing all 8 parameters. The description adds emphasis on case-sensitivity and examples for the coin parameter, but does not provide additional meaning beyond the schema for other 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 HIP-3 order history with user attribution, mentions Build+ tier, and highlights case-sensitivity. It distinguishes from sibling tools like get_order_history (generic) and get_hip4_order_history by specifying HIP-3.
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 implies usage for HIP-3 orders and Build+ tier, and emphasizes case-sensitivity. However, it does not explicitly guide when to use this over alternatives like get_order_history or get_spot_order_history, nor does it mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that the tool shows 'when each data type was last updated and current lag', which is valuable behavioral context about the output. 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?
Two concise sentences: first sentence states purpose and scope, second provides param format and output summary. 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 tool with one parameter and an output schema, the description covers the key aspects: what it does, accepted input formats, and output content. Could optionally mention that output schema provides exact structure, but not necessary.
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 describes the coin parameter well (canonical form, legacy forms). The description supplements by explicitly accepting legacy '#0' and '%230' forms, adding clarity 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 HIP-4 data freshness for a coin across multiple data types (orderbook, trades, OI, L4). It is specifically differentiated from sibling freshness tools (e.g., get_freshness, get_hip3_freshness) by the 'HIP-4' prefix.
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 HIP-4 outcome-market coins, but does not explicitly state when to use this tool over alternatives like get_hip3_freshness or get_freshness. No exclusion or alternative guidance is provided.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description is not required to repeat safety traits. It adds value by noting the 'Pro+ tier' access restriction and specifying that it returns 'new orders, modifications, cancellations, fills', which discloses the nature of the data. No contradictions with 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 brief yet complete, consisting of three focused sentences. The first sentence states the primary action, the second clarifies the input format, and the third describes the output. Every sentence contributes to understanding without 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 existence of an output schema and detailed parameter descriptions, the description covers the essential functional aspects. It could be improved by adding guidance on when to use diffs versus full orderbook or history tools, but it is largely adequate for a read-only tool with rich annotations and 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 coverage is 100% and includes descriptions for all parameters. The description adds extra context for the coin parameter (canonical vs legacy forms) and cross-references get_hip4_instruments for listing coins, which enhances understanding beyond the schema. Other parameters are adequately covered by 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 HIP-4 L4 orderbook diffs for a specific coin, using a specific verb-noun structure. It distinguishes from siblings by specifying 'diffs' as opposed to full snapshots or history, and provides a concrete example (e.g., '0').
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 tracking order-level changes via 'raw order-level changes' and 'over a time range', but does not explicitly state when to prefer this over alternatives like get_hip4_l4_orderbook or get_hip4_order_flow. No exclusions or direct comparisons are provided.
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?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds important behavioral context: mark_price is an implied probability (0..1) not USD, and Pro+ tier is required. This helps the agent understand special 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 three sentences, with the main purpose front-loaded. Every sentence provides essential information without redundancy or verbosity.
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 coin format variations, mark_price interpretation, and tier requirement. It does not mention the depth parameter, but the output schema likely covers return structure. Overall sufficient for a simple snapshot 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. The description provides example coin formats and notes legacy forms, which reinforces the schema but adds minimal new semantic meaning 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 retrieves a HIP-4 L2 orderbook snapshot for a coin, with specific examples of coin formats and a note on mark_price interpretation. It semantically distinguishes from siblings like get_hip4_l4_orderbook (L4) and get_hip3_orderbook (HIP-3).
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 implies usage for current L2 orderbook data vs. historical (get_hip4_orderbook_history) and L4 (get_hip4_l4_orderbook), but does not explicitly state when to use this tool over siblings. It does mention a prerequisite (Pro+ tier).
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?
Adds significant context beyond annotations: outcome grouping ('<10*id>' Yes / '<10*id+1>' No), WebSocket event notification, and omission of aggregated_oi. No contradictions with 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?
Three concise sentences with front-loaded purpose. No redundant phrases. 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?
Covers key behavioral details (grouping, WebSocket, OI omission) and references sibling. With output schema present, return values are covered. Slight lack of pagination details, but overall 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 all parameters described. The description only reiterates the is_settled filter and implies pagination with cursor, adding minimal extra meaning.
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 'List HIP-4 outcome markets aggregated across both sides' with a clear verb and resource. It distinguishes from sibling get_hip4_outcome by noting this tool omits aggregated_oi.
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 context: optional filtering by settlement status, WebSocket event for updates, and direction to get_hip4_outcome for OI. However, no explicit when-not statements or comparisons to other siblings.
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?
Annotations already indicate readOnly, non-destructive, idempotent behavior. The description adds context about accepting legacy coin formats and using cursor pagination, which is helpful beyond 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?
Two sentences: first clearly states purpose, second adds essential details on coin formats and output nature. No redundancy, front-loaded, 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 rich schema and output schema existence, the description adequately covers the tool's role. It mentions time range and pagination but omits details on interval aggregation defaults; however, these are covered in the 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 has 100% coverage with descriptions, baseline 3. The description adds value by explaining coin canonical/legacy forms and that output is timestamped snapshots with cursor pagination, enhancing understanding of 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?
Description clearly states the tool retrieves HIP-4 mid-price (implied probability 0..1) history for a coin, distinguishing it from other HIP-4 tools like order books 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 when-to-use or alternatives are mentioned, but the tool name and description imply its use for historical price data. Lacks guidance on when to prefer this over other HIP-4 tools or how to choose between 'get_hip4_prices' versus 'get_hip4_instrument' for current prices.
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?
Annotations already indicate readOnly, destructive, idempotent, and openWorld hints. The description adds useful context: returned fields (addresses, price, size, side, PnL), data availability from May 2025, and WebSocket alternative. No contradictions, and adds value beyond 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 three concise sentences: first states purpose and output, second notes data availability, third mentions WebSocket alternative. Front-loaded and 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?
With an output schema present, the description doesn't need to detail return structure. It covers key fields, data availability, and a real-time alternative. However, it could explicitly differentiate from get_liquidations_by_user for 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?
Input schema covers all 5 parameters with descriptions, so schema_description_coverage is 100%. The tool description does not add parameter-level details. It lists return fields but not parameter specifics. 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 gets liquidation history for a specific coin over a time range. It distinguishes itself from sibling tools like get_liquidations_by_user (by user) and get_liquidation_volume, and mentions WebSocket for real-time 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 implies historical use and contrasts with real-time WebSocket. However, it does not explicitly state when to use this tool over siblings like get_liquidations_by_user or get_liquidation_volume. It provides clear context for the main use case.
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?
Annotations already indicate read-only, idempotent, open world. Description adds that it returns order lifecycle events with user addresses, providing useful behavioral context beyond 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?
Two sentences: first states purpose and tier, second describes output. Efficient and 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?
Description covers purpose, tier, and output content. Output schema exists, so return details are handled. Lacks explanation of pagination or filtering options, but these are in 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 100% of parameter descriptions, so baseline is 3. Description adds overall context about what the data represents (lifecycle events, attribution), which aids 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?
Description clearly states 'Get Hyperliquid order history with user attribution (Build+ tier)' and lists specific lifecycle events, distinguishing from sibling tools by specifying tier and user attribution.
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?
Description mentions 'Build+ tier' implying restricted use, but does not explicitly state when to use or alternatives. No guidance on when not 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?
Annotations already mark it as read-only, idempotent, and non-destructive. Description adds that it is live from a specific date (2026-05-05) and returns 'raw order-level changes', which is useful behavioral context beyond annotations. 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?
Two sentences: first states purpose and tier, second explains symbol format and return content, third notes data availability. Zero wasted words, 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?
Given the output schema exists, the description covers purpose, data type, and availability. It does not explain pagination or defaults beyond schema, but these are in parameters. The tool's complexity is moderate and description is sufficient alongside schema and annotations.
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 has 100% coverage with detailed parameter descriptions, including examples and defaults. The description does not add significant meaning beyond the schema; it merely echoes the symbol format. Baseline 3 is appropriate since schema carries the burden.
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?
Explicitly states it gets Hyperliquid Spot L4 orderbook diffs, distinguishes from siblings like get_spot_l4_orderbook (snapshot) and get_l4_diffs (futures) by specifying 'Spot' and 'diffs'. The description also clarifies that it returns raw order-level changes over a time range, making its function unique.
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?
Mentions Pro+ tier tier requirement, providing context for eligibility. Does not explicitly state when not to use alternatives, but the distinction from siblings is clear via naming and description. The description implies it is for diff-based queries rather than snapshots or historical records.
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?
Beyond annotations (readOnlyHint=false, etc.), the description adds behavioral context: the tool generates a challenge message that must be signed via personal_sign (EIP-191) and then used in web3_signup. It clarifies that no browser or email is needed, which aids understanding of the interaction pattern.
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 purpose, and includes essential usage context. Every sentence adds value without 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?
The tool is simple (one parameter) and has an output schema, so the description is largely complete. It could optionally mention challenge expiration or rate limits, but the current description is sufficient for correct 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?
The input schema has 100% description coverage for the single 'address' parameter with a clear example. The description does not add further meaning to the parameter beyond the schema, so a 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 a SIWE (Sign-In with Ethereum) challenge message for a wallet address,' specifying the verb (Get) and resource (SIWE challenge). It distinguishes itself from sibling tools like web3_signup by identifying it as the first step in the API key creation flow.
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: 'first step to create a free API key using only a wallet — no browser or email required.' It also instructs that the returned message must be signed and submitted to web3_signup, providing a clear usage path. No alternatives are mentioned, but the 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?
The description adds the authentication requirement but does not address potential side effects indicated by openWorldHint=true. The readOnlyHint=false annotation contradicts the implied read-only nature of listing keys, but the description does not clarify this.
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: one for purpose, one for prerequisites and return info. Every sentence is necessary and front-loaded, with 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?
The description covers purpose, prerequisites, and return fields. An output schema exists (not shown), so return details are handled. Minor gap: no mention of error cases or expiration handling, but enough for typical use.
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 that 'message' comes from web3_challenge and 'signature' is from personal_sign, going beyond the schema's 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 'List all API keys for a wallet,' using a specific verb and resource. It distinguishes itself from sibling tools like web3_revoke_key and get_* data tools by focusing on key listing with authentication requirements.
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 the prerequisite: 'Requires a fresh SIWE challenge signed with personal_sign.' This provides clear context for when to use the tool, though it does not explicitly contrast with alternatives like web3_revoke_key.
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?
Annotations already mark it as read-only, idempotent. Description adds context: returns OHLCV, default interval 1h, start defaults to 24h ago. No contradiction with annotations. Provides useful behavioral context beyond 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?
Two clear sentences. Front-loaded with main purpose. Every word adds value. No redundancy or 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?
Covers key aspects: data type, intervals, availability, defaults. With an output schema present, return values are handled. However, it does not explain pagination or cursor usage, which is relevant for large datasets. Slightly incomplete but mostly sufficient.
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%, but description adds value by specifying defaults (interval='1h', start='24h ago', limit=100) and explaining output fields (open, high, low, close, volume). This goes beyond the 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?
Clearly states 'Get Hyperliquid OHLCV candle data for a coin.' The verb (get) and resource (OHLCV candle data) are specific. It lists intervals and data fields, distinguishing it from other data tools like get_trades or get_orderbook. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes intervals and data availability from April 2023, but does not provide explicit guidance on when to use this vs sibling candle tools (e.g., get_hip3_candles, get_lighter_candles). No alternatives or exclusions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context such as data available from May 2023 and support for aggregation intervals, going beyond the annotations by specifying the historical scope and optional aggregation.
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 front-load the purpose, detail return content, and then provide additional context. No unnecessary words, 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?
Given the parameter count, full schema coverage, and presence of output schema and annotations, the description is complete. It covers the coin, time range, aggregation, and data availability. No major gaps identified.
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 has 100% description coverage, so the schema already explains all parameters. The description adds useful context about data starting from May 2023 and aggregation intervals, but does not significantly enhance parameter 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?
The description clearly states the tool retrieves Hyperliquid funding rate history for a coin over a time range, specifying it returns timestamped funding rates and premiums. This clearly differentiates it from sibling tools like get_funding_current that provide current 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 clear context on what the tool does and mentions data availability and aggregation intervals, but does not explicitly state when to use it versus alternatives like get_funding_current. However, the distinction is implied by the word 'history'.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral detail: 'Shows when each data type was last updated and current lag,' which informs the agent about the output content beyond 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 extremely concise: two sentences, no redundancy, and front-loaded with the core action. 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?
Given the tool's simplicity (one required parameter, read-only, output schema exists), the description covers the purpose, output content, and usage hints. No gaps remain for an agent to misinterpret.
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 for the single parameter 'coin', including examples and case sensitivity. The description does not add additional meaning beyond what the schema provides, 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 purpose: 'Get data freshness for a HIP-3 coin across all data types (orderbook, trades, funding, OI).' It specifies the verb, resource, and scope, distinguishing it from siblings like get_freshness or get_hip4_freshness.
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 usage guidance by noting case-sensitive symbols and suggesting get_hip3_instruments to list all symbols. It does not explicitly state when not to use, but the HIP-3 specificity and examples offer clear 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds that it returns current data with specific fields (OI, mark price, oracle price). No annotation contradiction.
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 the core purpose, second covers case-sensitivity and return fields. No wasted words, information is 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?
For a one-parameter read tool with output schema, the description covers purpose, usage guidance, returned fields, and symbol format. Annotations provide safety and idempotency. Nothing 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?
The input schema already fully describes the 'coin' parameter with examples and instructions (100% coverage). The description repeats the case-sensitivity hint but adds no new 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 tool gets current HIP-3 open interest for a coin. It specifies case-sensitivity and lists returned fields (OI, mark price, oracle price). This distinguishes it from siblings like get_hip3_open_interest_history (historical) and get_hip4_open_interest (different protocol).
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 emphasizes case-sensitive symbols and provides examples across builders. It explicitly directs to use get_hip3_instruments for listing available instruments. While it doesn't state when not to use this tool, the context is clear for a simple read operation.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that it returns 'timestamped OI snapshots' and mentions time range and aggregation, providing behavioral context beyond annotations. 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?
Two concise sentences with no filler. The primary purpose is front-loaded, and each sentence adds essential information (purpose, case-sensitivity, reference to instrument listing). Perfectly sized.
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 high schema coverage, presence of output schema, and annotations, the description covers all necessary aspects: what it does, key constraints (case-sensitivity), and a pointer to related tool for enumeration. No gaps for a tool of moderate 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 coverage is 100%, so description does not need to add extensive parameter details. It reiterates case-sensitivity and gives examples, which adds marginal value. Baseline 3 is appropriate; no significant additional semantic enrichment.
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 'Get HIP-3 open interest history over a time range', identifying the specific resource (HIP-3 open interest) and action (history retrieval). The mention of case-sensitive symbols and examples further clarifies scope, differentiating it from sibling tools like get_open_interest_history and get_hip3_open_interest.
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 guidance on symbol case-sensitivity and examples, and references get_hip3_instruments for a full list. However, does not explicitly contrast with other open interest history tools (e.g., get_open_interest_history for non-HIP-3), though the naming implies the context. Still, sufficient for an agent to determine proper 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?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds value by stating the return format ('bids/asks over a time range') and data tier access restrictions, which are not in annotations. No contradictions detected. However, it does not disclose potential rate limits or response size limits beyond the 'limit' parameter.
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 three short, focused sentences. The first sentence states the core purpose, the second adds case-sensitivity, and the third clarifies tier restrictions. Every sentence adds necessary information, no fluff or repetition.
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 moderate complexity (6 parameters, output schema present), the description provides sufficient context: what data is returned (L2 snapshots), how to handle case-sensitivity, and tier limitations. Pagination is implied via cursor parameter, and the output schema covers return structure. No further details are needed for correct invocation.
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%, with each parameter described. The description compensates by adding context about the free tier limitation (only km:US500 without Build+ subscription) and emphasizing case-sensitivity for the 'coin' parameter. These details are beyond what the schema provides, raising the baseline from 3 to 4.
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 'historical HIP-3 orderbook snapshots' with L2 bids/asks over a time range. This distinguishes it from sibling tools like get_hip3_orderbook (current snapshot) and get_hip3_l2_orderbook_history (which is similarly named but likely a duplicate or variant). The verb 'Get' and resource 'history' match the name perfectly.
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 case-sensitivity and a free tier limitation ('Free tier: km:US500 only'). However, it does not explicitly differentiate this tool from closely related siblings like get_hip3_l2_orderbook_history or get_hip3_l4_orderbook_history. No guidance on when to choose this over those alternatives, lacking explicit 'use when' or 'use instead' statements.
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?
Adds important behavior beyond annotations: symbols are case-sensitive, and pagination is supported. Annotations already convey safety and idempotency, so the description adds useful 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, front-loaded with purpose, efficient. No extraneous information.
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?
With output schema present and description covering return fields, time range, and pagination, the tool is fully specified 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% and description adds little new meaning beyond restating case-sensitivity and pagination, which are 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?
Clearly states 'Get HIP-3 trade history', specifying the resource (HIP-3 trades) and action. Distinguishes from sibling tools like get_hip3_trades_recent by mentioning 'over a time range'.
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?
Implies usage for historical trade data over a range, but does not explicitly contrast with alternatives like get_hip3_trades_recent or get_trades.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful behavioral context: returns 'timestamped OI snapshots' with mark_price as an implied probability (0..1), and accepts legacy coin forms. No contradictions; provides value beyond 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 extremely concise, with two sentences that cover purpose, coin format, output nature, and sibling alternative. No unnecessary words.
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 presence of a full output schema and 100% parameter coverage in the input schema, the description is sufficient. It correctly identifies the output as timestamped snapshots and provides a key sibling alternative for related use 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?
The input schema has 100% description coverage for all 6 parameters. The description does not add significant meaning beyond what the schema provides for parameters like start, end, limit, cursor, interval. It only repeats coin format info already in 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 verb 'Get', resource 'HIP-4 per-side open interest history', and scope 'for a coin'. It provides a specific example and explicitly differentiates from sibling tool get_hip4_outcome, 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 hints at usage by mentioning start/end defaults and explicitly states when to use get_hip4_outcome instead for paired-set/display OI. However, it does not explicitly contrast with the 'current' variant (get_hip4_open_interest_current), leaving some 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating safe, idempotent reads. The description adds behavioral context: it returns L2 snapshots over a time range, accepts legacy coin formats, and requires Pro+ tier. This supplements the annotations without contradiction.
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 and front-loaded: three sentences cover purpose, coin format, and tier requirement. No extraneous text. Every sentence earns its place, providing essential information 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?
Given the existence of an output schema and comprehensive annotations, the description is complete. It mentions the key functionality (historical L2 snapshots, time range, coin formats, tier). Pagination and parameter defaults are covered in the schema. The description covers all essential aspects 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description echoes the coin format details already present in the schema, adding no new semantic information. As per guidelines, baseline 3 is appropriate as the description does not enhance parameter understanding 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's purpose: 'Get historical HIP-4 L2 orderbook snapshots for a coin'. It specifies the resource (L2 orderbook snapshots), action (historical retrieval), and scope (HIP-4, specific coin). The mention of coin formats and Pro+ tier further clarifies the domain. The name and description effectively distinguish it from similar tools like get_hip4_orderbook (current) and get_hip4_l4_orderbook_history (L4).
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 on when to use the tool: for historical L2 snapshots, with specific coin format guidance ('Bare numeric coins are canonical; legacy forms accepted') and tier requirement ('Pro+ tier required'). However, it does not explicitly compare to siblings like get_hip4_orderbook (for current snapshot) or get_hip4_l4_orderbook_history (for L4), which would improve guidance. The recommendations are clear enough for a straightforward read tool.
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?
Annotations already indicate read-only, idempotent, open-world. Description adds behavioral details: returns price, volume, OI aggregates, and clarifies mark_price is implied probability (0..1) not USD, which is important for correct interpretation. No contradiction with 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?
Two sentences front-load purpose and coin example, then clarify return fields and mark_price semantics. Every sentence adds value with zero waste.
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?
Output schema exists, so description need not detail return structure. It adequately names the key aggregates (price, volume, OI) and resolves ambiguity about mark_price. For a summary tool with good annotations, this is 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 a detailed description of the coin parameter. Description echoes the accepted forms but mainly adds context about the summary itself. With high schema coverage, baseline is 3; description adds some value but is largely redundant on parameter meaning.
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 retrieves a combined HIP-4 24h market summary for a coin, with specific verb 'Get', resource 'HIP-4 summary', and scope '24h'. It distinguishes from sibling summary tools like get_hip3_summary by explicitly naming HIP-4.
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 guidance on coin format (canonical vs legacy forms) and references get_hip4_instruments for listing coins. While it does not explicitly enumerate when to use vs alternatives, the context is clear for a high-level summary tool among many HIP-4 detail 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?
Annotations already declare readOnly, non-destructive, idempotent. Description adds specific fields returned (severity, root cause, etc.), providing useful behavioral context beyond 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?
Two sentences, front-loaded with purpose, no wasted words. Informative and 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?
Tool has output schema, so description need not explain return values. Mentions key fields returned, making it complete for a simple get-by-ID 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 has 100% coverage with a clear parameter description and example. Description adds no extra parameter information 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?
Clearly states verb 'Get' and resource 'specific data quality incident', distinguishes from sibling 'get_data_incidents' by specifying 'by its ID'. Mentions returned details.
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?
Implicitly suggests use when full details of a specific incident are needed. Does not explicitly mention when not to use or name alternatives, but sibling list provides 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds value by specifying the exact data fields returned and the purpose (discovering valid symbols), but does not mention pagination or rate limits, which are minor gaps.
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; no wasted words. Purpose and content are front-loaded, making it easy to scan.
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 list tool with no parameters and a rich annotation set, the description is complete. It conveys what the tool returns, its purpose, and is sufficient for an agent to decide when to use 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?
No parameters exist, so schema description coverage is 100%. The description does not need to explain parameters. Baseline for zero parameters is 4, and the description adds no extra param info, which 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 it lists all available Lighter.xyz instruments with specific fields (market IDs, fees, decimals, active status) and explicitly says 'Use this to discover valid Lighter symbols.' This differentiates it from sibling instrument list tools (e.g., get_instruments, get_hip3_instruments) by specifying the Lighter.xyz context.
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 discovering Lighter symbols but does not provide explicit guidance on when not to use it or alternatives. Among many sibling instrument tools, no comparison is given, leaving the agent to infer 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?
Annotations already declare readOnlyHint true, so the description adds value by specifying returned fields and pagination support. No contradictions. Could mention rate limits or data freshness 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?
Two concise sentences, front-loaded with purpose, no redundant information. Efficiently conveys the core functionality and key features.
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 output schema and comprehensive annotations, the description covers essential aspects: what data is returned, pagination support, and time range capability. No missing critical information for an agent to use the tool.
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?
All parameters are documented in the schema, and the description adds context about returned fields and pagination. The mention of 'price, size, side, and timestamps' helps the agent understand output, though output schema exists.
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 retrieves Lighter.xyz trade history for a coin within a time range, listing specific returned fields. The name includes 'lighter' to distinguish from other trade history tools, making it 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 cursor pagination and time range but does not explicitly guide when to use this tool over siblings like get_lighter_trades_recent or get_trades. The implied use case is historical trades with custom range, but no direct comparison or exclusion criteria.
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?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds behavioral details about showing 'when each data type was last updated and current lag', which goes beyond annotations. 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?
Two sentences, front-loaded with purpose, no redundant information. Every word serves a purpose.
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 one-parameter freshness tool with an output schema, the description covers all essential aspects: target (Spot), data types, symbol format, and what is returned (last updated and lag). It is complete for its 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 schema already documents the 'coin' parameter thoroughly with examples and resolution. The tool description adds no additional parameter-specific 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?
The description uses a specific verb 'Get' and resource 'per-pair data freshness' for Hyperliquid Spot, listing data types and symbol format. It clearly distinguishes from sibling freshness tools by specifying 'Spot', making its scope 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 states it is for Hyperliquid Spot and mentions the symbol format, which helps the agent understand context. However, it does not explicitly contrast with other freshness tools (e.g., get_freshness for perpetuals), though the name and scope are 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?
Annotations already indicate read-only and idempotent. Description adds value by disclosing live coverage start date (2026-05-05, no backfill) and requiring Build+ tier for non-default depth. No contradiction with 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?
Four sentences, each conveying essential information without redundancy. Front-loaded with purpose, then details. No unnecessary words.
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 output schema exists, the description sufficiently covers purpose, parameters, constraints, and data availability. Mentions return type (bids/asks) and key behavioral notes. Complete for its 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 covers 100% of parameters with descriptions. Description adds moderate context for coin (dashed canonical, internal resolution) and clarifies start/end defaults. Does not significantly exceed schema information.
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 gets historical Hyperliquid Spot L2 orderbook snapshots over a time range, specifying the resource and action. It differentiates from siblings by explicitly mentioning 'Spot' and 'L2', and contrasts with other orderbook tools in the sibling list.
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 clear usage context: when historical snapshots are needed, symbol format, and tier requirement for non-default depth. It could explicitly state when not to use (e.g., for current orderbook use get_spot_orderbook), but the context is sufficient for an informed agent.
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?
Annotations already declare readOnlyHint and idempotentHint, so the agent understands safety. The description adds value by detailing exactly what data is returned (mark/mid price, active status, etc.), which goes beyond 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?
A single, well-structured sentence that front-loads the action and includes a list of return fields. No unnecessary words.
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?
With an output schema present and the tool being a simple lookup, the description covers the essential information: purpose, parameter format, and return components. No gaps noted.
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 parameter description is very detailed (example, format, internal resolution). The main description only repeats the example, adding minor value. Baseline score 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 details for a single Hyperliquid Spot pair by dashed canonical symbol, listing specific return fields (base/quote asset, wire symbol, etc.) and distinguishing it from sibling get_spot_pairs.
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 parameter description explicitly directs users to use get_spot_pairs for listing all pairs, providing usage context. However, the main description does not state when not to use this tool, but the sibling set 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral context like case sensitivity and data availability without contradicting annotations. It does not reveal additional behavioral constraints beyond what annotations provide.
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-loaded with purpose and return fields, then adding critical usage notes. Every sentence adds value without 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 output schema exists (not shown), the description covers return fields, pagination hints (cursor), and data availability window. It lacks timezone info for timestamps but is otherwise adequate for the tool's complexity.
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-documented. The description adds default values for start (24h ago) and end (now), and reiterates the case-sensitive nature of 'coin', providing extra clarity 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 tool name 'get_hip3_liquidations' and description clearly state it retrieves HIP-3 liquidation events for a coin over a time range, listing specific returned fields. It is well-differentiated from sibling tools like get_hip3_liquidation_volume and get_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 context such as case-sensitive symbols, data availability from February 2026, and a WebSocket alternative for real-time data. However, it does not explicitly state when not to use this tool versus related tools like get_hip3_liquidation_volume.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds return content (trigger prices and triggered status) and a Pro+ tier note, which provides additional context beyond 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?
Two sentences: first sentence states purpose and tier, second provides case-sensitivity hint and return summary. No redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, tier, case-sensitivity, and return content. With an output schema present, it need not detail return structure. It lacks explicit mention of pagination or default time ranges, but those are in the schema. References to get_hip3_instruments enhance completeness.
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% with parameter descriptions. The description adds extra value by stating case-sensitivity, giving market examples, and suggesting use of get_hip3_instruments to list symbols, going beyond schema 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 it retrieves HIP-3 TP/SL order history, specifies the Pro+ tier, and mentions case-sensitivity. It distinguishes itself from siblings like get_tpsl (general) and other get_hip3_* tools by focusing on TP/SL orders.
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 implies usage for HIP-3 TP/SL orders and notes the Pro+ tier requirement, but does not explicitly exclude alternatives like get_tpsl for non-HIP-3 or 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds minimal behavioral context beyond the listed return fields and case sensitivity.
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. The purpose is front-loaded, and essential details are included 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?
Given the simple one-parameter tool with full schema coverage, annotations, and an output schema (indicated by context), the description covers purpose, case sensitivity, and key return fields, making it complete.
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%, providing baseline. The description adds value with examples of symbols and a link to the listing tool, which helps the agent understand parameter usage 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 verb 'Get', the resource 'details for a single HIP-3 instrument', and distinguishes from siblings like get_hip3_instruments. It also mentions case sensitivity and specific return fields.
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 notes case sensitivity and provides an alternative 'Use get_hip3_instruments to list all', guiding when to use this tool vs the listing sibling.
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?
Annotations already declare readOnlyHint true and idempotentHint true; description adds important behavioral detail about case-sensitivity. 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?
Two efficient sentences: one for purpose, one for critical usage note. No wasted words.
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 no parameters and existing output schema and annotations, the description provides sufficient context about what the tool returns and how to use 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?
No parameters exist, so schema coverage is 100%. Description adds meaning by explaining the output context (list of HIP-3 instruments) 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 lists all available HIP-3 builder perp instruments and distinguishes from siblings by specifying HIP-3 context. It also notes case-sensitivity, which is a key detail.
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 guides to use this tool to discover valid symbols before querying other HIP-3 data, but does not mention when not to use or compare to similar tools like get_hip3_instrument.
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?
Annotations already declare readOnly=true, idempotent=true, and non-destructive. Description adds value by noting case sensitivity, free-tier restriction, and return structure (bids, asks, mid price). No contradiction with 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?
Three concise sentences: purpose, case sensitivity/example, tier restrictions. No redundant information; every sentence adds critical context.
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 output schema exists (not provided), description appropriately avoids duplicating return details. Covers purpose, parameter nuances, limitations, and references related tool for listing symbols. Adequate for a snapshot tool with robust annotations.
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% with descriptions. Description enriches 'coin' parameter with examples, case sensitivity warning, and market count (125+ across 6 builders). 'depth' parameter is minimally enhanced but schema already describes it sufficiently.
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 the current HIP-3 orderbook snapshot' with specific verb and resource. Differentiates from siblings by emphasizing 'current snapshot' and mentioning specific symbol caveats like case sensitivity and free-tier limitation.
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 guidance: free tier only supports 'km:US500', Build+ supports all HIP-3 symbols. Suggests using get_hip3_instruments to list symbols. Missing explicit when-not-to-use alternatives like history or L2-specific 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by listing the return fields (outcome_id, side, asset_id, etc.), offering transparency beyond safety guarantees.
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 with example, second details accepted forms and return fields. No wasted words, 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?
Given the tool's simplicity, existence of output schema, and thorough schema parameter description, the tool description is complete. It covers identification, variations, and usage hint.
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 covers 100% of parameter description with detailed explanation of coin forms. Tool description restates this with an example, adding minimal extra value. 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?
Clearly states 'Get details for a single HIP-4 instrument by coin symbol', specifying the verb, resource, and parameter. Distinguishes from sibling tools like get_hip4_instruments (list all) and other get_hip4_* tools.
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 mentions when to use this tool (single instrument) and directs to get_hip4_instruments for listing all. Also clarifies accepted coin forms, providing concrete 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, making safety clear. The description adds the specific fields returned, but does not discuss data freshness, rate limits, or response behavior beyond the summary composition. Adequate given the strong annotation coverage.
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 the core purpose ('Get combined Lighter.xyz market summary for a coin in a single call'), followed by a list of returned fields. No unnecessary words; 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?
For a simple read-only tool with strong annotations and an output schema (though not shown), the description is complete. It specifies the input, the return fields, and the platform. No additional context is needed for correct invocation.
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 single 'coin' parameter has a description in the schema ('Lighter.xyz coin symbol, e.g. 'BTC', 'ETH''). The description adds an example but does not significantly augment the schema, which already covers 100% of the parameter. Baseline 3, bumped for the helpful example.
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 combined Lighter.xyz market summary for a coin, listing the specific fields returned (mark price, oracle price, funding rate, open interest). This distinguishes it from sibling tools that return individual data points or summaries for other platforms.
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 implies use when a consolidated summary is needed, and mentions 'in a single call' to highlight efficiency. However, it does not explicitly contrast with individual data tools like get_lighter_funding_current or get_lighter_open_interest, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnlyHint, destructiveHint false, idempotentHint true, and openWorldHint true. The description adds valuable behavioral context: ~1.2s resolution, data available from April 2023, and tier-specific depth limits, which go beyond 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 three sentences with no extraneous information. The first sentence states the core purpose, the second adds data scope, and the third provides tier details. Every sentence earns its place.
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 has 6 parameters, an output schema, and many siblings, the description covers critical aspects: what is returned, resolution, time range, data history, and tier limitations. It is sufficient for an agent to decide when to use this tool.
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 input schema has 100% description coverage for all 6 parameters, so the description need not repeat parameter details. However, the description indirectly adds value by linking parameters like 'coin' and 'depth' to tier restrictions, e.g., 'BTC only' for free users and depth limits per tier.
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 historical Hyperliquid orderbook snapshots with ~1.2s resolution, returning L2 snapshots with bids/asks over a time range. This distinguishes it from siblings like get_orderbook (current snapshot) and get_l2_orderbook by focusing on historical 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 tier-based usage guidance (free: BTC only with 20 levels, Build+: all symbols with 200 levels, Pro+: full depth), which helps users select appropriate tool variants. It does not explicitly mention when not to use this tool vs similar siblings like get_hip3_orderbook_history, but the tier information is practical.
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?
Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description adds valuable behavioral details: it returns 'full order-level orderbook with individual order IDs, user addresses, prices, and sizes' and notes the data is 'Live from 2026-05-05'. No contradiction with 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 extremely concise, consisting of two tight sentences plus a third about data freshness. Every sentence adds necessary context without redundancy. It is well-structured and front-loaded with the core purpose.
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 presence of an output schema and exhaustive input schema, the description is complete. It covers the tier requirement, data coverage date, and return structure. It sufficiently distinguishes the tool among many similar orderbook endpoints.
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 covers all three parameters with detailed descriptions, so baseline is 3. The description adds minimal extra value beyond the schema, such as the 'dashed canonical' format and Pro+ tier, but does not significantly 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 specifies the verb ('Get'), resource ('Hyperliquid Spot L4 orderbook reconstruction'), and constraints ('at a specific timestamp', 'Pro+ tier'). It distinguishes itself from siblings by explicitly mentioning 'Spot' and 'L4', and noting the reconstruction aspect, which sets it apart from other orderbook 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 states the tool is for 'orderbook reconstruction at a specific timestamp' and requires 'Pro+ tier', indicating when to use it. However, it does not explicitly mention when not to use it or provide direct alternatives among the many sibling orderbook tools, though 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds context: returns periodic full order-level snapshots for reconstruction, and live data availability from a specific date. 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?
Two sentences, no filler. First sentence states core purpose and tier, second explains behavior and data recency. Every phrase is meaningful.
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 output schema exists and annotations are rich, description covers essential behavioral traits (snapshots, time range, live start date) without needing to detail return values. Complete for agent 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?
Input schema has 100% description coverage. Description does not add parameter-specific details beyond what's in schema, though it reinforces the symbol format. 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 verb ('Get'), resource ('Hyperliquid Spot L4 orderbook checkpoints'), and scope (Build+ tier, dashed canonical symbols). Distinguishes from siblings by specifying spot and L4, and notes live data start date.
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?
Implies usage for L4 orderbook reconstruction over a time range with Build+ tier. Does not explicitly list alternatives or when-not-to-use, but the specificity to spot L4 helps differentiate from non-spot L4 history tools present in siblings.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying the exact count (294 pairs) and the symbol format (dashed canonical, e.g., 'HYPE-USDC'), which are beyond annotation scope.
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 purpose and metadata fields, then adding count and usage hint. Every sentence is concise and informative.
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 zero parameters, a rich output schema, and comprehensive annotations, the description fully covers what the agent needs: what the tool does, how to use it, and 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?
The input schema has no parameters, achieving 100% coverage. The description lists the metadata fields returned (base/quote asset, wire symbol, etc.), adding context about the output without needing 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 it lists all Hyperliquid Spot pairs with specific metadata, distinguishing it from sibling tools like get_instruments or get_spot_pair. It also explicitly says to use it to discover valid symbols before querying other spot 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 advises using this tool to discover valid spot pair symbols before other spot tools, providing clear context. While it does not explicitly mention when not to use it, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds beyond: explains that mark_price is implied probability (0..1), notes legacy coin forms, and that only latest row is returned.
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. Purpose in first line, additional details in second and third, no filler words. Efficient and 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?
With output schema present, description adequately covers purpose, parameter, and key behavioral points. Could have mentioned return row fields but output schema handles that.
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. Description adds example coin '0' and legacy forms '#0'/'%230', plus a reference to get_hip4_instruments for listing all coins, providing extra guidance.
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 'Get' with specific resource 'current HIP-4 per-side open interest for a coin'. Example coin '0' and explicit differentiation from sibling get_hip4_outcome for paired-set/display 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?
States when to use (get current per-side OI) and explicitly when not (use get_hip4_outcome for paired-set/display OI). Also explains coin format acceptance.
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?
The description goes far beyond the sparse annotations (which only indicate non-readonly, non-destructive, non-idempotent, open-world). It details the HTTP 402 response, payment payload format, EIP-712 signing, and the two-step interaction. No contradictions with annotations.
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 well-structured with clear section headers (TWO-STEP FLOW, PAYMENT PAYLOAD FORMAT, EIP-712 SIGNING, IMPORTANT). It is front-loaded with the purpose. While long, every section is necessary given the complexity of the payment flow, making it appropriately concise for its informational density.
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 complexity of the tool (two-step payment, signing, etc.) and that an output schema exists (so return values need not be detailed), the description covers all necessary aspects: the flow, payload format, signing details, and important constraints. It is comprehensive and leaves no ambiguity.
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 schema descriptions include pricing for tier and a brief note for payment_signature. The tool description adds substantial value by providing the full payload structure, signing instructions, and critical data type constraints (values must be strings), which 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 the tool's purpose: 'Subscribe to a paid tier (build or pro) using x402 USDC payment on Base.' It specifies the action (subscribe), the resource (paid tier), and the method. This clearly distinguishes it from sibling tools, which are predominantly data retrieval 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 outlines a two-step flow: step 1 (call with only tier) and step 2 (call with payment_signature). It provides clear instructions on when to omit or include parameters. Although it does not explicitly state when not to use the tool, the context is sufficient given the exclusive nature of subscription among siblings.
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?
Annotations already declare it as read-only, idempotent, and non-destructive. The description adds value by confirming it returns all available instruments with leverage, decimals, and active status, which aligns with and enriches the annotations without contradiction.
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 covering what it does and when to use it. No redundant information. Every word serves a purpose.
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 has no parameters and a likely straightforward output schema, the description provides all necessary context: what it returns (leverage, decimals, active status) and why it's useful (discovering symbols). It is complete for the tool's simplicity.
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?
There are no parameters (0), so schema coverage is 100%. The description does not need to explain parameters. It focuses on the output semantic (list of instruments with specific fields), which is adequate for a parameterless tool.
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 all available Hyperliquid perpetual and spot instruments with specific details (leverage, decimals, active status). This differentiates it from singular instruments (get_instrument) and version-specific variants (get_hip3_instruments, get_lighter_instruments) by emphasizing 'all available' and the scope.
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 advises using this tool to discover valid coin symbols before querying other endpoints, establishing a clear prerequisite. It does not explicitly mention when not to use it or alternatives, but the context implies it's the primary discovery tool.
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?
While annotations already indicate idempotent and read-only behavior, the description adds valuable behavioral context: case-sensitivity, timestamp range defaults, cursor pagination, and aggregation interval options. No contradictions with 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?
Three sentences pack all essential information: purpose, case-sensitivity, time range, pagination, and intervals. No wasted words; every sentence adds value. Front-loaded with the core action.
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 has 6 parameters (1 required) and an output schema exists, the description covers all key aspects: what data is returned, symbol format, time range, pagination, and aggregation. It references a sibling tool for complete symbol list, making it self-contained enough for effective use.
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%, but the description adds significant meaning beyond the schema: it reiterates case-sensitivity, lists example symbols from various builders, mentions 125+ markets, and suggests using get_hip3_instruments. It also explains default start/end and intervals.
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 'HIP-3 funding rate history' with specific verb (Get) and resource (HIP-3 funding rate history). It distinguishes from siblings like get_funding_history by specifying the HIP-3 market, and mentions case-sensitivity and example symbols, making 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 implicitly provides usage context by mentioning it returns historical data with pagination and intervals, and references the sibling tool get_hip3_instruments for listing symbols. However, it does not explicitly contrast with other funding-related tools (e.g., get_funding_current, get_funding_history) or state 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.

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:

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

Score Badge

Copy to your README.md:

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

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/0xArchiveIO/0xarchive-mcp'

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