Ein MCP-Server (Model Context Protocol), der KI-Agenten wie Claude, GPT und benutzerdefinierten Agenten direkten Zugriff auf Live-HIP-4-Prognosemarktdaten auf Hyperliquid ermöglicht. Dies ist der erste MCP-Server für Prognosemärkte.
Keine API-Schlüssel erforderlich. Verbindet sich direkt mit der öffentlichen API von Hyperliquid.
Related MCP server: prediction-market-intelligence-mcp
Tool | Beschreibung |
| Alle aktiven Prognosemärkte mit aktuellen Preisen |
| Detaillierte Informationen für eine spezifische Ergebnis-ID |
| Umfassender Überblick mit Wahrscheinlichkeiten, Abwicklungsstatus und geparsten Metadaten |
| L2-Orderbuch (Bids, Asks, Spread) für eine Ergebnisseite |
| Aktuelle Mittelpreise für alle Ergebnis-Coins |
| OHLCV-Kerzendaten für Charting und Analyse |
| Letzte Trades auf einem spezifischen Markt |
| Trade-Historie für eine Wallet-Adresse |
| Bestehende Limit-Orders für eine Wallet |
| Aktuelle Bestände an Ergebnisanteilen und deren Werte |
Fügen Sie dies zu Ihrer Claude Desktop-Konfiguration (claude_desktop_config.json) hinzu:
{
"mcpServers": {
"liquidiction": {
"command": "npx",
"args": ["tsx", "/path/to/liquidiction-mcp/mcp-server.ts"]
}
}
}Starten Sie Claude Desktop neu und versuchen Sie dann:
"Was sind die aktuellen HIP-4-Prognosemarkt-Quoten?"
"Zeige mir das Orderbuch für Ergebnis 13"
"Welche Positionen hält 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 startUmgebungsvariable | Standard | Beschreibung |
|
| Hyperliquid API-Endpunkt |
Setzen Sie dies auf https://api.hyperliquid.xyz für Mainnet-Daten.
"Wie stehen die Quoten für BTC über 71.566 $?"
Verwendet get_market_summary, um alle Märkte abzurufen, findet BTC-Märkte und gibt die aktuellen Wahrscheinlichkeiten zurück.
"Gibt es eine gute Liquidität auf dem Hypurr vs. Usain Bolt Markt?"
Verwendet get_orderbook, um Bid/Ask-Tiefe, Spread und Orderanzahl zu prüfen.
"Was sind meine Positionen und mein PnL?"
Verwendet get_user_positions + get_user_fills, um Bestände und Trade-Historie anzuzeigen.
"Wie hat sich der HYPE-Prognosemarkt in den letzten 24 Stunden bewegt?"
Verwendet get_candles mit 1h-Intervall, um die Preisbewegung im Zeitverlauf anzuzeigen.
HIP-4 (Hyperliquid Improvement Proposal 4) führt Prognosemärkte ein, die nativ auf der L1-Orderbuch-Engine von Hyperliquid laufen. Hauptmerkmale:
Binäre Ergebnisse (Ja/Nein), bewertet in 0-100 Cent
Vollständig besichert (kein Hebel, kein Liquidationsrisiko)
Nutzt dieselbe Infrastruktur wie Perps und Spot
Unterstützt wiederkehrende Märkte (15M, 1H, 1D Zeiträume)
Abwicklung über On-Chain-Orakel
Für angereicherte Daten mit Orderbuch-Tiefe, Volumen und Metadaten:
GET https://testnet.liquidiction.xyz/api/premium/analyticsKostenpflichtig mit 0,001 $/Anfrage über x402 USDC-Mikrozahlungen auf Base Sepolia.
Landingpage: liquidiction.xyz
Twitter: @LiquidictionHL
Telegram: t.me/Liquidiction
Basiert auf: 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.
