Claude、GPT、カスタムエージェントなどのAIエージェントが、Hyperliquid上のライブHIP-4予測市場データに直接アクセスできるようにするMCP（Model Context Protocol）サーバーです。これは予測市場向けの初のMCPサーバーです。
APIキーは不要です。HyperliquidのパブリックAPIに直接接続します。
Related MCP server: prediction-market-intelligence-mcp
ツール | 説明 |
| 現在の価格を含むすべてのアクティブな予測市場 |
| 特定のオウトカムIDの詳細情報 |
| 確率、決済ステータス、解析済みメタデータを含む詳細な概要 |
| オウトカムサイドのL2オーダーブック（買い、売り、スプレッド） |
| すべてのオウトカムコインの現在のミッドプライス |
| チャート作成および分析用のOHLCVローソク足データ |
| 特定の市場での最新取引 |
| ウォレットアドレスの取引履歴 |
| ウォレットの指値注文 |
| 現在のオウトカム保有数と価値 |
Claude Desktopの設定（claude_desktop_config.json）に追加してください：
{
"mcpServers": {
"liquidiction": {
"command": "npx",
"args": ["tsx", "/path/to/liquidiction-mcp/mcp-server.ts"]
}
}
}Claude Desktopを再起動し、以下を試してください：
「現在のHIP-4予測市場のオッズは？」
「オウトカム13のオーダーブックを見せて」
「0x1393...1869はどのようなポジションを持っていますか？」
claude mcp add liquidiction npx tsx /path/to/liquidiction-mcp/mcp-server.tsgit clone https://github.com/Liquidiction/liquidiction-mcp.git
cd liquidiction-mcp
npm install
npm start環境変数 | デフォルト | 説明 |
|
| Hyperliquid APIエンドポイント |
メインネットデータの場合は https://api.hyperliquid.xyz に設定してください。
「BTCが71,566ドルを超えるオッズは？」
get_market_summary を使用してすべての市場を取得し、BTC市場を見つけて現在の確率を返します。
「Hypurr対Usain Bolt市場の流動性は十分ですか？」
get_orderbook を使用して、買い/売りの深さ、スプレッド、注文数を確認します。
「私のポジションと損益は？」
get_user_positions と get_user_fills を使用して、保有資産と取引履歴を表示します。
「HYPE予測市場は過去24時間でどのように動きましたか？」
1時間間隔の get_candles を使用して、時間の経過に伴う価格変動を表示します。
HIP-4（Hyperliquid Improvement Proposal 4）は、HyperliquidのL1オーダーブックエンジン上でネイティブに動作する予測市場を導入します。主な特徴：
0〜100セントで価格設定されるバイナリーオウトカム（Yes/No）
完全担保型（レバレッジなし、清算リスクなし）
パーペチュアルやスポットと同じインフラを共有
繰り返し市場をサポート（15分、1時間、1日周期）
オンチェーンオラクルによる決済
オーダーブックの深さ、ボリューム、メタデータを含む強化されたデータについては：
GET https://testnet.liquidiction.xyz/api/premium/analyticsBase Sepolia上のx402 USDCマイクロペイメントを介して、1リクエストあたり0.001ドルで提供されます。
ランディングページ: liquidiction.xyz
Twitter: @LiquidictionHL
Telegram: t.me/Liquidiction
構築基盤: Hyperliquid
MIT
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.
