Hyperliquid MCP Server

by t3rmed

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. For example, cancel_all_orders vs cancel_order handle different cancellation scopes, and get_user_fills vs get_user_fills_by_time provide historical data with different filtering approaches. The descriptions make it easy to distinguish between trading actions, data queries, and order management functions.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with snake_case throughout. The verbs are clear and appropriate (get, cancel, place) and the nouns specify the exact resource or action. There are no deviations in style or convention across the 11 tools.
Tool Count5/5
With 11 tools, this server provides comprehensive coverage for cryptocurrency trading on Hyperliquid without being overwhelming. The count aligns well with the domain scope, covering order placement/cancellation, market data access, portfolio tracking, and trade history—all essential functions for trading automation.
Completeness4/5
The toolset covers most core trading operations including order management, market data, portfolio tracking, and historical fills. A minor gap exists in account management tools (e.g., deposit/withdrawal, funding rates) and advanced order types beyond limit/trigger orders, but agents can execute basic to intermediate trading workflows effectively.
Average 3.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 'Get historical candle data' which implies a read-only operation, but doesn't cover critical aspects like rate limits, authentication needs, data freshness, or error handling, leaving significant gaps for a tool with market data access.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of financial data tools, no annotations, and no output schema, the description is insufficient. It lacks details on return format (e.g., data structure, timestamps), error cases, or behavioral constraints, making it incomplete for effective agent 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?
Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds no additional meaning beyond implying historical data retrieval, which is already clear from the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'historical candle data for a specific coin', making the purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'get_all_mids' or 'get_l2_book' that might also provide market data, missing explicit differentiation.
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. With siblings like 'get_all_mids' and 'get_l2_book' that likely offer different market data, there's no mention of context, prerequisites, or exclusions, leaving usage 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 provided, the description carries the full burden of behavioral disclosure. It states it 'Get[s] L2 order book snapshot', implying a read-only operation, but doesn't clarify if this requires authentication, has rate limits, returns real-time or cached data, or what the output format entails. For a tool with zero annotation coverage, this is a significant gap, scoring a 2.
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, efficient sentence that front-loads the core purpose without any wasted words. It directly states what the tool does, making it easy to parse and understand quickly. This exemplifies excellent conciseness and structure, earning a 5.
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 complexity of financial data tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what an 'L2 order book snapshot' entails (e.g., bid/ask levels, depth), return values, or behavioral traits like latency or authentication needs. For a tool in this context, more detail is needed, resulting in a score of 2.
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, with clear docs for 'coin' and 'nSigFigs'. The description adds no additional parameter semantics beyond implying the tool is coin-specific, which is already covered in the schema. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'L2 order book snapshot for a specific coin', making the purpose immediately understandable. It specifies the scope ('for a specific coin') but doesn't explicitly differentiate from siblings like 'get_all_mids' or 'get_candle_snapshot', which might also provide market data. This is clear but lacks sibling differentiation, warranting a 4.
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, such as 'get_all_mids' for mid-prices or 'get_candle_snapshot' for historical data. It doesn't mention prerequisites, exclusions, or specific contexts, leaving the agent to infer usage based on the name alone. This lack of explicit guidance results in a score of 2.
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 states what data is returned but doesn't describe important behaviors: whether this requires authentication, rate limits, real-time vs. cached data, error conditions, or response format. For a financial data tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose. It wastes no words on unnecessary details. However, it could be slightly more structured by separating the core function from the data components for even better readability.
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 moderate complexity (portfolio data retrieval), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It tells what data is returned but lacks crucial context about authentication, data freshness, error handling, and response structure. For a financial tool with no output schema, more completeness would be expected.
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 fully documents the single optional parameter. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'portfolio information', specifying the included data fields (positions, PnL, margin usage). It distinguishes from siblings like get_open_orders or get_user_fills by focusing on portfolio rather than orders or fills. However, it doesn't explicitly contrast with all siblings, preventing a perfect score.
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 doesn't mention when to prefer get_portfolio over other data retrieval tools like get_user_fills or get_open_orders, nor does it specify any prerequisites or constraints for usage. The only implied context is portfolio-related queries.
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 tool places orders but doesn't mention critical traits like authentication requirements, rate limits, potential side effects (e.g., fund deductions), error handling, or response format. For a financial transaction tool, this is a significant gap 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 complexity of a financial order placement tool with no annotations and no output schema, the description is insufficient. It lacks details on authentication, error cases, return values, and differentiation from siblings like 'place_trigger_order', leaving critical context gaps for safe and effective 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?
Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., assetIndex mapping, isBuy meaning). The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 for high coverage without extra value.
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 ('place') and resource ('limit or trigger order on Hyperliquid'), making the purpose evident. However, it doesn't distinguish this tool from its sibling 'place_trigger_order', which appears to be a more specific variant, leaving some ambiguity about when to use one versus the other.
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 doesn't mention prerequisites (e.g., authentication, account setup), compare it to 'place_trigger_order', or indicate scenarios where it's appropriate (e.g., trading strategies). This lack of context makes it harder for an agent to decide when to invoke it.
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 but offers minimal information. It states what the tool does but doesn't describe execution behavior (what happens when triggered), potential risks, authentication requirements, rate limits, or error conditions. For a financial trading tool with no annotation coverage, this represents 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point with zero wasted verbiage.
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?
For a financial trading tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address critical context like execution mechanics, risk implications, authentication requirements, or response format. The combination of complex functionality with minimal behavioral disclosure creates significant gaps for an AI agent trying to use this tool appropriately.
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 8 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description doesn't enhance understanding of parameter relationships or usage patterns.
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 ('Place a trigger order') and specifies the resource type ('stop-loss or take-profit') and platform ('on Hyperliquid'). It distinguishes from the sibling 'place_order' by focusing specifically on conditional trigger orders rather than immediate execution orders. However, it doesn't explicitly contrast with 'cancel_order' or other order management 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when trigger orders are appropriate compared to regular orders, nor does it reference the sibling 'place_order' for immediate execution needs. There's no discussion of prerequisites, timing considerations, or typical use cases for stop-loss versus take-profit orders.
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. 'Cancel all open orders' implies a destructive write operation, but it doesn't disclose critical behavioral traits like whether this action is irreversible, requires confirmation, affects only certain order types, has rate limits, or returns any confirmation data. The description is minimal and lacks necessary context for safe use.
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, efficient sentence with zero waste—'Cancel all open orders' directly conveys the core action without extra words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of a destructive trading operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'open orders' entails, the return format (e.g., success confirmation or list of canceled orders), error conditions, or side effects. For a high-stakes tool like this, more context is needed to ensure safe and correct usage.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, but it implicitly confirms no parameters are needed by stating 'all open orders' without qualification. This aligns perfectly with the schema, warranting a baseline score of 4 for zero-parameter tools.
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 'Cancel all open orders' clearly states the verb (cancel) and resource (all open orders). It distinguishes from the sibling 'cancel_order' by specifying 'all' versus a single order. However, it doesn't explicitly mention the trading context or differentiate from other cancellation-related tools that might exist, keeping it at a 4 rather than a 5.
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 'cancel_order' for specific orders or other trading operations. It doesn't mention prerequisites, risks, or appropriate contexts for bulk cancellation versus selective cancellation.
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 states what the tool does but lacks critical details such as whether it's a read-only operation, potential rate limits, authentication requirements, or what format the mid prices are returned in (e.g., JSON, array).
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, efficient sentence that front-loads the core action ('Get current mid prices') and resource ('all coins on Hyperliquid'). There is no wasted verbiage, making it highly concise and well-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 complexity of retrieving financial data and the absence of annotations and output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral traits like whether it's real-time or cached data, leaving significant gaps for agent usage.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds value by specifying 'all coins on Hyperliquid', which clarifies scope beyond what the empty schema indicates, earning a baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current mid prices for all coins on Hyperliquid'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get_candle_snapshot' or 'get_l2_book', which also retrieve market data but for different metrics.
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 doesn't mention prerequisites, timing considerations, or compare it to sibling tools like 'get_portfolio' or 'get_user_fills', leaving the agent to infer usage 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 full burden but only states the action without behavioral details. It doesn't disclose whether cancellation is reversible, requires specific permissions, affects portfolio balances, has rate limits, or returns confirmation details. For a mutation tool with zero annotation coverage, 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 a single, efficient sentence that front-loads the core purpose with zero redundant information. Every word earns its place by specifying the action, target, and identification methods.
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?
For a mutation tool ('cancel') with no annotations and no output schema, the description is incomplete. It doesn't explain what happens upon cancellation (e.g., order status change, funds release), error conditions, or return values. Given the complexity of order management, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value by mentioning 'order ID or client order ID', which is already covered in parameter descriptions. Baseline 3 is appropriate when 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 the action ('Cancel') and target ('a specific order'), specifying identification methods ('by order ID or client order ID'). It distinguishes from sibling 'cancel_all_orders' by focusing on individual cancellation, though it doesn't explicitly name that sibling.
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 context through 'specific order' and parameter descriptions mentioning 'use either orderId or clientOrderId', suggesting this tool is for targeted cancellations. However, it doesn't explicitly state when to use this versus 'cancel_all_orders' or other order-related tools, nor does it mention prerequisites like order status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves open orders but does not disclose behavioral traits such as whether it requires authentication, rate limits, pagination, error handling, or the format of returned data. For a read operation with zero annotation coverage, this is a significant gap in transparency, though it correctly implies a non-destructive 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?
The description is a single, efficient sentence that front-loads the core purpose ('Get all open orders') and includes key details (scope and parameter hint). There is no wasted language, making it appropriately sized and easy to parse quickly.
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 complexity of a financial tool with no annotations and no output schema, the description is incomplete. It lacks details on authentication needs, rate limits, return format, error conditions, or how results are structured (e.g., list of orders with fields). For a tool interacting with wallet data, this omission reduces its usefulness for an AI agent in making informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'user' documented as an optional wallet address defaulting to the configured wallet. The description adds minimal value beyond the schema by mentioning 'a specific user', but does not provide additional context like format examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate as the schema handles most parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all open orders', specifying the scope as 'for the configured wallet or a specific user'. It distinguishes the tool's purpose from siblings like 'get_user_fills' (which retrieves historical fills) and 'get_portfolio' (which retrieves overall holdings). However, it doesn't explicitly differentiate from 'cancel_all_orders' or 'place_order' in terms of action type, though the verb 'Get' implies read-only 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?
The description implies usage when needing to retrieve open orders, with a default to the configured wallet and an optional user parameter for specificity. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_user_fills' (for historical data) or 'cancel_all_orders' (for management actions). No exclusions or prerequisites are mentioned, leaving usage context somewhat inferred rather than clearly defined.
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 describes a read operation ('Get'), which implies non-destructive behavior, but doesn't mention any other traits such as rate limits, authentication requirements, pagination, or error handling. For a tool that accesses trading history without annotation coverage, this is a significant gap in transparency, though it doesn't contradict any 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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core functionality ('Get trading history (fills)') and includes essential scope information. Every part of the sentence earns its place, making it highly concise and well-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 context: no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks details on behavioral aspects like rate limits or authentication, doesn't explain the return format (e.g., what data 'fills' includes), and doesn't differentiate from sibling tools. For a tool that retrieves trading history, this leaves the agent with insufficient information to use it effectively beyond basic 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?
The input schema has 100% description coverage, with one optional parameter 'user' documented as 'User wallet address (optional, defaults to configured wallet)'. The description adds minimal value beyond the schema by restating that it retrieves fills 'for the configured wallet or a specific user', which aligns with the schema's description. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't provide additional parameter details like format examples or constraints.
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: 'Get trading history (fills) for the configured wallet or a specific user'. It specifies the verb ('Get'), resource ('trading history (fills)'), and scope ('configured wallet or a specific user'). However, it doesn't explicitly differentiate from sibling tools like 'get_user_fills_by_time', which appears to be a time-filtered variant, so it doesn't reach the highest clarity level.
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 context by mentioning 'configured wallet or a specific user', suggesting this tool retrieves fills for either the default wallet or a specified one. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_user_fills_by_time' or other sibling tools, nor does it specify any prerequisites or exclusions. This leaves some ambiguity for the agent in selecting between similar 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 provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this requires authentication, rate limits, pagination behavior, error conditions, or what format the trading history returns. For a data retrieval tool with zero annotation coverage, this is insufficient.
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, efficient sentence with zero wasted words. It's appropriately sized and front-loads the core functionality without unnecessary elaboration.
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 read-only data retrieval tool with good schema coverage but no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context about authentication, response format, or error handling that would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond implying time range filtering. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'trading history (fills)' with scope 'for a specific time range', making the purpose unambiguous. It doesn't explicitly differentiate from sibling 'get_user_fills' (which lacks time parameters), but the time range specification provides implicit distinction.
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 when needing fills within a time range, but provides no explicit guidance on when to use this versus 'get_user_fills' (which presumably returns all fills without time filtering). No alternatives, exclusions, 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.

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 MCP server](https://glama.ai/mcp/servers/t3rmed/hyperliquid-mcp/badges/card.svg)](https://glama.ai/mcp/servers/t3rmed/hyperliquid-mcp)

Score Badge

Copy to your README.md:

[![hyperliquid-mcp MCP server](https://glama.ai/mcp/servers/t3rmed/hyperliquid-mcp/badges/score.svg)](https://glama.ai/mcp/servers/t3rmed/hyperliquid-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/t3rmed/hyperliquid-mcp'

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