Non-custodial Hyperliquid perpetual-futures trading for Claude, Cursor and any MCP client: live market data, orderbook, candles, account state and — once the user arms it — order execution with on-chain leverage on the user's own wallet. No withdraw tool, server-enforced caps.
Use this when the user asks to cancel a resting or trigger order by its oid (from get_my_open_orders).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The Hyperliquid order id (oid) to cancel — see get_my_open_orders |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds that the cancellation applies to resting/trigger orders and that the oid comes from get_my_open_orders, but doesn't elaborate on side effects, reversibility, or failure modes beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the trigger condition and includes the necessary identifier provenance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter cancellation tool with strong annotations and a clear description, this is essentially complete. It could mention what the response or result looks like, but that's not required given the simplicity and the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents order_id. The description's reference to get_my_open_orders for obtaining the oid adds slight context but is essentially echoed in the schema description, providing no meaningful extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('cancel'), identifies the resource ('resting or trigger order'), and specifies the identifier source ('by its oid from get_my_open_orders'). This clearly distinguishes it from sibling tools like place_order, close_position, and set_position_tp_sl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use this when the user asks to cancel...'), which is clear context. However, it doesn't enumerate when-not-to-use scenarios or explicitly name alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks to close (fully or partially) an open Hyperliquid position. Risk-reducing: works whenever agent trading is armed.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Partial close size in coins. Omit to close the entire position | |
| symbol | Yes | Coin symbol of the open position, e.g. BTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and non-readonly. The description adds meaningful behavioral context by noting it is risk-reducing and only available when agent trading is armed, which is not otherwise visible. No contradiction with the annotations found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the use case and then give the key risk/availability context. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter close action, the description plus schema covers the core usage, full/partial close, and a key precondition. A return payload is not specified, but no output schema exists and the action's success can likely be inferred; still, a brief note on the response would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both `symbol` and optional `size`. The description's 'fully or partially' wording reinforces the size semantics but does not add much information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific trigger ('when the user asks to close...') and identifies the exact resource ('an open Hyperliquid position'), including fully or partially. This clearly differentiates it from siblings like place_order or set_position_tp_sl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use the tool ('when the user asks to close...') and adds an operational precondition ('works whenever agent trading is armed'). It does not explicitly name alternatives or negative conditions, but the use case is clear enough for an agent to route to it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants OHLCV candle history for a Hyperliquid perp market (for analysis or charting).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of candles | |
| symbol | Yes | Coin symbol, e.g. BTC | |
| interval | No | Candle interval | 1h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate those. It adds that the tool returns historical OHLCV data, but it does not disclose output shape, ordering, pagination, or any other behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
This is a single, front-loaded sentence that clearly states the trigger condition and the domain of the tool. There is no redundant wording or unnecessary background information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only candle-history tool, the description, schema, and annotations together cover the essential selection and invocation information. Minor gaps are the lack of explicit sibling differentiation and no description of the return value shape, but those are not critical given the simple output implied by OHLCV.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (symbol, interval, limit) are already well documented structurally. The description adds no extra semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and action: retrieving OHLCV candle history for a Hyperliquid perp market. This semantically distinguishes the tool from siblings like get_price and get_orderbook by specifying candle history and the charting/analysis use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: when the user wants OHLCV candle history. It does not mention when not to use it or name sibling alternatives, but the use-case framing provides clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which perpetual markets are tradable on MCPify (Hyperliquid), or for a market overview with prices, 24h change, volume, funding and max leverage.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order | volume |
| limit | No | Max rows | |
| search | No | Filter by symbol substring, e.g. BTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that the response includes prices, 24h change, volume, funding, and max leverage, which informs expectations about returned data. It does not discuss pagination, rate limits, or real-time characteristics, but those are not critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a clear trigger and data fields, front-loaded with the usage condition. No filler, no redundant wording, and every phrase earns its place. Extremely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers the key elements: when to use it and what data is returned, and the schema fully documents optional parameters. No output schema exists, but the description partially compensates by naming the returned metrics. It does not explicitly mention sorting/limiting behavior, though that is covered in the schema. Overall, complete enough for a straightforward read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (sort, limit, search) are fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema already provides. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (perpetual markets on MCPify/Hyperliquid) and the purpose (listing tradable markets or providing an overview with prices, 24h change, volume, funding, and max leverage). It stops short of explicitly naming sibling tools to differentiate, but the overview phrasing helps distinguish it from price or candle tools. Clear verb/resource and use case, though lacking direct sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Use this when...' gives explicit trigger conditions: user asks about tradable perpetual markets or wants a market overview. These conditions are specific enough to route an agent correctly. It does not mention when not to use the tool or name alternative tools, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about THEIR MCPify account: balance, withdrawable, open positions with PnL and liquidation prices, and whether agent trading is armed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile: readOnlyHint true and destructiveHint false. The description adds useful context about what account data is returned, but doesn't disclose additional behavioral traits such as data freshness, auth requirements, or response formatting. It also doesn't contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence: the trigger condition comes first, followed by a compact list of data categories. There is no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only account summary, the description is complete: it covers balance, withdrawable, open positions with PnL and liquidation prices, and agent trading arming state. An agent has enough to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the description carries essentially no parameter burden. It adds selection semantics by describing the user request that maps to this tool, which is appropriate for a parameterless tool. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly maps a user intent to a resource: 'Use this when the user asks about THEIR MCPify account' followed by a specific data scope. It distinguishes itself from order-, trade-history-, and position-management siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions ('when the user asks about their account') and the exact data topics included. It does not name alternatives or exclusions, but the sibling names such as get_my_open_orders and get_my_trade_history make the boundary easily inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for their open/resting orders on Hyperliquid (including TP/SL trigger orders). Returns each order's oid for cancellation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior, so the bar is lower. The description adds meaningful context by clarifying that TP/SL trigger orders are included and that the returned oid is intended for cancellation. This explains what the agent can do with the result beyond simply reading 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver all essential information with no fluff. The usage trigger is front-loaded, and the value of the return field is stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is complete: it defines the scope, includes a subtle edge case (TP/SL triggers), and states the useful return value. No output schema exists, so mentioning the oid is sufficient for an agent to understand how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides complete coverage vacuously. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description correctly implies that no inputs are required and the tool operates directly on the current user's orders.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' with a clear resource: the user's open/resting orders on Hyperliquid. It explicitly includes TP/SL trigger orders, which distinguishes it from order history or trade history tools. The stated purpose of returning each order's oid also signals a direct link to cancellation workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with 'Use this when the user asks for their open/resting orders,' giving clear invocation context. It does not explicitly name sibling alternatives like get_my_order_records, but the phrase 'open/resting' versus historical records provides enough differentiation for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what orders were placed through MCPify (our audit records, including which source placed them: web, mcp agent, admin) — successes and rejections alike.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of records | |
| action | No | Filter by action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful scope beyond annotations—audit records, sources, and inclusion of both successes and rejections—but does not disclose return format or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; it front-loads the exact trigger and key scoping details. Every phrase contributes to selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two documented parameters, the description is adequate. It does not describe the return shape, but the absence of an output schema is mitigated by the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with limit and action fully described in the schema. The description does not add parameter-level meaning beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the operation as retrieving MCPify audit order records, including which source placed them and both successes and rejections. It is specific about the resource, though it does not explicitly name sibling tools like get_my_open_orders or get_my_trade_history to contrast against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user asks what orders were placed through MCPify" is an explicit trigger condition. It lacks explicit when-not-to-use guidance or alternative tool mentions, but the scope is clear enough for an agent to select it for audit/order queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for their recent fills/executions on Hyperliquid (live venue truth: price, size, fee, realized PnL).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of fills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about 'live venue truth' and the returned fields, but does not disclose pagination, data retention, or response shape beyond the field list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the trigger and the key returned data with zero filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and annotations covering side effects, the description is sufficient. It lists the important return fields despite no output schema, and the trigger phrase covers user intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the only parameter (limit) fully with description, default, min, and max. The description adds no further parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('recent fills/executions') and the specific venue (Hyperliquid), with a concrete list of returned fields. It distinguishes this tool from siblings like get_my_order_records by emphasizing filled trades rather than orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this when the user asks for their recent fills/executions', giving a clear trigger condition. It does not mention alternatives or when not to use it, but the condition is specific enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the live order book (bids/asks) for a Hyperliquid perp market.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Levels per side | |
| symbol | Yes | Coin symbol, e.g. BTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the context that the data is 'live,' but does not disclose additional behavior such as pagination, rate limits, or response shape, so the value beyond annotations is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states the invocation condition and the resource, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and a clear schema, the description is nearly sufficient. It could mention what the response contains (e.g., arrays of bids and asks at a given depth), but that is largely inferable from 'bids/asks' and the 'depth' parameter. Minor gap, not a significant one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (symbol and depth) are already documented with types and constraints. The description does not add new parameter semantics beyond implying the order book contains bids/asks, which is already known from the tool name. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'wants the live order book (bids/asks) for a Hyperliquid perp market.' This clearly identifies the tool's function and distinguishes it from siblings like get_price, get_markets, and get_candles by naming the unique data object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit trigger condition ('Use this when the user wants the live order book'), making when to use the tool clear. However, it does not mention alternatives or exclusion cases, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks the current price of a specific coin on Hyperliquid (mark price, 24h change, volume, funding).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Hyperliquid perp coin symbol, e.g. BTC, ETH, xyz:TSLA (not BTCUSDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds expected data fields but does not disclose response format, error behavior, or symbol validation beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tightly scoped sentence that front-loads the usage trigger and lists the relevant outputs. No unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter read-only tool, the description adequately conveys what the tool returns and when to use it. It does not specify output formatting, but that is a minor gap given the low complexity and clear annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, symbol, is well described with examples and an exclusion. The description adds little beyond the schema, which is acceptable given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 current price of a specific coin on Hyperliquid and lists the included data points (mark price, 24h change, volume, funding). It distinguishes well from siblings like get_candles or get_markets, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: use when the user asks for the current price of a specific coin. It does not mention alternatives or exclusions, but the context is clear enough for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user explicitly asks to open a perp position or place an order on Hyperliquid via MCPify. Real funds — ALWAYS call preview_order with the same arguments first, show the user the proposal, and get their explicit confirmation; place_order is refused unless a matching preview ran within the last 10 minutes. Requires Agent Trading enabled on the MCPify settings page.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Position direction | |
| symbol | Yes | Hyperliquid perp coin symbol, e.g. BTC, ETH, SOL (not BTCUSDT) | |
| leverage | No | Leverage multiplier | |
| stop_loss | No | Stop-loss trigger price | |
| margin_usd | Yes | USDC margin to commit. Position notional = margin × leverage | |
| order_type | No | Execution type | market |
| limit_price | No | Required when order_type is limit | |
| margin_mode | No | Margin mode | cross |
| take_profit | No | Take-profit trigger price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by warning that this involves 'Real funds,' requiring explicit user confirmation, and explaining that place_order refuses execution unless a matching preview ran within 10 minutes. It also discloses the prerequisite that Agent Trading must be enabled, adding context not present in the schema or annotations. No contradiction with readOnlyHint=false or destructiveHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The first sentence states the purpose, the second front-loads the critical safety workflow (preview before order, confirmation, refusal rule), and the third states the prerequisite. Every sentence earns its place and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes, destructive order placement tool with nine parameters and no output schema, the description covers the essential context: when to use it, the mandatory preview flow, user confirmation, the 10-minute expiry, and required settings. It also names the sibling preview_order to route the agent correctly. No critical gap is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 nine parameters thoroughly. The description does not add parameter-level meaning, but the mention of 'with the same arguments' ties the parameters to the preview step, offering a small degree of additional context. This meets the baseline for a fully self-documenting schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'open a perp position or place an order on Hyperliquid via MCPify.' It clearly distinguishes this tool from siblings like cancel_order, close_position, and preview_order by defining the exact user intent that triggers it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool — when the user asks to open a perp position or place an order — and provides an explicit alternative: 'ALWAYS call preview_order with the same arguments first.' It also gives a hard precondition (matching preview within 10 minutes) and a configuration requirement (Agent Trading enabled), leaving no ambiguity about sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this BEFORE place_order whenever the user wants to open a position: it validates and sizes the order (fresh est. entry, size after rounding, est. liquidation, TP/SL sanity, MCP caps) WITHOUT placing anything, and shows a proposal card the user can confirm from. Read-only and always safe to call. If the user confirms, call place_order with the same arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Position direction | |
| symbol | Yes | Hyperliquid perp coin symbol, e.g. BTC, ETH, SOL (not BTCUSDT) | |
| leverage | No | Leverage multiplier | |
| stop_loss | No | Stop-loss trigger price | |
| margin_usd | Yes | USDC margin to commit. Position notional = margin × leverage | |
| order_type | No | Execution type | market |
| limit_price | No | Required when order_type is limit | |
| margin_mode | No | Margin mode | cross |
| take_profit | No | Take-profit trigger price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral detail: it performs validation and sizing, shows a proposal card, and is 'always safe to call.' This discloses side-effect-free behavior and the user-facing outcome without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a clear purpose: when to use, what it does, and what to do next. There is no redundancy or filler, and the most important directive is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description adequately covers the tool's role, its safety profile, and its interplay with place_order. It also tells the agent what the user sees (proposal card), making the tool fully usable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are already documented in the schema. The description adds context about validation/sizing but does not provide per-parameter meaning beyond what the schema gives, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('preview'), names the resource ('order'), and clearly states that it validates and sizes an order WITHOUT placing anything. It explicitly distinguishes itself from place_order, so an agent can instantly tell what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool BEFORE place_order whenever the user wants to open a position, and it directs the agent to call place_order with the same arguments if the user confirms. This gives both a clear usage condition and an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks to set or update take-profit / stop-loss on an open Hyperliquid position. Replaces any existing TP/SL triggers for that coin.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin symbol of the open position, e.g. BTC | |
| stop_loss | No | New stop-loss trigger price | |
| take_profit | No | New take-profit trigger price |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=false, safe=false, destructive=false), lowering the burden on the description. It adds genuinely useful behavioral context: 'Replaces any existing TP/SL triggers for that coin' warns that prior triggers are overwritten rather than merged. A residual ambiguity about whether passing one price also wipes the other trigger keeps this from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with zero filler: the routing instruction comes first, the behavioral warning second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a low-complexity tool: 3 flat params, full schema coverage, and annotations carrying the safety profile. Gaps remain that could mislead an agent — behavior when no open position exists for the symbol, whether this places a live exchange mutation, and the precise scope of trigger replacement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — all three params (symbol, stop_loss, take_profit) are described with types and meanings, so the baseline is 3. The description adds no param-specific detail beyond the overwrite caveat, which the schema already phrases as 'New ... trigger price'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'set or update take-profit / stop-loss on an open Hyperliquid position', which clearly identifies the operation and its target. It does not explicitly name sibling tools for contrast, but the 'open position' scope and TP/SL domain cleanly separate it from place_order, cancel_order, and close_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this when the user asks to set or update take-profit / stop-loss' provides an explicit trigger condition framed in user intent, and the 'open position' clause implicitly excludes entries and informational lookups. It stops short of naming alternatives (e.g., 'use place_order for new entries') or stating exclusions, so routing is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action, but get_markets and get_price overlap in the data they return (price, 24h change, volume, funding), differing mainly by all-markets vs single-coin scope. The descriptions are explicit enough that an agent should rarely misselect, though the boundary is slightly blurry.
All tool names follow a consistent verb_noun snake_case pattern: get_ for reads, plus clear action verbs like place_, preview_, cancel_, close_, and set_. There is no mixing of styles or vague generic verbs.
13 tools is well within the ideal range for a trading-focused server. Each tool covers a distinct part of the workflow without feeling bloated or redundant.
The tool surface covers the full trading lifecycle: market data, account/position/order/trade reads, order preview and placement, cancellation, position closing, and TP/SL management. No obvious dead-ends or missing core operations for the stated Hyperliquid perp trading purpose.