HyperLiquid MCP Server

Server Quality Checklist

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

Latest release: v0.1.8
Disambiguation2/5
Multiple tools have overlapping purposes: there are three cancel tools (cancel_all_orders, cancel_order, cancel_order_by_client_id), three TP/SL tools (set_take_profit_stop_loss, set_take_profit, set_stop_loss), and close_position vs market_close_position. While descriptions clarify the differences, the boundaries are tight enough that an agent could easily select the wrong tool, especially for closing positions or setting TP/SL.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun snake_case pattern (e.g., cancel_order, get_orderbook, update_leverage). Minor deviations such as market_open_position and market_close_position insert a modifier before the verb, but the intent is still clear and the overall convention is predictable.
Tool Count3/5
At 24 tools, the server is on the heavy side. The broad domain justifies many tools, but the count is inflated by redundant variants (three cancel tools, three TP/SL tools, five account query tools that could be consolidated. It's not extreme, but it exceeds the ideal 3-15 range and feels heavier than necessary.
Completeness4/5
The tool set covers the core trading lifecycle: market data, order placement (limit, market, bracket), order modification/cancellation, position management (close, TP/SL), leverage, transfers, and account queries. Minor gaps exist such as fetching a specific order by ID or listing all available coins, but agents can work around these with the existing tools.
Average 3.8/5 across 24 of 24 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on October 28, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
Add a glama.json file to provide metadata about your server.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but 'Modify an existing order' is essentially a tautology. It does not explain preconditions, what fields are mutable, whether updates are partial or full, or what errors can occur.
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 and front-loaded with the main action, and the argument list is easy to scan. It could be more structured, but no words are wasted.
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 four required parameters, no annotations, and only a bare output schema, the description is incomplete. It does not state when to use the tool, whether the order must exist, or what the response contains, leaving the agent under-informed.
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 description adds minimal semantic value by listing each parameter with a brief definition (e.g., 'coin: Trading pair'), which the schema lacks. However, it fails to explain relationships between parameters, format constraints, or optionality beyond the schema's required flags.
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 phrase 'Modify an existing order' clearly states the action and resource, distinguishing it from sibling tools like 'cancel_order' and 'place_limit_order'. However, it does not explicitly differentiate from similar modification tools like 'update_leverage' or 'set_take_profit'.
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 gives no guidance on when to use this tool versus alternatives. It does not mention that it is for changing size/price, nor does it contrast with cancel or other order-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only repeats the action and resource without revealing important traits such as whether orders are returned for all markets, whether pagination is used, or whether any filtering is applied. This is a significant transparency gap.
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 of four words, which is extremely concise and front-loaded. While it lacks substantive detail, it does not waste any words and is efficiently structured.
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 simplicity of the tool and the presence of an output schema, the description could be minimally adequate, but it fails to provide essential context such as the definition of 'open' orders, whether the list includes all trading pairs, or if canceled orders are excluded. This leaves the agent uncertain about the tool's behavior in edge cases.
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 tool has zero parameters, and the schema is fully covered since there are no properties to describe. The description correctly implies that no input is required, so there is effectively nothing to add beyond what the schema already 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?
The description clearly identifies the action ('Get') and the resource ('all open orders'), which is specific and distinct from sibling tools like get_open_positions or get_trade_history. However, it does little more than restate the tool name, so it does not fully differentiate the tool's unique scope.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, typical use cases, or situations where another tool would be preferred, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the cancel action but doesn't mention side effects (e.g., irreversibility), required permissions, error behavior, or ordering constraints. It is a mutation tool with no additional transparency.
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 and front-loaded with the main action. The Args section is minimal and structured without unnecessary text. It could be slightly more informative but earns points for efficiency.
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 low complexity and presence of an output schema, the description is adequate but incomplete. It doesn't clarify when to use this over the sibling cancel_order_by_client_id or address edge cases, leaving a noticeable gap in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds basic meanings for both parameters (coin: trading pair, order_id: order ID to cancel), which helps since schema description coverage is 0%. However, it doesn't clarify the distinction between exchange order ID and client order ID (relevant given sibling cancel_order_by_client_id), nor provide format details.
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 action ('Cancel a specific order by order ID'), which is a specific verb + resource. It distinguishes from siblings like cancel_all_orders and cancel_order_by_client_id by emphasizing 'by order ID', though it doesn't explicitly name alternatives.
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 is given on when to use this tool vs cancel_order_by_client_id or modify_order. The description implies usage for canceling a single order by ID but doesn't provide context or exclusions, leaving the choice ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get market data', implying read-only, but does not describe return format, data scope, rate limits, or any other behavioral traits. This is a minimal disclosure for a tool that overlaps with several siblings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with the main sentence front-loaded and an Args section that directly documents the sole parameter. Every line serves a purpose with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and one parameter, the description is incomplete because 'market data' is ambiguous in the context of sibling tools like get_orderbook and get_candles_snapshot. It does not clarify what data is actually returned, making it difficult for an agent to select this tool over alternatives.
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 0% coverage with no description for 'coin'. The description compensates by defining 'coin' as a trading pair with examples 'BTC' and 'ETH', adding essential meaning. However, it stops short of specifying accepted formats or edge cases, so it doesn't earn a 5.
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?
Description clearly states 'Get market data for a specific coin', providing a verb and resource. However, 'market data' is generic and does not differentiate from siblings like get_orderbook or get_candles_snapshot, so it falls short of the 5 threshold for explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention whether this tool provides general price data or specific data types, nor does it exclude use cases covered by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the high-level action. It does not disclose whether this is a read-only operation explicitly, any authentication requirements, or what specific margin details are included. 'Get' implies read-only, but additional context is absent.
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 concise sentence that is front-loaded and contains no redundant words or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists, and there are no parameters, the description is mostly sufficient. However, it lacks any context on how it differs from the similar sibling 'get_account_summary', and it does not clarify scope (e.g., spot vs. perpetual accounts), leaving some 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?
The tool has zero parameters, so the schema fully covers parameter semantics. Per baseline for zero-parameter tools, the description does not need to explain parameters.
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 account balance and margin information, using a specific verb ('Get') and resource. However, it does not distinguish from the sibling tool 'get_account_summary', which likely overlaps in 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?
No guidance is provided on when to use this tool versus alternatives such as 'get_account_summary' or 'get_open_positions'. There is no mention of prerequisites or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get orderbook data' without describing return format, pagination, rate limits, or any side effects. Given that the tool is a read operation, the lack of any behavioral context beyond the bare action is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear first-sentence purpose and a compact Args list. Every sentence earns its place, and the structure is front-loaded with the primary purpose. It is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter set and an output schema exists, so the description does not need to explain return values. However, it lacks usage guidance and behavioral context, making it minimally sufficient for a straightforward read tool. Given the existence of overlapping sibling tools, it could be more complete by clarifying when to choose 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 schema provides no descriptions (coverage 0%), so the description's Args section compensates by explaining both parameters: 'coin' as a trading pair with examples, and 'depth' as order book depth with a default value. This adds meaningful semantics beyond the raw schema, though it could be more detailed (e.g., depth units or allowed ranges).
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 orderbook data for a specific coin' with a specific resource (orderbook) and verb (get). It is distinct from siblings like get_market_data and get_candles_snapshot, but it does not explicitly differentiate itself or mention alternatives, so it lacks the explicit sibling differentiation seen in top-tier descriptions.
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 vs. alternatives. The description only lists arguments, with no mention of appropriate contexts, exclusions, or comparison to similar tools like get_market_data or get_candles_snapshot. This leaves the agent to guess which tool is appropriate for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the purpose and documents the 'days' parameter default; it does not mention read-only nature, pagination, order of results, or any other behavioral 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?
The description is extremely concise: a one-line purpose followed by a single parameter doc line. No wasted words; the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and an output schema, the description is minimally adequate. It explains the parameter and the basic purpose, but lacks any context about scope (e.g., which account), data returned, or relation to sibling tools. The output schema covers return structure, mitigating the need for 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?
The input schema only defines the 'days' parameter as an integer with a default of 7, but the description adds the semantic 'Number of days to look back', clarifying the parameter's meaning. This compensates for the schema's lack of a property 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 'Get trade history for the account' with a specific verb and resource. The resource 'trade history' is unique among sibling tools (e.g., get_funding_history, get_account_summary), inherently distinguishing it.
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. It lacks any context about use cases, prerequisites, or exclusions (e.g., not funding history). Usage is only implied by the name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention side effects like irreversibility, that the order must be open, or error behavior if the order is already filled. The description merely restates the action without adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by a compact parameter breakdown. No unnecessary words, and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and parameters, and an output schema exists, so return values need not be explained. However, it lacks behavioral context such as cancellation semantics, and does not clarify the distinction from 'cancel_order', leaving the overall context somewhat incomplete.
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 has 0% description coverage, but the description compensates by explaining 'coin' as a trading pair and detailing 'client_order_id' as a 128-bit hex string with an example. This adds meaningful semantic value for both 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 uses a specific verb 'Cancel' with a resource 'specific order' and a distinguishing qualifier 'by client order ID'. This clearly differentiates it from sibling tools like 'cancel_order' and 'cancel_all_orders'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as 'cancel_order'. It only states the mechanics of cancellation without specifying context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency. It only lists the content areas (balance, positions, orders) but does not disclose important behavioral traits such as whether orders include open/closed, potential latency, authentication requirements, or any side effects. This is insufficient for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose and key content areas. It is concise, front-loaded, and every phrase 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 tool has no parameters and an output schema exists, the description need not explain return formatting. The concise list of included elements (balance, positions, orders) provides sufficient context for an agent to understand the tool's scope relative to siblings. However, it lacks some nuance about the nature of 'orders' or whether it is real-time, so it's not a perfect 5.
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 tool has zero parameters, so the input schema already provides full coverage (100%). As per the baseline for 0-param tools, a score of 4 is appropriate since there are no parameter semantics to add beyond the empty 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?
The description clearly states the tool retrieves a 'comprehensive account summary' including 'balance, positions, and orders', which is a specific verb+resource combination. However, it does not explicitly differentiate itself from sibling tools like get_account_balance, get_open_positions, or get_open_orders, though the word 'comprehensive' implies a combined view.
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 getting an account overview, but it does not explicitly state when to prefer this over individual sibling tools or mention any exclusions. There is no clear 'when to use' or '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It merely says 'Get funding history' and describes parameters, but gives no information about rate limits, response format, potential errors, or any side effects. The read-only nature is implied by the verb 'Get' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the purpose stated in one sentence and parameters listed cleanly. No unnecessary words or filler; every sentence 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 tool's simplicity (2 params) and the presence of an output schema, the description covers the essential invocation details. It lacks guidance on when to use this versus other data tools, but for a straightforward data retrieval, the provided information is largely 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?
The schema has no descriptions, so the description fully compensates by explaining that 'coin' is a trading pair with examples and 'days' is the look-back period with a default value. This adds clear meaning beyond the raw type/default information in 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?
The description clearly states the action ('Get funding history') and the resource (a coin), with parameter details. It is distinct from siblings like get_market_data and get_trade_history by its focus on funding history, but it does not explicitly differentiate from alternative 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 guidance is provided on when to use this tool compared to siblings like get_market_data or get_candles_snapshot. There are no exclusions, prerequisites, or contextual hints about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it merely says 'update' without mentioning side effects, permissions, reversibility, or the impact on existing orders/positions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary followed by a clean Args list with examples. No redundant words, and 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?
The input parameters are well-covered, and the existence of an output schema removes the need to describe return values. However, the lack of usage context and behavioral transparency leaves the description just adequate for a simple mutation tool.
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?
The schema has 0% description coverage, so the description carries full responsibility for parameter meaning. It thoroughly explains all three parameters with examples (e.g., 'BTC', 'ETH', 10 for 10x) and clarifies the boolean cross_margin semantics (cross vs. isolated margin).
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 function with a specific verb ('update') and resource ('leverage for a coin'), making it distinct from sibling tools like modify_order or set_take_profit. However, it does not explicitly name alternatives or add further scope beyond the coin, so it misses the top score.
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?
There is no explicit guidance on when to use this tool versus alternatives, such as 'before opening a position' or 'does not affect existing positions.' The intended use is implied by the tool's name and purpose, but no when/when-not conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Get' implies a read-only operation, but it does not explicitly state that no state changes occur, nor does it mention authentication context or other behavioral traits. It is acceptable for a simple 0-param getter, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler. The key information is front-loaded and every word contributes meaning.
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 0-parameter read tool with an output schema, the description is mostly complete. It specifies scope ('all open positions') and content ('PnL information'). It could mention account context or return format, but the simplicity of the tool reduces the need.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter behavior since none exist.
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'), names the resource ('open positions'), and adds return content ('with PnL information'). This clearly distinguishes it from sibling tools like get_open_orders or get_account_summary.
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 is given about when to use this tool versus alternatives. The description implies a use case—when you want all open positions—but does not mention account scope, exclusions, or contrasting sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only repeats the parameters and does not mention side effects, confirmations, irreversibility, or any account requirements. It is not misleading, but it provides almost no behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a one-line summary followed by a simple Args list. Every sentence earns its place, with no redundancy or fluff. It is easily scannable.
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 (two parameters, straightforward operation) and the presence of an output schema, the description is nearly complete. It covers the core semantics of amount and direction. The only shortfall is the lack of behavioral transparency (e.g., fees, reversibility), but that is already captured in the transparency dimension.
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 has no description coverage (0%), so the description's Args section is the only explanation. It adds clear meaning: 'amount' is the amount to transfer, and 'to_perp' indicates direction (to perpetual vs. spot). This goes beyond the schema's bare types and defaults, though it could have specified units or currency.
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: 'Transfer funds between spot and perpetual accounts.' This uses a specific verb and resource, and the directionality is further clarified by the 'to_perp' parameter. It clearly distinguishes itself from siblings like order placement or balance queries.
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 from its name and context—whenever funds need to be moved between spot and perpetual accounts. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. This is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (cancel all orders) and the optional coin filter, but does not disclose potential consequences, irreversibility, permissions required, or behavior on partial failures. For a destructive batch operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear sentence plus an Args block. Every piece of text adds value, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one well-documented parameter, and an output schema exists. However, for a mutating batch operation that can be highly destructive, the description omits important context such as irreversible action, scope limitations (e.g., only open orders), and potential partial-failure semantics. It is minimally complete but lacks safety-critical detail.
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 0%, but the description compensates well by explaining the single parameter 'coin' as an optional trading pair and clarifying that None means cancel all orders. This adds meaningful semantics beyond the raw schema definition.
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+resource ('Cancel all orders') and clearly distinguishes itself from sibling tools like cancel_order and cancel_order_by_client_id by indicating the bulk-cancel scope. The optional coin filter adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when canceling all orders or all orders for a specific coin. It does not explicitly mention alternatives (e.g., cancel_order for individual orders), but the 'all' scope provides sufficient contextual guidance for 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?
With no annotations, the description carries the burden. It adds useful behavioral context about how full closures are executed (via market_close_position) and the limitation of HyperLiquid's market_close for partial closures. However, it leaves ambiguous whether the tool itself places limit orders or instructs the user to do so, undermining full transparency.
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 Args and Note sections, and is appropriately concise. The note is informative but could be clearer, especially regarding partial closures, so it loses one point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and alternatives, but the ambiguity about partial closure execution is a significant gap. It does not fully clarify whether this tool can be used for partial closures or if the user must place limit orders separately, which is essential for a trading tool.
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?
The input schema only lists 'coin' (string) and 'percentage' (number) with a default, but the description provides essential semantics: 'coin: Trading pair (e.g., BTC, ETH)' and 'percentage: Percentage of position to close (default: 100.0 for full close).' This adds meaning beyond the schema, satisfying the 0% coverage gap.
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 'Close a position (full or partial)' with a specific verb and resource. It distinguishes itself from sibling tools by mentioning 'uses market_close_position for optimal execution' and discussing partial closure, which is unique compared to market_close_position.
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?
Guidance is provided: 'For 100% closure, uses market_close_position for optimal execution' and 'For partial closure, you'll need to use limit orders as HyperLiquid's market_close closes all positions.' This names alternatives and conditions, though the ambiguity about whether the tool itself handles partial closures via limit orders slightly reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool uses HyperLiquid's market_close method and automatically determines the correct side and size to close all positions. It does not mention prerequisites or risks like slippage, but the core behavioral trait (closing everything) is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: a one-sentence summary, an Args list, and a clarifying Note. Each sentence adds value, and the parameter explanations justify their inclusion given the empty schema descriptions.
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 (2 params, no nested objects), and an output schema exists, so return values are covered elsewhere. The description covers purpose, behavior, and parameter meanings. It lacks explicit comparison to the 'close_position' sibling, but that is a usage guideline gap rather than a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining 'coin' as a trading pair with examples and 'client_order_id' as an optional tracking ID. This provides useful meaning beyond the bare schema, though it could include more format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Close all positions for a coin at market price' and explicitly emphasizes 'ALL positions' twice. It distinguishes from siblings by the 'all' scope, which is a key differentiator from the 'close_position' sibling that likely closes a single position.
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 that this tool closes all positions for a specified coin, implying when it should be used over a single-position closer. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it lacks the explicit exclusions of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that 'size' is the number of tokens, not dollar value, and provides a calculation example—this is critical, non-obvious behavior. It also mentions it uses HyperLiquid's market_open method. It does not disclose potential side effects like immediate slippage or margin requirements, but the most important behavioral trap is covered.
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 well-structured with labeled parameters and a clear callout for the size nuance. The example calculation is necessary and earns its place. It is not overly verbose; every sentence contributes value, and the critical warning is front-loaded before the detailed example.
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, not explaining return values is acceptable. The description covers the essential parameters and the key behavioral trap. It could add context about account prerequisites or that this opens a perp position, but the tool's purpose and invocation are clear enough for an agent. It is nearly complete for a trading action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. It explains each parameter: coin (e.g., 'BTC'), side ('buy' for long, 'sell' for short), size (with a detailed example of converting dollar value to tokens), and client_order_id (optional tracking ID). This adds substantial meaning beyond the bare schema, which only lists types and defaults.
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: 'Open a new position at market price using HyperLiquid's market_open for optimal execution.' This is a specific verb+resource, and it distinguishes from sibling tools like market_close_position and place_limit_order. The scope (opening at market) is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for opening positions at market price, and it recommends the use of HyperLiquid's native market_open for optimal execution. While it does not explicitly exclude alternative tools (e.g., limit orders), the scenario is clearly defined, and the 'optimal execution' note gives usage guidance. It lacks explicit 'when not to use' but is well above implied 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context such as 'must have an existing position' and 'will auto-detect from existing position if not provided' for position_size. However, it does not describe error behavior when no position exists, the order type created, or side effects like replacing existing take profit orders, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args section and a note. Every sentence serves a purpose: defining scope, listing parameters, and pointing to alternatives. There is no filler or redundancy, striking an appropriate balance between detail and brevity.
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 (3 parameters, no annotations) and the presence of an output schema, the description is comprehensive. It covers the core action, constraints, parameter semantics, and usage alternatives. The output schema handles return values, so the description need not describe them. This is more than sufficient for correct selection and 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 description coverage is 0%, so the description must compensate. It explains 'coin' as a trading pair with the constraint of an existing position, and 'position_size' with auto-detection behavior. 'take_profit_price' is only restated as 'Take profit price', which adds no new meaning beyond the schema, but the overall parameter guidance is strong.
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 with a specific verb ('Set') and resource ('take profit order for an EXISTING position'). It explicitly distinguishes itself from siblings by emphasizing 'ONLY' and 'EXISTING', and even names alternatives in the note. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'This is specifically for setting ONLY take profit on EXISTING positions.' It also names alternatives: 'Use set_take_profit_stop_loss if you want both TP and SL, or place_bracket_order for new positions.' This fully directs the 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?
No annotations are provided, so the description carries the full burden of disclosure. It explicitly describes the calculation and return format (dictionary with token amount, current price, and dollar amount). This is sufficient for a non-destructive calculation tool. It does not mention error cases or data source, but the behavior is straightforward.
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 well-structured: a one-sentence purpose, labeled args, returns, and a worked example. Every line adds value, and the example is provided without redundancy. No filler or fluff is present.
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 calculation tool, the description is complete. It covers inputs, output structure, and a full example. Even though an output schema is claimed, the description already documents the return format. All necessary information for correct invocation is present, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does exceptionally well. It explains both parameters ('coin' and 'dollar_amount') with examples ('BTC', 'ETH', 'SOL' and '20.0 for $20'), and the example output clarifies the meaning of each field. The schema provides only types, so the description is the sole source of semantic 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 starts with a clear verb and resource: 'Calculate how many tokens can be bought with a given dollar amount.' This unambiguously distinguishes it from all sibling tools, which are order management and market data operations. The example call further reinforces the specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever a user wants to convert a dollar amount into a token quantity. It does not explicitly exclude alternatives, but no sibling serves the same purpose, so the context is sufficient. The example call provides practical guidance on invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: batch retrieval for multiple coins, default end_time to now, mutual exclusivity between days and start/end, and limit semantics (latest N candles). 'Fetch' implies read-only operation, though it doesn't state this explicitly or mention rate limits/auth, but the coverage is substantial.
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 front-loaded with a clear purpose sentence followed by an organized Args list. Each line is informative and necessary, with no filler or redundancy. It efficiently conveys all required 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 the tool has an output schema, the description doesn't need to explain return values. It adequately covers all input parameters, defaults, and mutual exclusivity constraints, making it complete for a batch OHLCV retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains every parameter: coins as trading pairs, interval as HyperLiquid-supported, start/end timestamps in milliseconds, days as an alternative, and limit as max candles per coin. This fully covers parameter meaning, units, and constraints.
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 fetches candlestick (OHLCV) data for multiple coins in one request, using a specific verb ('Fetch') and resource ('candlestick data'). This distinguishes it from sibling market data tools like get_orderbook or get_market_data by emphasizing batch retrieval of OHLCV candles.
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 (when OHLCV data is needed) and provides clear context for parameter relationships (e.g., 'start_time required when days not provided', 'days mutually exclusive with start/end'). However, it does not explicitly name alternative tools or state when NOT to use this tool, which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses key behavioral traits: the order creates a new position, uses normalTpSl grouping for OCO behavior, and clarifies that size is in tokens not dollars. While it doesn't cover all edge cases (e.g., price slippage), it provides substantial helpful context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-organized with a clear summary, Args list, and IMPORTANT note. Every sentence adds value, especially the size clarification and alternative tool mention. The length is justified for a 7-parameter tool with a common pitfall.
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 and the absence of annotations, the description covers the essential context: new position scope, OCO behavior, parameter details, and alternative tools. It does not describe return values, but the presence of an output schema reduces that need. Overall, it is complete enough for correct invocation.
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?
Since schema descriptions are absent (0% coverage), the description fully compensates by explaining every parameter in the Args section. It gives an explicit example for size conversion ('$20 ÷ $150 = 0.133 SOL') and specifies client_order_id format as a 128-bit hex string. This is exemplary parameter documentation.
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: 'Place a bracket order for a NEW position (entry + take profit + stop loss in one order)'. It explicitly distinguishes from sibling tools by noting 'For existing positions, use set_take_profit_stop_loss', making it easy to select the correct tool.
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?
Usage context is explicit: it is for NEW positions only, with direct guidance to use set_take_profit_stop_loss for existing positions. The description also explains the OCO behavior ('TP and SL orders cancel each other'), clarifying when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds crucial context: 'size' is number of tokens (not dollar value) with a conversion example, explains reduce_only semantics, and specifies the client_order_id hex format. It omits some operational details (e.g., order lifecycle, margin requirements), but covers the most critical behavioral nuances.
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 well-structured and front-loaded: a clear purpose sentence, a concise argument list, a highlighted 'IMPORTANT' pitfall with a concrete example, and a brief pointer to an alternative. Every sentence serves a purpose, keeping it appropriately sized despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter trading tool with no schema descriptions and no annotations, the description is remarkably complete. It covers all parameters, provides a real-world conversion example, flags the most common user error (size vs. dollar value), and references the correct alternative for TP/SL. The presence of an output schema further covers return-value expectations, making this contextually 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 description coverage is 0%, so the description must compensate. It explains every parameter: coin as trading pair, side as buy/sell, size as token count (with explicit warning against dollar value), price as per-token limit price, reduce_only as position-reduction-only, and client_order_id as an optional 128-bit hex string. This adds substantial meaning beyond the bare 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 'Place a basic limit order (for opening new positions or manual closing)', specifying both the action and the scope. This distinguishes it from market orders, bracket orders, and TP/SL tools, making the purpose explicit and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names one alternative: 'For setting take profit/stop loss on existing positions, use set_take_profit_stop_loss instead.' It also implies usage for opening or manually closing positions, but does not contrast with market open/close or bracket order tools, so guidance is not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses important behavioral traits: OCO (One-Cancels-Other) behavior, existing position requirement, and auto-detection of position size. It does not detail all potential side effects (e.g., interaction with existing TP/SL orders) but provides substantial value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, an Args list, and a Note. Every sentence earns its place, front-loading the core purpose and providing necessary details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, 1 required) and no annotations, the description is fairly complete: it covers usage context, alternatives, parameter semantics, and OCO behavior. The output schema exists, so return value explanation is not required. Minor gaps remain around error cases and precise price handling, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: coin must have an existing position, take_profit_price and stop_loss_price are optional, and position_size auto-detects. This adds meaningful semantic context beyond the bare schema, though not exhaustive (e.g., price format).
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: "Set take profit and/or stop loss orders for an EXISTING position (OCO orders)". It uses specific verbs and resource, and explicitly distinguishes from siblings like set_take_profit and set_stop_loss by combining both, and notes it's for existing positions only.
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 provides explicit usage guidance: "This is for EXISTING positions only. Use place_bracket_order for new positions with TP/SL." It also clarifies optional parameters and auto-detection of position size, giving clear context on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses key constraints: existing position required, auto-detection of position_size, and the 'only stop loss' scope. However, it does not state whether an existing stop loss is replaced or what happens if no position exists, so some behavioral detail is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a compact argument list and a clear note. Every sentence adds value, with 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, an output schema exists, and the description covers purpose, parameters, constraints, and alternatives. It is sufficiently complete for an agent to select and invoke this tool correctly.
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 0%, but the description explains every parameter with meaningful context: coin examples and existing-position requirement, stop_loss_price purpose, and position_size auto-detection. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets ONLY a stop loss order on an EXISTING position, using specific verbs and resource. It also distinguishes from sibling tools set_take_profit_stop_loss and place_bracket_order, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (only for existing positions, only stop loss) and when NOT to use, naming alternatives: 'Use set_take_profit_stop_loss if you want both TP and SL, or place_bracket_order for new positions.' This is ideal guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/talkincode/hyperliquid-mcp-python'

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