An MCP server that gives an AI assistant read access to OddsRelay: matched boards, the prices for one event, and
the sport, event, bookmaker and coverage lists behind them. It is read-only, and every call that spends tokens is
priced first and refused above a per-call cap (max_tokens). The assistant is told to ask you before raising it.
It works with Claude Desktop, Claude Code, Cursor and any other client that starts MCP servers over stdio, and it is
built on the oddsrelay TypeScript client.
API docs: https://oddsrelay.io/docs
Sign up at app.oddsrelay.io/signup and copy your key from the dashboard. Free gives you 50,000 tokens for 14 days from sign-up, with no card, then no tokens until you choose a plan, on the same key. Plans and token prices. Paid plans are for your own use. A product that serves other people runs on Enterprise.
Related MCP server: polymarket-mcp
You need an OddsRelay API key (Get a key, above). The server reads the key from ODDSRELAY_KEY. The bundle sets it for you; the other routes set it in your MCP client's config and need
Node 18 or later.
Download oddsrelay-mcp.mcpb from the latest release
and double-click it to install it in Claude Desktop, which asks for one setting: your API key. The setting is marked
sensitive, so Claude Desktop masks it, and it passes the key to the server as ODDSRELAY_KEY. The bundle carries
everything the server needs and runs on the Node built into Claude Desktop, so you need no Node of your own.
claude mcp add --transport stdio oddsrelay --env ODDSRELAY_KEY=your_key_here -- npx -y oddsrelay-mcpSettings, Developer, Edit Config opens claude_desktop_config.json. Add the server, then restart Claude Desktop:
{
"mcpServers": {
"oddsrelay": {
"command": "npx",
"args": ["-y", "oddsrelay-mcp"],
"env": { "ODDSRELAY_KEY": "your_key_here" }
}
}
}Add the same mcpServers block to ~/.cursor/mcp.json (every project) or .cursor/mcp.json (one project).
The key sits in that config file as plain text, so keep the file out of anything you commit.
Ask your assistant:
Using OddsRelay, which bookmakers carry tennis on the standard board?
That calls coverage, which costs no tokens. Then:
Show the OddsRelay standard board for soccer at Ladbrokes and William Hill, first five events.
The assistant finds the bookmaker keys with bookmakers, then calls odds, which is priced before it runs.
Tool | What it reads | Tokens |
| Sport and competition keys, paged | none |
| The events of one sport, with their ids, paged | none |
| Bookmaker and exchange keys | none |
| Which bookmakers carry which sports on one product, and the product's market keys | none |
| A matched board ( | priced first, capped |
| One event's prices at each bookmaker and exchange carrying it, narrowed to the bookmakers and markets you name | priced first, capped |
| Your plan, token balance, reset time and key scope | none |
odds and event_odds take a max_tokens argument with a small default. Before each call the server asks the
API what the call would cost (a quote, which spends nothing). If it would cost more than max_tokens, the server
makes no call, spends nothing and tells the assistant the price, so the assistant can narrow the filters or ask you
before it tries again with a higher max_tokens.
odds always takes one sport and the bookmakers you name, so each call stays narrow. The cost is set by the filters
you send; cutting the reply to limit rows does not change it. Every reply from these two tools carries tokens:
what the call cost and what is left.
Both tools only read, but their MCP annotations mark them as calls with a cost rather than read-only, so a client
that asks before such calls will ask you each time. event_odds reads the raw board, so it needs a key that can read raw odds.
Replies are compact JSON. Long lists are cut to limit rows (each tool has its own default) and to a size an
assistant can read in one go, with a more note saying how many rows were left out and what to change to see them.
Paged tools return next_cursor, which the assistant passes back as cursor; a page cut short goes on from the
first row not shown.
Errors come back as tool errors with the API's error code and, where the API sends them, the values it accepts:
ask for an unknown bookmaker and the error lists the keys it accepts.
The server reads the key only from ODDSRELAY_KEY and sends it only to https://api.oddsrelay.io, in the
Authorization header. It never puts the key in a tool reply or an error: if an error ever echoed it, it would be
replaced with [hidden]. The server logs nothing.
No tool writes anything, reads or writes files, or calls any host but the OddsRelay API.
npm ci
npm testThe tests run the server against a stubbed fetch and make no network calls. npm run bundle builds
oddsrelay-mcp.mcpb from dist and the installed dependencies: manifest.json describes the bundle, and
.mcpbignore keeps sources, tests and development packages out of it. To try the built server by hand,
npx @modelcontextprotocol/inspector node dist/cli.js opens it in the MCP Inspector.
oddsrelay-python: the Python client, pip install oddsrelay
oddsrelay-js: the JavaScript and TypeScript client, npm install oddsrelay
oddsrelay-r: the R client
oddsrelay-sheets: formulas and a template spreadsheet for Google Sheets
examples: short programs to copy, one folder each
Libraries and tools, the docs, the API reference and the OpenAPI file
Contact: hello@oddsrelay.io
MIT
Lists the bookmaker and exchange keys that odds, event_odds and coverage take. Costs no tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond the annotations, namely that the call costs no tokens, which affects an agent's willingness to call it freely.
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 short sentences, both earning their place: the first defines the output, the second justifies calling it. The key information is front-loaded with no filler.
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 no parameters and no output schema, the description carries the burden of explaining the return value, and it does name the returned content (bookmaker and exchange keys) plus the cost. It stops short of describing the response shape (e.g. how bookmakers vs exchanges are separated), a minor gap for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter meaning is missing.
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 (Lists) and resource (bookmaker and exchange keys), and goes further by naming the siblings (odds, event_odds, coverage) whose inputs these keys are, so an agent immediately understands the tool's role in the workflow.
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 makes clear this is the lookup source for the keys consumed by odds, event_odds and coverage, which gives an agent a strong cue for when to call it first. It does not state explicit exclusions or say when not to call it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows which bookmakers carry which sports on one product, and that product's market keys (the values odds takes as markets). Filter by bookmaker or sport. Costs no tokens and sends no key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return; a note counts the rest | |
| sport | No | Only this sport, such as soccer | |
| region | No | Region code. Left out, the API uses uk. | |
| product | No | standard, 2up, dutching, each-way, extra-place, bog or raw | standard |
| bookmaker | No | Only this bookmaker or exchange key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely non-derivable behavior: the call consumes no tokens and requires no API key, which affects an agent's willingness to invoke it repeatedly. It stops short of describing the response shape or pagination beyond the schema's own limit note.
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 zero waste. The core purpose is front-loaded and the cost/key detail is packed into a short trailing clause rather than padding.
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 no output schema, the description does carry the return-value burden and largely meets it by explaining that results are bookmaker-by-sport coverage plus market keys. It is nearly complete, missing only an explicit note about row limits or truncation behavior, though the schema's limit description covers that partially.
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%, with per-parameter descriptions for limit, sport, region, product, and bookmaker, so the schema carries the load. The description restates bookmaker/sport filtering without adding format or syntax detail beyond what is already documented, making the baseline 3 correct.
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: shows which bookmakers carry which sports on a product, plus that product's market keys. It implicitly distinguishes itself from the odds and bookmakers siblings by naming market keys as 'the values odds takes as markets', but it never names an alternative tool outright.
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?
Gives filtering guidance ('Filter by bookmaker or sport') and a cost cue ('Costs no tokens and sends no key'), which implies it is cheap to call freely. However, it never says when to reach for this over sports, bookmakers, odds, or event_odds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads one event's prices (id from events or odds) at each bookmaker and exchange carrying it, narrowed to the bookmakers and markets you name. Needs a key that can read raw odds. Spends tokens: priced first, and refused when it would cost more than max_tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An event id such as or_evt_da71d5873e85 | |
| limit | No | Most bookmakers to return; a note counts the rest | |
| region | No | Region code. Left out, the API uses uk. | |
| markets | No | Only these market keys, such as h2h | |
| bookmakers | No | Only these bookmaker or exchange keys | |
| max_tokens | No | Refuse the call when its quoted price is above this many tokens. Ask the user before raising it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: a key with raw-odds read permission is required, the call is metered ('spends tokens'), the price is quoted before commitment, and it self-refuses above max_tokens — this also reconciles the surprising readOnlyHint=false by implying a metered, non-inert operation. It does not describe the shape or scale of what comes back.
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?
Three dense sentences, front-loaded with the core read action and the id provenance immediately after it. The parenthetical breaks the sentence flow slightly, but no sentence 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?
For a 6-parameter, no-output-schema tool whose annotations are partly misleading, the description covers auth, cost, refusal, and scoping — enough to call it correctly. It leaves the return structure unstated, which is the one gap an agent cannot recover from structured fields.
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 the baseline is 3, but the description adds meaning the schema lacks: the provenance of `id` (events or odds) and the pre-flight semantics of `max_tokens` as a refusal threshold. It confirms rather than merely restates the filtering role of bookmakers/markets.
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 — reads one event's prices across every bookmaker and exchange carrying it, then narrows to named bookmakers/markets. It is clearly differentiated from the siblings `events` and `odds` by tying the input id to those tools as its source.
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?
Gives the prerequisite for `id` (come from `events` or `odds`), the scoping axes (bookmakers, markets), and the cost gate (priced first, refused above max_tokens). It never states when to prefer this over the sibling `odds` tool, so it stops short of explicit alternatives/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the events of one sport with their ids, for event_odds. Costs no tokens. Paged: pass next_cursor back as cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most events to return; a note counts the rest | |
| sport | Yes | Which sport: tennis, or a competition key from the sports tool | |
| cursor | No | next_cursor from the previous reply, with the same other arguments | |
| region | No | Region code. Left out, the API uses uk. | |
| commence_to | No | Latest start time, ISO 8601 | |
| commence_from | No | Earliest start time, ISO 8601 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only readOnly/openWorld, so the description's additions carry real weight: zero token cost and explicit pagination behavior ('pass next_cursor back as cursor') are concrete traits an agent needs. It still says nothing about failure modes, rate limits, or whether results are empty vs. absent sports.
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?
Three compact sentences with no filler: what it returns, what it costs, and how to page. The highest-value facts (ids, free, paging) are front-loaded.
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 read-only listing tool with no output schema and full schema coverage, the description covers purpose, cost, and paging adequately. It leaves return-shape details (id format, note field behavior implied by the limit description) to the schema and response.
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 the baseline is 3; every parameter already has its own documented meaning, including cursor and sport. The description's cursor note essentially restates the schema's 'next_cursor from the previous reply' wording, adding no new syntax or constraints.
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 ('Lists the events of one sport with their ids') and immediately ties itself to the sibling it feeds ('for event_odds'), so an agent can separate it from sports and event_odds without opening schemas.
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?
'for event_odds' establishes the workflow context (fetch ids, then request odds) and 'Costs no tokens' signals it is cheap to call liberally. It never states when not to use it or what alternative exists, so it stops short of a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a matched board (bookmaker back prices with exchange lay prices) for one sport at the bookmakers you name. Spends tokens: priced first, and refused when it would cost more than max_tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Which matched board | |
| limit | No | Most events to return; a note counts the rest | |
| sport | Yes | Which sport: soccer, or a competition key from the sports tool such as soccer_epl | |
| region | No | Region code. Left out, the API uses uk. | |
| markets | No | Market keys such as h2h; left out, every market on the board | |
| exchanges | No | Exchange keys; left out, every exchange on the board | |
| bookmakers | Yes | Bookmaker keys from the bookmakers tool | |
| max_tokens | No | Refuse the call when its quoted price is above this many tokens. Ask the user before raising it. | |
| commence_to | No | Latest start time, ISO 8601 | |
| commence_from | No | Earliest start time, ISO 8601 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true and neither idempotent nor destructive, but give no reason for the non-read-only flag. The description supplies exactly that missing context: the call consumes tokens, is quoted before execution, and is refused when the quote exceeds max_tokens. That materially changes how an agent should budget the call. Auth, rate limits and pagination are still undisclosed.
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 padding. The core purpose comes first and the costly, refusing behavior — the operational fact most likely to surprise an agent — is front-loaded into the second sentence.
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 10-parameter tool with full schema coverage and no output schema, the description covers purpose, the return shape (back/lay board) and the cost gate, and the schema carries the rest. The absence of output schema means the agent still has no explicit picture of the response envelope, which keeps this short of 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?
Schema description coverage is 100%, so the heavy lifting is done by the schema, including max_tokens' refusal semantics and the commence_from/to window. The description only reinforces the bookmakers parameter ("at the bookmakers you name") and the token ceiling, adding little beyond what is already documented. 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?
The description names a specific verb and resource ("Reads a matched board") and defines the resource precisely as bookmaker back prices paired with exchange lay prices, scoped to one sport and named bookmakers. It does not, however, differentiate itself from the sibling event_odds, leaving the board-vs-single-event distinction implicit.
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 context is implied through the cost warning ("Spends tokens: priced first"), which tells the agent to be deliberate about calling it, but there is no explicit when/when-not guidance and no named alternative such as event_odds for narrower queries. The agent must infer routing from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists sport and competition keys (such as soccer or soccer_epl) for the sport filter of odds and events. Costs no tokens. Paged: pass next_cursor back as cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most sports to return; a note counts the rest | |
| cursor | No | next_cursor from the previous reply, with the same other arguments | |
| region | No | Region code. Left out, the API uses uk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds two genuinely non-structured traits: the call is free ('Costs no tokens') and the result is paged with next_cursor to be fed back as cursor. That is real operational context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, no filler, and the purpose statement is front-loaded before the cost and paging notes. Every clause carries information the agent needs.
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 no output schema, the description must signal return shape, and it does by naming the key format and the next_cursor paging field. The 'note counts the rest' behavior is left to the limit parameter description rather than the tool description, but nothing essential for a correct call is missing.
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% (limit, cursor, region all documented, including the uk default), so the baseline is 3. The description goes slightly beyond by explaining the paging contract — passing next_cursor back as cursor — which references a return field not present in any schema since there is no output 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?
The description names a specific verb and resource ('Lists sport and competition keys') and gives a concrete example format ('soccer or soccer_epl'), so the agent knows exactly what comes back. It also ties the output to a downstream use (the sport filter of odds and events), which distinguishes it from siblings like bookmakers and coverage, though it does not explicitly contrast itself with them.
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 clearly states context of use — obtaining keys for the sport filter of odds and events — and adds an incentive ('Costs no tokens') that tells the agent this is a cheap discovery call. It does not spell out when *not* to call it or name an explicit alternative, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows this key's plan, token balance, reset time and scope. Costs no tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the cost characteristic ('Costs no tokens') and the exact fields returned, which is valuable given there is no output schema.
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 short sentences, zero waste, with the core purpose front-loaded and the cost note appended second. Every clause earns its place.
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 no output schema and no parameters, the description carries the return-value burden and does so adequately by naming the four pieces of information returned. Only minor omissions, such as response shape or units for the balance, remain.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No syntax or input concerns exist.
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 ('Shows') and a precisely enumerated resource ('this key's plan, token balance, reset time and scope'). It is unmistakably distinct from the data-retrieval siblings (sports, events, odds), so an agent can route to it without inspecting the schema.
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 the natural use case (checking your quota/balance) and the note 'Costs no tokens' hints that it is safe to call freely, but there is no explicit when-to-use or when-not-to-use statement and no alternatives named.
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.0bookmakerscoverageevent_oddseventsoddssportsusageScored across 7 tools
Each tool targets a distinct aspect: discovery (sports, events, bookmakers, coverage), price retrieval (odds, event_odds), and account info (usage). Minor overlap exists between bookmakers (key list) and coverage (mapping + markets), and between odds (sport-level) and event_odds (event-level), but descriptions clarify the granularity.
All tools are lowercase resource nouns (sports, events, bookmakers, coverage, odds, usage) with one snake_case compound (event_odds). Style is consistent and readable, though it deviates from a strict verb_noun pattern. Plural/singular mix is minor.
7 tools are well-scoped for a read-only odds API: four discovery tools, two price retrieval tools, and one account tool. No redundant or missing tools at this count.
Covers the full read lifecycle: discovering sports, events, bookmakers, coverage/market keys, and fetching odds at sport and event level, plus usage. Minor gap: no dedicated tool to list market keys independently (bundled into coverage with bookmaker-sport mapping).
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
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 MCP server exposing a user ORANO library to their own AI agent.
Read-only MCP server for Robinhood Chain token discovery, research, and due diligence via GMGN.
