Read-only HIP-4 prediction-market data for Hyperliquid via MCP.
List active markets, current prices, and market summaries
Fetch detailed market metadata and order books for outcome sides
Get OHLCV candle history and recent trades
Query wallet fill history, open orders, and positions
Inspect cross-deployer positions without merging contracts
Use mainnet by default or testnet via env var; no API keys, signing, or trading
Provides a communication channel for the Liquidiction platform, allowing users to engage with the community and receive updates about the prediction market service.
Read-only HIP-4 prediction-market tools for MCP-compatible agents. The server connects directly to Hyperliquid's public API. No API keys, wallet connection or signing permissions are required.
Requires Node.js 20 or newer and npm.
git clone https://github.com/Liquidiction/liquidiction-mcp.git
cd liquidiction-mcp
npm ci
npm startThis is a stdio MCP server, so npm start waits for an MCP client rather than opening a website. Mainnet is the default. Set HL_API_URL=https://api.hyperliquid-testnet.xyz only when you want testnet data.
Existing installations: run git pull --ff-only, npm ci, then restart your MCP client.
Related MCP server: prediction-market-intelligence-mcp
After installing dependencies, configure your client with absolute paths:
{
"mcpServers": {
"liquidiction": {
"command": "node",
"args": [
"/absolute/path/liquidiction-mcp/node_modules/tsx/dist/cli.mjs",
"/absolute/path/liquidiction-mcp/mcp-server.ts"
],
"env": {
"HL_API_URL": "https://api.hyperliquid.xyz"
}
}
}
}This uses the installed runtime and works even when the client's working directory is elsewhere. On Windows, use paths such as C:/Users/you/liquidiction-mcp/mcp-server.ts and the corresponding node_modules/tsx/dist/cli.mjs path. Restart the client after changing its configuration.
For Claude Code:
claude mcp add liquidiction -- node /absolute/path/liquidiction-mcp/node_modules/tsx/dist/cli.mjs /absolute/path/liquidiction-mcp/mcp-server.tsFor clients that launch from the repository directory, npx tsx mcp-server.ts also works.
Tool | Input | Result |
| None | Active outcomes, selections, venues and prices |
|
| Metadata, venue, selections and side prices |
| None | Market overview and available settlement metadata |
|
| Top bids, asks and spread |
| None | Current outcome mid-prices |
|
| OHLCV history |
|
| Recent public trades for the selected outcome side |
|
| Recent public HIP-4 fills for a wallet |
|
| Public resting HIP-4 orders |
|
| Positions, venues, selections, held shares and mark values |
Outcome API requests use #N. Explicit coin inputs also accept +N, legacy @N and bare numeric aliases and normalize them to #N. Wallet balances returned as +N retain their raw coin and also expose the canonical #N identifier. Ordinary spot @N rows are not classified as outcome holdings or fills.
Ask your agent:
Show the HIP-4 positions for this wallet, including venue, team, total shares and held shares. Compare positions on the same fixture without merging their contracts.
get_user_positions returns JSON text with address, fetchedAt, source, a snapshot note and a positions array. Each row includes:
coin, rawCoin, outcomeId, side, venue and deployer address.
Market and selection labels resolved from the contract metadata when available.
shares, the original total string, heldShares and unheldShares.
markPrice and markedValue, or null when a valid mark is unavailable.
Available contract timing, result source and counted-play fields, plus raw descriptions.
Do not assume side 0 means the same team across venues. Outcome and trade.xyz can list a fixture in opposite participant order. The tools preserve distinct contracts and their rules; they do not certify equivalence or automatically merge positions.
unheldShares is total minus held shares, not a guarantee that an order can execute. Reads are not an atomic snapshot. Marks are estimates, not executable sale quotes. Missing active-market metadata remains null; this server does not supply historical metadata for every settled contract.
Supply a known wallet address. This server does not search an index for wallets holding a particular combination of markets.
npm ci
npm run typecheck
npm testThe regression suite runs offline and covers current balance formats, cross-deployer side reversal, held shares, fractional balances, missing marks, input validation and API errors.
An optional read-only smoke check launches a real MCP stdio client and calls all 10 tools against the configured Hyperliquid network:
npm run test:live -- 0xff16003f5bc3560daf4b9df62c191831af47387f 1866The example is a live wallet, so holdings can change. If it no longer has positions, choose another wallet and active outcome ID. The check compares MCP holdings against a separate balance read and can fail if the wallet trades between reads. Normal Hyperliquid rate limits apply.
MIT licensed. This server never submits trades.
Get OHLCV candle data for a prediction market outcome
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Coin identifier, e.g. "#90" | |
| interval | No | Candle interval: "1m", "5m", "15m", "1h", "4h", "1d" | 1h |
| hours | No | Hours of history to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description does not mention any behavioral traits such as data limits, pagination, or rate limits. The description is too brief for a data retrieval tool.
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?
Single sentence, concise and front-loaded. No unnecessary 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?
No output schema; description does not clarify return format (e.g., array of candles with fields). For a tool that fetches historical data, this is a gap. Parameter coverage is adequate.
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 all three parameters with descriptions, so baseline 3. Description adds no extra meaning beyond existing 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?
Clear verb 'Get' and specific resource 'OHLCV candle data for a prediction market outcome'. Distinguishes from siblings like get_prices or get_market_detail which provide different data.
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?
No guidance on when to use this tool compared to alternatives like get_prices or get_recent_trades. Missing conditions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info about a specific market outcome
| Name | Required | Description | Default |
|---|---|---|---|
| outcome_id | Yes | Outcome ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; only 'get detailed info' is stated. Lacks disclosure of what constitutes 'detail', error handling, or data latency. With zero annotation support, description should provide more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and direct. Could be slightly more informative but not verbose.
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?
No output schema exists, and description does not explain return format or structure of 'detailed info'. For a single-param tool, more detail about the response would improve completeness.
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% for the single parameter. Description adds no extra meaning beyond the schema's existing 'Outcome ID' description. 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 states the verb (get), specific resource (market outcome), and scope (detailed info). Distinguishes from siblings like get_market_summary which likely provides aggregated data.
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?
No guidance on when to use this tool versus alternatives like get_market_summary or when not to use. Missing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a rich overview of all markets with probabilities, settlement status, and parsed metadata
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output content (probabilities, settlement status, parsed metadata) but omits behavioral traits like data freshness, pagination, authentication, or side effects. It 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource. Every word adds value, no redundancy. Concise and well-structured.
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?
Given no parameters and no output schema, the description provides a basic sense of return content. However, it is vague on the structure (e.g., format of probabilities, how settlement status is represented) and lacks details like whether results are aggregated or per-market. Adequate but could be more 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?
The tool has no parameters (schema coverage 100%), so baseline is 4. The description does not need to add parameter information, and it correctly avoids mentioning nonexistent params. No improvement needed.
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 states the verb ('Get') and resource ('rich overview of all markets'), and specifies the content (probabilities, settlement status, parsed metadata). This distinguishes it from siblings like 'list_markets' (likely just names) and 'get_market_detail' (single market).
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 implies use when you need an overview of all markets, but provides no explicit guidance on when to use it vs. alternatives, nor any exclusions or prerequisites. For example, it doesn't mention when 'get_market_detail' would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get open orders for a user address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | User wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It only states it gets data but does not disclose behaviors like whether orders are sorted, paginated, or require authentication. No mention of side effects (read-only is implied). Minimal transparency.
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?
Extremely concise: one sentence of 8 words. No fluff. Front-loaded with verb and resource.
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 tool with 1 required param and no output schema, the description is too minimal. It does not explain what the return data looks like, error cases, or any constraints. With no annotations, more context is needed.
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% with one parameter 'address' described as 'User wallet address'. The description adds no extra meaning beyond the schema. 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?
Clear verb 'Get' and resource 'open orders' with a qualifier 'for a user address'. It distinguishes itself from siblings like 'get_candles' by specifying the context, but does not explicitly differentiate from similar order-related tools like 'get_user_fills' or 'get_user_positions'.
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?
No guidance on when to use this tool versus alternatives such as 'get_user_fills' or 'get_orderbook'. No mention of prerequisites or typical use cases. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get order book for a specific outcome side
| Name | Required | Description | Default |
|---|---|---|---|
| outcome_id | Yes | Outcome ID | |
| side | No | Side (0=Yes/first, 1=No/second) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, or describe what happens with invalid inputs, rate limits, or pagination. The description lacks behavioral context beyond the basic purpose.
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 sentence of 8 words, conveying the essential information without any filler. It is efficient and well-structured.
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?
Given the lack of output schema and annotations, the description should offer more context about the return format (e.g., bids/asks) or any constraints. It currently only states the purpose, leaving the agent uninformed about what data to expect.
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 descriptions exist for both parameters. The tool description adds the phrase 'for a specific outcome side', which slightly reinforces the side parameter's purpose but does not add new meaning beyond the schema's own descriptions. Baseline 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 states the verb 'Get' and the resource 'order book' with a specific qualifier 'for a specific outcome side'. This precisely conveys the tool's function and distinguishes it from sibling tools like get_prices or get_recent_trades.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_prices). The description omits context about when an order book is needed vs other market data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current mid prices for all outcome coins
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It correctly implies a read-only operation, but it does not mention caching, rate limits, or data freshness. For a simple get, this is adequate but not thorough.
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 concise sentence of eight words, front-loading the key information without any wasted words. It is appropriately sized.
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?
Given no output schema, the description should clarify the return format and semantics of 'mid prices'. It does not specify whether the output is a single number, a list, or a mapping by coin. This lack of detail reduces completeness.
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 tool has no parameters and schema coverage is 100% (trivially). The description does not add parameter information, but none is needed. The baseline for zero-parameter tools is 4.
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 states the tool retrieves current mid prices for outcome coins. It specifies the action ('get') and the resource ('mid prices') with a scope ('all outcome coins'), but it does not explicitly distinguish it from sibling tools like get_market_summary, which might also return price-related data.
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?
No guidance is provided on when to use this tool versus alternatives such as get_candles or get_market_detail. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent trades for a prediction market outcome
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Coin identifier, e.g. "#90" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks important behavioral details such as the time range of 'recent', pagination, or response structure. With no annotations and no output schema, the agent has minimal insight into side effects or data constraints.
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, well-structured sentence that front-loads the action and resource, with no redundant or extraneous content.
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 description is too minimal for a tool with no output schema and no annotations. It fails to explain what constitutes 'recent' or what fields the result contains, leaving the agent underinformed about the tool's behavior.
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?
While the input schema covers 100% of parameters, the description adds context by linking the 'coin' parameter to a 'prediction market outcome', clarifying its semantic role beyond the schema's generic identifier description.
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 states the action ('Get recent trades') and the target resource ('prediction market outcome'), making the purpose immediately understandable. However, it does not differentiate from sibling tools that also retrieve market data, such as get_candles or get_orderbook.
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?
No guidance is provided on when to use this tool versus alternatives like get_candles or get_prices. The agent is left to infer the appropriate context 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.
Get trade history for a user address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | User wallet address | |
| limit | No | Max number of fills to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states 'Get trade history' implying read-only, but does not disclose details such as ordering, pagination, or what constitutes a 'fill'. The behavioral impact is minimally described.
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 clear sentence without unnecessary words. It is appropriately sized for a simple tool, though could include more context.
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?
Given the tool has only 2 parameters and no output schema or annotations, the description is adequate but minimal. It lacks details like default behavior for limit or return structure.
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% with descriptions for both parameters. The description does not add additional meaning beyond the schema, so 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 'Get trade history for a user address' uses a specific verb ('Get') and resource ('trade history') with a clear subject ('user address'). It distinguishes itself from siblings like 'get_recent_trades' and 'get_user_positions' by focusing on filled trades for a specific user.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_recent_trades' or 'get_open_orders'. The description lacks context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current outcome share positions for a user
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | User wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as idempotency, authentication requirements, or rate limits. The description 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Efficiently conveys the tool's purpose.
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 tool with one parameter and no output schema, the description is minimally adequate. However, it lacks usage context and behavioral details that would help an agent.
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% with a single parameter 'address' described as 'User wallet address'. The description adds no extra meaning beyond the schema, so 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 states the specific verb 'Get' and resource 'current outcome share positions' for a user, clearly differentiating from siblings like get_open_orders or get_user_fills which deal with orders or fills.
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?
No guidance on when to use this tool versus alternatives. For example, it does not explain when to use this vs get_user_fills or get_open_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all prediction markets with current prices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 disclosing behavioral traits. It does not mention whether the operation is read-only, rate limits, data freshness, or any side effects. It only states the basic function.
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, clear sentence with no wasted words. It is front-loaded and 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?
For a simple tool with no parameters and no output schema, the description provides the essential information. It could mention the return structure, but the current phrasing is sufficient to understand the tool's purpose.
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 parameters, so the description does not need to add parameter semantics. The baseline score for 0 parameters is 4, and the description is adequate.
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 states the action ('list'), the resource ('all prediction markets'), and what is included ('current prices'). It distinguishes from sibling tools like get_market_detail (focused on one market) and get_prices (likely price-specific).
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 implicitly indicates when to use this tool: when one needs an overview of all markets with their current prices. However, it lacks explicit guidance on when not to use it or alternatives, though the context of sibling tools provides some clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_candlesget_market_detailget_market_summaryget_open_ordersget_orderbookget_pricesget_recent_tradesget_user_fillsget_user_positionslist_marketsScored across 10 tools
Each tool targets a distinct data type (candles, market details, orders, etc.) with clear descriptions, though some overlap exists between get_market_detail, get_market_summary, and get_prices. Overall, an agent can distinguish them.
All tools follow a consistent verb_noun pattern with 'get_' except one using 'list_', which still aligns with a verb+noun convention. No mixing of styles or ambiguous verbs.
10 tools is well-scoped for a read-only prediction market data server. Each tool serves a specific data retrieval need without unnecessary duplication or gaps.
The set covers all essential read operations for prediction markets: listing, details, prices, orderbook, user data. Minor gaps exist, such as aggregated market statistics or historical trade summaries, but core workflows are supported.
Hyperliquid - 2 tools for perpetuals, options, and position data
Hosted Hyperliquid MCP server: query OHLCV, funding and positioning data in plain language with a free API key.
Real-time & historical Hyperliquid/Lighter: L4/L2/L3, fills, funding, OI, liquidations, candles
Live prices, perps, prediction markets and a paper trading desk over one MCP.
