Skip to main content
Each workflow below is a sequence an agent can run on its own; the first, second and fifth are also served as prompts so a client can offer them as commands. Every call was run against the live server on 2026-09-17 during graph run 74, and the output shown is that call’s result trimmed to the fields that matter. Prices are asks in dollars per contract that pays $1.

1. Scan for liquid opportunities

Question: is there anything tradeable right now that could actually be filled? Step 1, observed:
Nothing executable existed at that moment; list_opportunities {"executable": true} confirmed it with "data": []. Step 2, observed:
What to report. “No lead could be filled at a profit at graph run 74 (12:10 UTC). The widest cross-venue inconsistency is the Brewers–Pirates total 8.5: Yes on Kalshi at 54¢ plus No on Polymarket at 45¢ costs 99¢ for a pair that pays $1, but the books filled zero pairs after fees (net_edge_usd 0).” Do not present the 1¢ as an edge: the top-of-book ask is not depth, and estimated_fee_usd takes the rest. depth.limited_by names what stopped the fill (price, depth, minimum, fees, unavailable or informational).

2. Brief me on an event

Question: what does the Detroit vs Buffalo total points market say, on both venues, and what moved it? Step 1 returned one result with "match": "match", "venues": ["kalshi", "polymarket"], event_id "810546" on Polymarket, and the two market ids for the O/U 54.5 outcome. Step 2, observed:
Step 3, observed:
What to report. The contract (from market.title and yes_label: “over 54.5 points scored”), the price on each venue with its observed_at (Kalshi 52¢, Polymarket 53¢, both read about 12:33 UTC), the implied chance (51.5%), that the 7-day range was 45–53¢ and the Yes rose 7¢, that the last 200 fills were $10.5k with the largest under $1k, and that the two venues’ markets are proven equivalent. Say that Polymarket’s “Lions vs. Bills” moneyline is a different question in the same event. Trap: a query that matches words rather than the game ("lions bills total points" returned a rugby event, “Lions vs Leinster”) still comes back with "match": "match"; check title and venues before trusting a result, and treat "match": "trending" as “not found”.

3. Explain a relation

Question: why are the Kalshi and Polymarket 54.5 totals linked, and do their prices respect it? Step 1, observed:
Step 2, observed (trimmed): "relation": "equivalent", "direction": "both_ways", "reproduced": true, left "interval": "(54.5, ∞)" and "variable": "NFL total, Detroit vs Buffalo, 2026-09-17 ET", "found_by": {"id": 1, ...}, "confirmed_by": {"id": 74, ...}. What to report. Both contracts resolve on the same game’s final score with the same threshold (strike floor 109/2, the interval (54.5, ∞) on each side), so they are equivalent and should cost the same; the recorded asks differ by 1¢, which is not money until find_opportunities shows a fillable pair. Quote the evidence, including its caveat that postponement and cancellation settle differently. When explain_relation returns "related": false, as it did for the same Kalshi market against Polymarket’s moneyline nfl-det-buf-2026-09-18, its explanation says the proof was not available or the evidence conflicted, and reports how many relations the market does have; say “not proven”, never “unrelated”.

4. Watch a market’s rules

Question: how is this market decided, and have its terms changed since I looked? Step 1, observed:
What to report. The market settles on the final score of the game “originally scheduled for Sep 17, 2026” with the league as settlement source; one contract version has been seen since 2026-09-14 and nothing has changed. Relations are proven against a specific rules_hash, so a change also means the relations were re-proven; get_relation_proof says whether a stored relation still reproduced. The stream is the right tool for a standing watch; it is not exposed over MCP, so an agent that must poll should do so hourly at most, since terms are re-read on each crawl. See the API reference for streamEvents and its rules topic.

5. Backtest a band strategy

Question: what did buying Yes at 10–20¢ in sports markets the day before close return, and what fits that now? Step 1, observed:
Step 2, the matching band, observed: {"from_usd": "0.10", "to_usd": "0.20", "markets": 6221, "avg_price_usd": "0.1494", "yes_rate": "0.2263"}. Check: 100 × (0.2263 / 0.1494 − 1) = 51.5, which matches return_per_100_usd to rounding. Step 3, observed:
What to report. Across 6,221 settled sports markets priced 10–20¢ one day before close, Yes resolved 22.6% of the time against an average price of 14.9¢, so $100 spread across all of them came back as $151 before fees, with a 95% range of $144 to $158; the same band and side showed an edge on all three horizons. One market fits now: Getafe to win at 15¢ on Polymarket, graded deep, 1¢ spread. Then the limits, plainly: history is not a forecast; the return uses the band’s average midpoint, not the 15¢ ask; fees are excluded; a rule chosen from the same history it is measured on is not an out-of-sample test; and a 95% range is not a floor. Do not recommend a trade or size a position.

Writing the agent’s instructions

Give the agent these rules; they prevent most wrong answers.

Handling limits

A tool call that runs into your key’s limit comes back with isError: true and a message naming rate_limited or daily_quota_exceeded with the seconds to wait; the protocol call succeeds, so the agent can read it and wait rather than retry at once. One composed call can cost several requests, and each tool’s description says how many. A free key allows 30 requests per minute and 2,000 per day; see Rate limits.