Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hyperodds MCP Which HIP-4 markets show the biggest edge after fees right now?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give Claude, Cursor, VS Code or any other MCP client live data on Hyperliquid's HIP-4 outcome markets from every deployer: books, fair lines with their sources, rule comparisons where several deployers list the same question, and the newest listings. Free, with no key to set up.
@hyperodds/mcp runs on your machine over stdio and forwards each request to the hosted Hyperodds
server. It has no dependencies, and its tools are read-only: none can trade or access an account.
Claude Desktop (Settings > Developer > Edit Config), Cursor (~/.cursor/mcp.json, or
.cursor/mcp.json in one project) and Windsurf take this entry:
{
"mcpServers": {
"hyperodds": {
"command": "npx",
"args": ["-y", "@hyperodds/mcp"]
}
}
}Claude Code:
claude mcp add hyperodds -- npx -y @hyperodds/mcpVS Code (.vscode/mcp.json):
{
"servers": {
"hyperodds": { "type": "stdio", "command": "npx", "args": ["-y", "@hyperodds/mcp"] }
}
}The package needs Node.js 22 or later. A client that connects to remote servers can skip it and
use https://api.usehyperodds.com/mcp directly over Streamable HTTP.
Related MCP server: polymarket-mcp
"Which HIP-4 markets show the biggest edge after fees right now?"
"Is the next Fed decision priced the same on every deployer, and do their rules match?"
"Where does the fair line for the BTC markets settling today come from, and how confident is it?"
"What was listed in the last hour?"
Tool | Input | Output |
|
| Markets with bid, ask, fair line, best buy edge after fees, 24h volume, event time and status, plus how many match in total |
|
| One question listed by several deployers: each member's rule grade ( |
|
| One market's fair line: probability and band, method, confidence and flags, each source with its weight and age, plus the book and the edge for buying or selling either side |
|
| Markets in listing order, newest first, with the same fields as |
Your client receives each tool's input and output schema when it connects. The MCP guide explains the numbers.
Each message from the client goes out as one HTTPS request, and its response comes straight back. The bridge keeps no state beyond the protocol version agreed when the client connects. Requests run side by side. If one fails or gets no answer within 30 seconds, the client receives a JSON-RPC error that names the cause; a cancelled request is dropped. When the client closes the connection, the bridge drops what is still in flight and exits.
Prices are decimals from 0 to 1 for a market's first side, often Yes. Edges are percentage points after every fee, including the fee Hyperliquid takes at settlement, for a $100 order: 2.9 means 2.9¢ a share. An edge is null when $100 would not fill.
Price markets take their fair line from Deribit, Bybit and Cboe option surfaces, or from realized
volatility on Hyperliquid perps. Sports and events take theirs from matched Polymarket and Kalshi
quotes. Fair lines are estimates: edge rankings only use lines with a fairConfidence of at least
0.5 and more than one source, so check both before acting on one.
Each IP address gets 1,000 tool calls a day, reset at 00:00 UTC. Every request, tool call or not, also counts toward a rate limit of 5 a second, with bursts of up to 30. Past either limit, the server answers with an error that names it.
Variable | Default | Purpose |
|
| The server to forward to |
Set it in the client entry's env:
{
"command": "npx",
"args": ["-y", "@hyperodds/mcp"],
"env": { "HYPERODDS_MCP_URL": "https://mcp.example.com/mcp" }
}Behind a proxy, add HTTPS_PROXY and NODE_USE_ENV_PROXY=1 to the same env. Node.js reads the
proxy only when the second is set, which needs Node.js 22.21 or later.
npx -y @hyperodds/mcp --help and --version print the usage and the version.
git clone https://github.com/usehyperodds/hyperodds-mcp.git
cd hyperodds-mcp
npm ci
npm testnpm run lint and npm run typecheck run the other checks CI runs. See
CONTRIBUTING.md before
opening a pull request.
Report vulnerabilities privately to security@usehyperodds.com, or through the repository's Security tab. Please do not open a public issue for them. SECURITY.md has the details.
MIT. Third-party names identify data sources and compatible clients; Hyperodds is not affiliated with any of them.
Gives one question listed by several HIP-4 deployers: each member's rule grade against the anchor (SAME, CLOSE or DIFFERENT) with the differences found, its top of book, and the merged book across SAME members. Look it up by cluster id or by any member's outcome id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Cluster id, as odds_markets gives it | |
| outcome | No | Any member's outcome id |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | Yes | |
| title | Yes | |
| anchor | Yes | Outcome whose side orientation the merged book uses |
| merged | Yes | Top five levels a side across SAME members, priced as the anchor's side 0 |
| members | Yes | |
| mergedWithClose | Yes | Like merged, with CLOSE members added |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is covered. The description adds domain behavior that matters: what grades exist (SAME, CLOSE, DIFFERENT), that differences are reported per member, and that books are merged only across SAME members — context an agent could not infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core payload description is front-loaded before the lookup mechanism. The first sentence is dense and reads as a run-on list, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema, complete annotations, and 100% parameter coverage, the remaining burden is domain vocabulary, which the description supplies (anchor, rule grade, merged book). Minor gap: it doesn't say what happens if a member has no book or how partial/illiquid books appear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented and the baseline is 3. The description's 'by cluster id or by any member's outcome id' mildly reinforces that the two are alternative lookup paths, but it does not state mutual exclusivity, precedence, or behavior when both are supplied.
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?
It states a concrete verb and resource ('gives one question listed by several HIP-4 deployers') and enumerates the returned payload (rule grade, top of book, merged book), which is far more than a restatement of the name. It references odds_markets as the source of cluster ids but never explicitly contrasts itself with the sibling odds_markets/odds_fair/odds_new tools.
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?
'Look it up by cluster id or by any member's outcome id' tells the agent the two acceptable lookup keys, which is useful routing. However, it gives no when-to-use guidance versus the sibling odds_markets, odds_fair, or odds_new tools, and no exclusions or prerequisites beyond the implicit 'get the cluster id from odds_markets first'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gives one market's fair line (probability and band, method, confidence, and each source with its weight and age) with the top of book and the edge after all fees for each way to trade. Check confidence and singleSource before acting on the line.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | Outcome id |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| book | Yes | |
| edge | Yes | Edge in points after all fees for each way to trade, at refUsd |
| fair | Yes | |
| sides | Yes | |
| title | Yes | |
| status | Yes | |
| outcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower; the description still adds real context by disclosing that output is a synthesized line with per-source weights and freshness plus fee-adjusted edges, and by warning that confidence and singleSource must be checked before acting. It does not cover rate limits or failure modes, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, purpose first, caution second — well front-loaded with no wasted preamble. The first sentence is dense with a long parenthetical enumeration, but every listed element is meaningful output information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read with an output schema and full annotations, the description covers what the tool produces, the derived nature of the data, and the caveat about confidence/singleSource. What remains missing is when to pick it over its siblings, which is the one gap an agent could trip on.
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?
Only one parameter, and the schema documents it at 100% coverage ('Outcome id'). The description calls it 'one market's fair line', which introduces a mild market-vs-outcome ambiguity rather than clarifying the parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Gives one market's fair line') and enumerates what the result contains: probability and band, method, confidence, sources with weights and ages, top of book, and fee-adjusted edge. The 'one market' scope implicitly separates it from the multi-market siblings (odds_markets, odds_cluster), but no sibling is named explicitly.
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 second sentence gives useful downstream guidance ('Check confidence and singleSource before acting on the line'), which tells the agent how to consume the result. It does not say when to choose this tool over odds_markets, odds_cluster, or odds_new, nor any preconditions, so selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists HIP-4 outcome markets from every deployer with live top of book, fair line and edge after all fees. Filter by category, deployer or text, sort by edge, volume, new or settling, and page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Text to look for in the title, label, subcategory or deployer | |
| sort | No | volume (default): most traded first. edge: lines with confidence of at least 0.5 and more than one source first, then the largest edge. new: newest listings first. settling: soonest to settle first | |
| limit | No | Default 20, at most 100 | |
| offset | No | Markets to skip, for the next page. Default 0 | |
| category | No | ||
| deployer | No | Deployer code, such as hl (validator-run), out, txyz or skew |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | Yes | Markets that match, before limit and offset |
| markets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond those annotations: it covers every deployer, returns live pricing with fair line and edge after fees, and supports filtering and paging. It does not address authentication or rate limits, but it clears the annotation-adjusted bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no waste. The core listing purpose is front-loaded, followed by the filter/sort/page capabilities in a single efficient clause.
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?
With an output schema present and rich annotations, the description does not need to explain return values. It covers scope, filtering, sorting, and paging adequately for a six-parameter optional-filter list tool. The main gap is the absence of sibling routing guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the schema already documents most parameters well. The description restates the same filters and sort options without adding syntax or interpretation details beyond the schema, which is the baseline 3 case.
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 names a specific verb and resource — listing HIP-4 outcome markets across every deployer — and adds scope details like live top of book and edge after fees. It does not, however, distinguish this tool from the sibling odds_fair, odds_new, or odds_cluster tools, even though sorting by 'new' overlaps with odds_new.
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?
Usage is implied through capability listing (filter, sort, page), but there is no explicit statement of when to choose this tool over odds_fair or odds_new. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists HIP-4 markets newest first, with the same fields as odds_markets. Outcome ids grow with each listing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20, at most 100 | |
| offset | No | Markets to skip, for the next page. Default 0 | |
| category | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | Yes | Markets that match, before limit and offset |
| markets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond the schema: outcome ids grow monotonically with each listing, which helps an agent reason about recency. It does not discuss pagination behavior, but the schema covers limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the ordering constraint front-loaded. The reference to odds_markets requires sibling knowledge but is efficient; nothing is wasted.
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?
With an output schema and rich annotations, the description only needs to cover ordering, field parity, and any non-obvious behavior. It does that, though it leaves the category filter's role unexplained and does not state pagination semantics in prose.
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 67%, with limit and offset documented in the schema and category exposed as an enum without prose. The description adds no parameter-level guidance, so the baseline 3 applies for partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Lists HIP-4 markets') plus an ordering ('newest first'), which distinguishes it from the sibling odds_markets. It stops short of fully defining what HIP-4 markets are, but the core purpose is unambiguous.
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 newest-first ordering implies this is the tool for discovering recent listings versus odds_markets, but it never explicitly says when to choose this over the siblings or what conditions exclude it. Usage is inferable rather than stated.
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.
v0.1.0odds_clusterodds_fairodds_marketsodds_newScored across 4 tools
odds_markets vs odds_new overlap heavily: odds_new is essentially odds_markets pre-sorted newest-first with the same fields, and odds_markets already offers a 'new' sort. odds_cluster and odds_fair are clearly distinct (aggregation view vs single-market pricing), but the listing pair creates a real misselection risk.
All four tools share the same odds_ prefix, giving a predictable namespace. The suffixes vary in kind (plural noun, singular noun, adjective), but the pattern remains readable and consistent enough to infer purpose.
Four tools is on the lean side but appropriate for a focused odds/pricing analytics service. Each tool covers a distinct query shape, though odds_new is largely redundant with odds_markets and could be folded into it.
The surface covers the core domain well: market discovery (with filters, sorting, paging), cross-deployer clustering, and single-market fair line with edge. Minor gaps exist, such as no deployer/category enumeration or historical line tracking, but agents can work around these via filters and text search.
Hyperliquid MCP — read-only market data from Hyperliquid's public info API.
Historical tick, order book and settlement data for Polymarket and Predict.fun crypto up/down markets, plus smart-money lists and backtest quotes, over a read-only MCP server.
Read-only Hyperliquid analytics: orderflow, liquidation levels, whale positioning, funding.
Polymarket orderbook history, live books, trades and settlements, plus Hyperliquid perp books.
