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; a tool that calls four endpoints costs four requests.
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. The result is the endpoint’s body; see the API reference for the response schemas.
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.
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_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_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.
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.
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.