https://api.routeur.app/mcp exposes two kinds of tool. Composed tools answer a whole question in one call and return compact rows built for a model to read. Endpoint tools are generated from the API description, one per REST operation: their arguments are that endpoint’s parameters and their result is its JSON body, unchanged. Adding an endpoint to the API adds a tool here.
Every tool is read-only and idempotent (readOnlyHint, idempotentHint): nothing on this server places an order, follows a market or writes anything. Each tool call counts against your API key exactly as the REST requests it makes, which is the Cost column below; a composed tool’s cost is the most it can make in one call.
Composed tools
find_opportunities
Everything Routeur can see that is tradeable right now, in one call: mispricing leads (two-leg purchases a proven relation says pay at least $1), the widest price gaps between proven-equivalent markets on Kalshi and Polymarket, and open markets that fit a strategy settled history pays for.
Liquid by default: only leads whose live order books could actually be filled at a profit after fees, and only gaps and strategy matches in markets with real 24-hour volume (min_volume_usd, $1,000 by default). Set executable_only: false to include leads priced from top-of-book asks alone, which are often too thin to fill.
Each row carries the venue and market ids, so follow up with explain_relation (why the two markets are linked), market_snapshot (one market in full) or compare_venues (the same question on both venues). Leads are observations of public prices, not quotes, and nothing here places an order.
Costs up to four API requests against your key. detail: "full" adds the untouched API objects; the default summary keeps ids you can pass to the other tools.
compare_venues
The same real-world question on both venues, outcome by outcome, with each venue’s Yes and No asks and the gap between them in cents.
Ask with question in plain language (“fed cut in December”, “Chiefs vs Bills”), or name an event exactly with venue and event_id. Events listed on both venues come back first; when only one venue lists the question, the answer says so rather than inventing a counterpart. Outcomes are matched across venues by proven equivalence, never by wording.
A gap is not money on its own: both books need size and fees have to leave something. find_opportunities does that arithmetic. Costs one or two API requests. detail: "full" adds the untouched API objects; the default summary keeps ids you can pass to the other tools.
explain_relation
Takes two markets and returns the proven relation between them, the structured evidence the proof rests on, and whether today’s prices respect it.
A relation is proven from both contracts’ structured terms and exact arithmetic, never from wording: implies means this market resolving Yes guarantees the other does, equivalent means they resolve the same way in every outcome, contradicts means both cannot resolve Yes. When no relation comes back, that means none was proven, not that the markets are unrelated: ambiguous or conflicting evidence is withheld rather than guessed.
The price check states the constraint a relation puts on the two asks and says whether it holds now. Costs two or three API requests. detail: "full" adds the untouched API objects; the default summary keeps ids you can pass to the other tools.
market_snapshot
Everything about one market in a single call: the latest Yes and No asks with the implied chance and the spread between them, a summary of how the price moved over the last days days, what has traded recently, the relations the graph proves to other markets, and the events closest to it by meaning.
Prices are asks per contract that pays $1, as exact decimal strings. The spread is what you give up crossing it: the Yes ask minus one minus the No ask. Recent volume is summed from the public trade feed, so it counts fills Routeur recorded, not the venue’s own lifetime figure.
Costs five API requests against your key. detail: "full" adds the untouched API objects; the default summary keeps ids you can pass to the other tools.
search_markets
Searches every listed market on Kalshi and Polymarket in plain language and never comes back empty: each result says how it was found, from match (every word matched, or the query names something the market is labeled with) down to trending.
The query itself narrows the search: “dem senate races closing this month under 30c” filters to markets closing within a month whose leading outcome costs under 30¢. Venue names, “on both venues”, “longshots”, “coin flips”, “favorites”, “movers” and “over $50k traded” are understood too, and what was understood comes back in filters. The arguments below set the same filters explicitly and win over the query; with filters on, an empty result means exactly that.
Results are events with their leading outcomes, each carrying the venue and market ids to pass to market_snapshot, compare_venues or explain_relation. Costs one API request. detail: "full" adds the untouched API objects; the default summary keeps ids you can pass to the other tools.
Endpoint tools
One per documentedGET operation that answers with JSON. The result is the endpoint’s body; see the API reference for the response schemas. GET /v1/stream is not a tool: a tool result is one JSON body, and a stream is not, so connect to it directly with your API key.
get_accuracy
How often proven relations held at settlement.
The public accuracy record, readable without a key. For every relation
type and proof family, on one venue or across both: how many proven
relations were checked against the settled outcomes of their markets,
how many were violated, the violation rate with its 95% Wilson
interval, and how a hand-labelled sample of live relations was judged.
release states the guard that decides which families may offer
executable leads, and which have passed it. methodology says in
plain words how every figure is made. Refreshed every half hour.
proposals is a separate ledger, about the model’s suggested matches
rather than about anything the graph proved: how many suggestions were
made under each set of question versions, how many the solver later
agreed with or contradicted, and how many the settled outcomes caught
out. It releases nothing and enters no figure above it.
Calls GET /v1/accuracy once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Takes no arguments.
get_book_history
Top-of-book history.
The top of the book over time: the best Yes bid and ask, mid,
microprice, spread, the USD within 5 cents of each side’s best bid,
and the imbalance, one point per step in which the top changed,
each the last state in its step, with how many changes the step saw.
The series is recorded per second of change and kept hot for 30 days;
at most 5,000 points per request, so a day at one-second resolution
needs several requests.
Calls GET /v1/markets/{venue}/{id}/book/history once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_books_health
Order book feed health.
The state of each venue’s order book feed as its collector last
reported it: whether it is connected and since when, message and
level-change rates, how many markets are recorded at full depth and
how many polled (and how long a polling cycle takes), and the counts
since the collector started of reconnects, sequence gaps, resyncs and
level changes dropped under overload, with feed latency percentiles
where the venue stamps its messages. status is up, degraded
(silent for two minutes, or an issue reported) or down (not
connected, or no report for two minutes).
Calls GET /v1/books/health once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Takes no arguments.
get_calibration
How prices resolved.
For settled markets, how often markets priced in each 10-cent band a number
of days before close resolved Yes. A well-calibrated market resolves Yes about
as often as its price; gaps show where prices ran rich or cheap. Kalshi prices
are the midpoint of the best bid and ask, or the last trade; Polymarket prices
are the last recorded probability of the day, from archived history.
Calls GET /v1/insights/calibration once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_closing
Closing soon.
Events closing within the next days with at least $500 traded today, grouped by day and most traded first.
Calls GET /v1/insights/closing once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_event
Get an event.
One event with every outcome priced on each venue that lists it.
Calls GET /v1/events/{venue}/{id} once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_flows
One-sided money.
Markets with at least $2,000 traded over the window, ranked by net money toward Yes or No. The week and month windows reach into archived history. The one- and six-hour windows are summed as you ask; windows of a day or longer are refreshed every five minutes.
Calls GET /v1/insights/flows once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_insights
Market insights.
What stands out right now, refreshed every few minutes: proven-equivalent
markets priced furthest apart across venues, the biggest 24-hour price
moves among markets with at least $1,000 traded, and the most traded
markets.
Calls GET /v1/insights once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_market
Get a market.
One market with its rules, latest asks and relation counts.
Calls GET /v1/markets/{venue}/{id} once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_market_book
Order book.
The market’s order book: both outcomes’ bids and asks to the depth
asked, best first, with the top of book, the USD resting within 1, 2
and 5 cents of each side’s best bid, the imbalance between the sides,
and the market’s liquidity grade.
Books are recorded from the venues’ own feeds. Markets graded
tradeable or deep, markets in a current lead, and markets of followed
events are recorded at full depth as every level changes (tier is
full); every other listed market is polled over REST, five levels
per side, once a cycle (tier is rest; /v1/books/health gives the
cycle time). A Yes ask is a No bid at the complementary price: the
two outcomes’ ladders are one book seen from each side.
Without at, the book is the latest recorded, rebuilt from the last
snapshot and every level change since (source is live; received_at is
when the last change was received, and feed says whether the venue
feed is connected). With at, the book as it stood at that moment
(source is rebuilt), from up to 90 days back while events are
still hot; older history is in the daily Parquet export.
Prices are per contract that pays $1; quantities are contracts on
Kalshi and outcome shares on Polymarket.
Calls GET /v1/markets/{venue}/{id}/book once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_market_rules
Get a market’s rules and their history.
The market’s current rule text, the rulebooks in force above it with
their settlement sources, source links and contract terms documents,
every recorded version of the contract (hash, when it was first and
last seen, which fields changed, a unified diff from the version
before, and which rulebooks changed with it), and the ledger of every
change to the market’s terms, including rulebook and document changes
under an unchanged contract. Use it to see exactly how a market is
decided, whether that changed since a position was taken, and what
the venue’s own terms document says. Works for any market ever
recorded, listed or not.
Calls GET /v1/markets/{venue}/{id}/rules once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_moves
What’s moving and why.
The biggest 24-hour price moves among markets with at least $1,000 traded, each with the unusual-trading signals of the last day, its trades and net money toward Yes, and how many markets the graph relates to it.
Calls GET /v1/insights/moves once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_openapi
This document.
The OpenAPI 3.1 description of the API, as JSON.
Calls GET /v1/openapi.json once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Takes no arguments.
get_relation_proof
Why two markets are related.
The proof trail behind a relation in the latest graph, stated from the
left market’s side: both contract versions with the structured terms the
proof read (event, variable, Yes interval, rules hash, settlement), the
ordered proof steps, the evidence recorded when the relation was found,
and the graph runs that found and last confirmed it.
Steps are rebuilt from the stored contract versions with the same code
that builds the graph. reproduced is false when that rebuild no longer
yields the stored relation, for example because the venue changed
metadata outside the rules hash; the steps then end with
not_reproduced and the recorded conclusion.
Step kinds: usable, same_event, same_variable, intervals,
mutually_exclusive, game_quantity, same_game, orient_margin,
econ_quantity, not_reproduced and conclusion. Intervals use
interval notation over exact decimals: (20.5, ∞) is “more than 20.5”.
Either market may be given first. 404 with relation_not_found means
both markets are listed but the latest graph does not relate their
current contract versions.
Calls GET /v1/relations/{left_venue}/{left_id}/{right_venue}/{right_id} once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_relation_verification
Did a relation hold when the markets settled.
Whether a proven relation held once both markets settled, and how a
reviewer judged it, stated from the left market’s side. Unlike the
proof trail this works after the markets have left the listing, since
settled markets are no longer in the latest graph: the newest stored
proof between the two markets is used.
verification is present once both markets have settled: consistent
when the relation held, violated when it did not, unverifiable when
a side settled scalar or void or the relation makes no claim (overlaps).
label is present once a reviewer has judged the relation. bucket
carries the figures for the relation’s type and proof family, as on
/v1/accuracy, so one verdict can be weighed against its family’s
record.
Calls GET /v1/relations/{left_venue}/{left_id}/{right_venue}/{right_id}/verification once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_rulebook
Get a rulebook’s versions.
Every recorded version of one rulebook above the markets: a Kalshi
series (contract terms document, settlement sources, prohibitions,
product metadata), a Kalshi event (settlement sources, exclusivity,
strike period) or a Polymarket market’s resolution metadata. Each
version carries the venue’s fields verbatim, the settlement sources
read from them, the contract terms document in force with its
extracted text, which fields changed from the version before and a
diff. Use it to read the terms a whole series settles by and to see
when they changed.
Calls GET /v1/rulebooks/{venue}/{kind}/{id} once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_status
Latest graph run and crawls.
The most recent finished graph run with its counts, and the latest crawl of each venue.
Calls GET /v1/status once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Takes no arguments.
get_strategy
A strategy and the markets that fit it now.
Listed markets on the strategy’s venue and category, with a Yes ask inside its band, closing near its horizon, and not yet under way; most traded first.
Calls GET /v1/insights/strategies/{id} once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_tape
Large fills.
The largest fills across venues, newest first, with the outcome each backs. Windows that reach back before the live trade feed include archived Polymarket fills, marked archived.
Calls GET /v1/insights/tape once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
get_ticker
The live tape.
A short mixed list for a scrolling tape, taking turns between tradeable moves, large fills in the last hour, gaps between venues on proven-equivalent markets, and open markets fitting the strongest strategy.
Calls GET /v1/insights/ticker once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Takes no arguments.
get_topic
Markets about a person, team, place or subject.
Every listed event labeled with this name, most traded first, and the names that most often appear beside it.
Calls GET /v1/topics/{slug} once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_categories
Categories.
The shared categories both venues’ events are sorted into, with how many listed events each has.
Calls GET /v1/categories once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Takes no arguments.
list_cross_venue_pairs
Cross-venue pairs.
Relations between a Kalshi and a Polymarket market, stated from the left
market’s side: subset means the left market resolving Yes guarantees the
right does.
Calls GET /v1/cross-venue once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_events
Browse events.
Events across both venues, one card per real-world event: when Kalshi and
Polymarket list the same event, it appears once with both venues’ prices.
Each event carries its three leading outcomes.
Calls GET /v1/events once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_flow_signals
Unusual flow.
Markets whose last 15 minutes of trading were unusual against their own
previous week, scored every five minutes. Repeated detections of the same
market and kind within an hour extend one signal. Signals describe
trading, not its cause.
Calls GET /v1/flow once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_markets
Search markets.
Markets in the latest graph, ordered by title. Text search matches titles
by similarity, so small misspellings still match.
Calls GET /v1/markets once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_opportunities
Mispricing leads.
Two-leg purchases that pay at least $1 in every outcome a proven relation
allows, priced from recorded top-of-book asks with estimated fees. The best
leads each run are sized against live order books (depth); only leads
with depth.executable could be filled at a profit when the books were
read. Leads are observations, not quotes.
Calls GET /v1/opportunities once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_quotes
Quote history.
Top-of-book asks recorded each time they changed, oldest first. The first
point is the last change before the requested range, so a chart can start
at the range’s left edge. At most 5,000 points.
Calls GET /v1/markets/{venue}/{id}/quotes once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_related_events
List events related by meaning.
Open events that mean something close to this one, for “more like
this”. Nearness is the cosine similarity of the embeddings free-text
search uses, which are built from each event’s title, outcomes and
labels. Unlike relations, nothing here is proven: two related events
can resolve independently.
What comes back is filtered to be worth a look:
- Only listed events that can still be traded: closed events, games already under way, and one-winner events whose leading outcome costs 97¢ or more are left out, as are the event itself, its twin, and the same question listed on the other venue without a proven twin.
- A neighbour is kept when its meaning is very close, or when it is reasonably close and shares a labeled name or subject with the event.
- Instances of one recurring question collapse to the best of them: every day of a price range, or every game of the same team, shows once. At most one other instance of this event’s own series is kept, ranked below new questions.
- Order is by similarity, nudged toward what traded today.
reason. An event not yet labeled has no
related events. Results are cached for two minutes.
Calls GET /v1/events/{venue}/{id}/related once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_related_to_market
List events related to a market by meaning.
The events related by meaning to the event this market belongs to;
see GET /v1/events/{venue}/{id}/related for how they are chosen.
Calls GET /v1/markets/{venue}/{id}/related once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_relations
List a market’s relations.
Every proven relation from this market’s point of view: implies means
this market resolving Yes guarantees the other resolves Yes. Cross-venue
relations come first.
data holds proofs and only proofs. Where a market is one the graph’s
templates cannot reach — politics, culture, a one-off question — a
separate proposals field carries cross-venue matches a model
suggested, each with the probability it answered and the version of
every question it was asked. A proposal is informational: it is not a
proof, it is not evidence, and no lead, accuracy figure or other
endpoint is built on one. Proposals are sent only on the first page of
an unnarrowed list, and only while they are still open: once the solver
agrees with or refutes one, or a moderator dismisses it, it is gone.
Calls GET /v1/markets/{venue}/{id}/relations once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_strategies
Strategies history supports.
Rules to buy one side of markets priced in a 10-cent band some days before
they close, drawn from settled history, with what $100 spread across every
such market came back as and a 95% range on it. Only rules with at least
100 settled markets, a return of 3% or more before fees, and an edge in
the same direction on at least one horizon are listed, best cautious
return first. Bands below 10 cents and above 90 cents are left out:
history prices them at the midpoint, and that far out the ask is too far
from it for the return to be reachable. Each carries how many listed
markets fit it now.
Calls GET /v1/insights/strategies once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_topics
Names markets are labeled with.
The names most listed events are about, for browsing: people, teams, places and subjects, with how many events carry each.
Calls GET /v1/topics once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
list_trades
Trades.
Public fills recorded from the venue’s trade feed, newest first. Recording
runs every minute; Polymarket fills that the feed served without a market
are not included. No account or wallet identity is recorded.
Calls GET /v1/markets/{venue}/{id}/trades once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
purchase_comparison
Compare a chosen purchase against a cross-venue contract.
Account-independent whole-share estimates using current depth, live Kalshi event/series fee overrides, and captured Polymarket fee schedules. Missing, stale, disconnected or limited recorded books trigger bounded public venue reads (four seconds per contract, up to 500 levels). A failed refresh remains unavailable; no stale quote is promoted. Automated settlement assessments bind full source versions. USD/USDC estimates assume parity and funded balances with exclusions in pricing. Missing evidence, unsupported assets, unknown fees and stale or incomplete books prevent a savings recommendation. No order or account is created. Responses are never cached.
Calls GET /v1/markets/{venue}/{id}/comparison once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
search_events
Search events.
Finds events for free text and never comes back empty. Results come in
order of how they were found, each labeled with match:
match: every word matched in a title, outcome or category, allowing common shorthand (dems, gop, btc, fed) and the last word as a prefix so results follow typing; or the query names a person, team, place or subject a market is labeled with, however its title is worded.similar: some of the words matched, a title is close in spelling, or the market means close to the same thing.related: trending in the category the query is about, named inrelated_category.trending: trending anywhere, most traded first.
corrected_query. An empty q lists what is trending. Pages go up
to 300 results; pass next_offset as offset for the next page.
Plain language in the query narrows the search: “dem senate races
closing this month under 30c” filters to markets closing within a
month whose leading outcome costs under 30¢, and searches for “dem
senate races”. Also understood: a venue name, “on both venues”,
“longshots”, “coin flips”, “favorites”, “movers”, “closing
today/this week/this month”, “over $50k traded”. What was understood
comes back in filters, and query is what was searched for. The
same filters can be set as parameters, which win over the query. With
filters on, results can be empty: they are what you asked for.
Calls GET /v1/search once; the result is that endpoint’s JSON body, and the call counts as one request against your API key.
Related
- Reading order for LLMs: what a model should read, and hold, before quoting a number.
- Any MCP client: the protocol by hand, the headers, and
mcp-remotefor stdio-only clients.
Generated by
cmd/mcpdocs from routeur-platform commit c38e5ce on 2026-09-23. The tool set is read from the same OpenAPI description the server builds its tools from.