hyperliquid-mcp

Server Quality Checklist

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

Latest release: v0.0.1-1
Disambiguation4/5
The tools are mostly distinct, with clear separation between spot and perp clearinghouse states, and different order-related queries (status, open, history). There is slight potential confusion between 'order' and 'get_order_status', but descriptions clarify the intended purpose.
Naming Consistency3/5
Most read-only tools follow the 'get_' prefix convention, but 'order', 'cancel_order', and 'transfer_spot_perp' do not, mixing bare verbs with the prefix pattern. The names are readable but not fully consistent in style.
Tool Count5/5
With 12 tools, the server is well-scoped for its purpose, covering account state, order lifecycle, market data, and transfers without being overwhelming. Each tool serves a clear function within the trading domain.
Completeness4/5
The tool set covers core trading workflows, including querying state, managing orders, and fetching market data. Minor gaps exist, such as no explicit trade history, modify order capability, or position-specific endpoints, but these are workable for most use cases.
Average 3.3/5 across 12 of 12 tools scored. Lowest: 2.3/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
With no annotations, the description offers no behavioral transparency. It doesn't disclose side effects, execution semantics, authentication requirements, or whether this is a real trade order. The only implication is that it creates an order, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but underspecified for a tool with 11 parameters. It lacks structure or additional context, but it is not verbose. Under-specification makes it less useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and no annotations. The description is only one sentence, leaving out critical information about order execution, return value, risk, and usage context. This is highly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description does not explain any of the 11 parameters. Param names like 'is_buy' and 'limit_px' are partially self-explanatory, but the description adds no semantics, default values, or relationships.
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 an order) and the platform (Hyperliquid), distinguishing it from sibling tools like cancel_order and get_order_status. It lacks specifics on order types or asset classes, but the core purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'Request' implies a read operation, but there is no indication of what the response contains, whether any side effects occur, or any access requirements. This falls short of the transparency needed for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is structurally concise. However, it does not earn its place because it merely restates the tool name in a slightly expanded form. It is under-specified rather than genuinely informative, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what 'spot trading metadata' actually includes. It does not, leaving the agent to guess whether this returns fees, trading rules, or other information. The description is too sparse to be considered complete for a tool with no other structured context.
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 schema coverage is trivially 100%. There is nothing for the description to add to parameter semantics because no parameters exist. Baseline of 4 is appropriate for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Request spot trading metadata' is a near-tautology of the tool name 'get_spot_meta'. While it names a verb and resource, 'metadata' is vague and does not specify what the metadata actually contains, nor does it distinguish this tool from sibling getters like get_spot_clearinghouse_state or get_all_mids.
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. There is no mention of prerequisites, use cases, or why an agent would choose get_spot_meta over other getters. The description simply states a generic action without any contextual direction.
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 explaining behavioral traits. It only states the action without disclosing effects, failure modes, or how order identification works. This is insufficient for a mutation operation.
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 concise sentence with no wasted words. However, it is very sparse and could be structured to include essential context while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and no parameter details, the description is vastly under-specified for a cancellation tool. The agent cannot know what response to expect, how to identify the correct order, or what side effects occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not explain the meaning of 'coin' or the union type 'o' (number/string). The agent is left without any hint about how to specify the order to cancel.
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 ('Cancel') and the resource ('an order on Hyperliquid'). This distinguishes it from sibling tools like 'order' (create) and 'get_order_status' (query).
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, how it relates to alternatives, or any prerequisites (e.g., order must be open). The description is purely factual with no 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 the full burden of behavioral disclosure. It states the action is a 'Get' (implying read-only) and mentions the default behavior for missing user, but it does not disclose potential side effects, permission requirements, rate limits, or output format. The added default behavior is useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, front-loading the purpose in the first sentence. However, the phrasing is slightly awkward with a comma splice, but it remains concise and readable. Every clause contributes to the core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the main behavior and the default parameter case. However, it lacks context on return value structure, error handling, or whether any authentication is needed, which would be necessary for full agent autonomy. The complexity is low, so this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'user' parameter, but the description adds meaningful context by explaining that omitting the parameter returns the wallet address's clearinghouse state. This adds semantic value beyond the schema's tautological description, earning a score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the clearinghouse state of a user, with a specific verb ('Get') and resource ('clearinghouse state'), and distinguishes by the tool name from the sibling get_spot_clearinghouse_state. However, it does not explicitly mention 'perp' in the description, relying on the tool name for 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 explicit guidance on when to use this tool versus alternatives like get_spot_clearinghouse_state or get_order_status. It only notes the fallback behavior when no user is provided, which is a parameter detail rather than usage 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 the full burden of behavioral disclosure. It only states 'Get candlestick data', which implies a read operation but does not disclose the response format, whether data is historical or live, any rate limits, or how the snapshot is constructed. This lack of behavioral context leaves the agent uncertain about side effects and return expectations.
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 concise sentence, front-loaded with the action and resource. It is efficient with no wasted words, though it is terse enough to omit context that could be valuable. The structure is straightforward, but the brevity slightly reduces its effectiveness.
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 there is no output schema and no annotations, the description is insufficiently complete. It does not explain the structure of the returned data, time range handling, or any restrictions. The tool has four parameters, and the description only gives a high-level purpose without covering operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the description adds no additional parameter semantics. The description's mention of 'a token' aligns with the 'coin' parameter but does not add meaningful detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and identifies the resource as 'candlestick data for a token on Hyperliquid', which clearly distinguishes it from sibling tools dealing with orders, positions, or market metadata. The tool name and description align, leaving no ambiguity about the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, and does not mention exclusions or alternative tools. Usage must be inferred from the tool name and the phrase 'candlestick data', making it implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it gets the L2 book, omitting details about return structure, number of levels, aggregation, or whether it covers both spot and perp tokens. The description adds little beyond the tool's name.
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, front-loaded sentence with no redundant or filler content. It is appropriately sized for the minimal information it contains.
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 an order book tool with no output schema and no parameter elaboration, the one-sentence description leaves critical details unspecified, such as the depth levels returned, formatting, and whether both spot and perpetual markets are supported. The description is not complete enough for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema includes a description for 'coin' that says 'to get the price of', which is inconsistent with the tool's purpose of fetching the L2 book. With schema coverage at 50% and no additional parameter clarification in the tool description, this misalignment reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the L2 order book for a token on Hyperliquid, using a specific verb and resource. It distinguishes from sibling tools like get_all_mids or get_candle_snapshot by targeting the order book depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; there is no mention of when to use this tool versus alternatives like get_all_mids for mid prices or get_candle_snapshot for historical data. The intended use is implied by the name and description, but explicit exclusions or alternative recommendations are absent.
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 restates the operation ('Get') without adding context such as read-only nature, auth requirements, rate limits, or response behavior. The verb 'get' implies read-only, but no explicit behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool, the description is minimally adequate but lacks details on return format, error conditions, or whether the order ID must already exist. With no output schema or annotations, more explanation of the response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'user' and 'oid' having descriptions. The tool description adds no extra semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('status of an order on Hyperliquid'). It distinguishes itself from sibling tools like get_open_orders and get_order_history by focusing on a single order's current status via an order ID.
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 explicit guidance on when to use this tool versus alternatives. While the name implies usage for checking a specific order's status, there is no mention of prerequisites, alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It discloses a key default behavior: if no user is provided, the clearinghouse state of the wallet address is returned. However, it does not explain what the clearinghouse state includes, whether it is read-only, or any rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and the key conditional behavior without unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description is adequate but not complete. It explains the default user behavior but does not describe the structure or content of the returned 'clearinghouse state', which could be important for an agent to use the tool effectively. The presence of a similar sibling tool also suggests a bit more explicit differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'user' parameter (100% coverage), but the tool description adds meaningful context by clarifying the optional behavior: when the parameter is omitted, the wallet address's state is returned. This goes beyond the schema's bare description and helps the agent understand the parameter's optionality and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the clearinghouse state of a user on Hyperliquid. The tool name includes 'spot' to differentiate from the sibling 'get_perp_clearinghouse_state', but the description itself uses the generic phrase 'clearinghouse state' and does not explicitly mention 'spot', so it partially relies on the name for disambiguation.
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 such as get_perp_clearinghouse_state. The description does not provide context about distinguishing spot from perp clearinghouse state or mention any exclusions, leaving the agent to infer usage from the tool name alone.
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 a read-only 'get' action, but does not disclose response format, data freshness, pagination, or any potential side effects. The description is minimal and adds little beyond the tool's name.
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, clear sentence with no wasted words. It perfectly front-loads the action and resource, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description fully conveys the tool's purpose. While it doesn't detail the return structure, the simplicity of the operation makes that a minor gap. The description adequately covers what an agent needs to know for selection.
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, making schema coverage 100% by default. The description's phrase 'for all coins' matches the lack of filtering parameters, so no additional parameter explanation is needed. A baseline of 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('mid prices for all coins on Hyperliquid'), making the purpose immediately clear. It distinguishes itself from siblings like get_l2_book or get_candle_snapshot by focusing on mid prices across all coins.
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 a clear use case—fetching mid prices for all coins—but does not explicitly contrast this with alternatives like get_l2_book or get_spot_meta. It provides context but no explicit '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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does disclose a key behavior: if no user is specified, the tool returns the order history of the wallet address. However, it omits details such as authentication requirements, output format, and any potential limitations or side effects, leaving some important aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys both the main action and an important conditional behavior. It is concise and front-loaded with the core purpose, though the sentence structure could be slightly clearer. Overall, it is appropriately sized without unnecessary padding.
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 relatively simple, but the description lacks details about the expected format of the 'user' parameter (e.g., address or username), any pagination or limits, and the structure of the returned order history. Since there is no output schema, these gaps make the description only partially complete for an agent to use confidently.
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 covers the parameter 'user' with a description, but the tool description adds meaningful semantic value by explaining the optionality and default behavior ('if no user is provided, the order history of the wallet address will be returned'). This goes beyond the schema's basic description and clarifies the parameter's role.
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 ('Get') and resource ('all order history') on Hyperliquid. It distinguishes from sibling tools like get_order_status and get_open_orders by implying the full historical scope. This is a strong, unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an important usage note about default behavior when no user is provided, which helps with parameter handling. However, it does not explicitly compare with sibling tools or state when to use this versus alternatives, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the default behavior of returning the wallet address's open orders when no user is provided, but does not mention return format, pagination, or potential errors. For a simple read tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the main purpose front-loaded and a conditional clause explaining the default behavior. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, no output schema, and no annotations. The description covers the core functionality and the default behavior, which is sufficient for a simple read operation. It could mention the return type or address format, but these are likely obvious from context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the user parameter, but the schema text is awkward and does not clarify optionality. The description adds the important nuance that omitting user returns open orders for the wallet address, which goes beyond the schema and provides meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all open orders on Hyperliquid, specifying the verb and resource. It also distinguishes from sibling tools like get_order_history or get_order_status by focusing on open orders, and clarifies the default behavior when no user is provided.
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 using this tool when you need current open orders, and the default wallet address behavior is stated. However, it does not explicitly compare to alternatives or mention when not to use it, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that direction depends on the toPerp value, but does not specify which value maps to which direction. It also omits details about reversibility, fees, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the core function and the key controlling parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter transfer tool without an output schema, the description covers the essential action. However, it lacks explicit mapping for the boolean value and doesn't mention any account prerequisites or common edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the role of the toPerp parameter (direction flag), but ignores the amount parameter's format or constraints. With 0% schema coverage, it only partially compensates for the missing 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 transfers funds between spot and perp, with direction determined by a boolean flag. This distinguishes it from all sibling tools, which are read-only or order management.
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 context is clear: this is the only transfer tool among siblings, so usage is implied when moving funds between spot and perp. It doesn't explicitly exclude alternatives or list prerequisites, but no competing tool exists.
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/Impa-Ventures/hyperliquid-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Impa-Ventures/hyperliquid-mcp)

Score Badge

Copy to your README.md:

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

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