What a question costs on the odds MCP server

An assistant connected to the odds MCP server answers in plain language, which makes it easy to forget that every answer is made of API requests. A session has a budget, and spending it well is a habit, not a setting. Here is what a question actually costs, and the session shape that keeps a free key alive all day.

The meter behind the conversation

The server exposes eight tools, and the MCP quickstart lists the price of each, checked 2026-10-28: six tools cost one request against your plan, exactly like a REST call, and two are free. The free pair are list_sports, which returns the sport IDs and names, and the documentation search tool that answers how-do-I questions from the reference.

Every metered call shows up in your account panel like any other request, so an afternoon of questions is a polling loop in conversation form. The free key's 20 requests a minute and 100 a day apply, unchanged.

The cheap session shape

Order is the whole trick. Open with the free tools. Ask the documentation search how a thing works before you fetch it, and pull list_sports once to pin down the sport IDs instead of guessing. Both cost nothing.

Then spend metered calls on the narrowing path: get_events once per sport you care about, get_event_odds only for the matches you will actually act on, and get_odds_drops when you want recent moves. get_feed_status and get_account_usage are the two gauges: the first tells you the feed is fresh, the second tells you where you stand against the day's budget. Checking the gauge is itself one request, so read it when it answers a decision, not on a loop.

What a real question costs

A worked example. "What is live in tennis tonight, and has anything moved?" is about five requests: one get_events for the board, two or three get_event_odds for the matches that matter, one get_odds_drops for the moves, with the two free tools carrying the setup. At that rate, the free key's daily 100 covers a genuine research session, questions and all, with room for a second one in the evening.

The pattern that burns the budget is browsing by conversation: asking for every board, then every event on each board, then odds for events you never wanted. The assistant happily walks the whole tree. You are the pruning.

When the meter pushes back

Two protections are built in, per the same documentation. The responses are trimmed so they do not flood the assistant's context, and when the server answers rate_limited it also stops calling upstream until the window resets, so a runaway loop cannot burn the day. The day still ends at its limit, but it ends gently.

When 100 requests a day stop being enough, the pricing page shows what each plan lifts, checked 2026-10-28. Until then, the free tools first and the gauge in view is the whole discipline.

Ask in sentences, spend in requests. The budget is small and, spent in the right order, entirely sufficient.