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.
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.