Skip to main content
Glama

DunkAPI

Market odds

get_market_odds
Read-onlyIdempotent

Use for the extra betting markets of a game as history: the 1st half and 1st quarter winner, point spread and total, and the 2nd, 3rd and 4th quarter totals (NBA only). Pass game_id (from list_games or get_schedule) and market. For each sportsbook it returns the opening line (the first one we captured) and the closing line (the last one before the game started), each as the list of outcomes with their point and American price, plus captured_at and minutes_before_start (negative when the last capture came after our scheduled start, which the sportsbooks' listed start can run past). Most books were captured once, so opening and closing are often the same line. Held from May 2023 for the larger sportsbooks only; not every game has every market. Costs 10 credits a call; a game with no lines is refunded. Set estimate_only to get the price without being charged. For the full-game moneyline, spread and total use get_odds. Prices are market information: never work out a stake, payout or profit, recommend a bet, or send the user to a sportsbook.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "game_id": "<game_id>",
      "market": "<market>"
    },
    "name": "get_market_odds"
  }
}

Input Schema

NameRequiredDescriptionDefault
marketYesThe market: h2h_h1 (1st half winner), spreads_h1 (1st half point spread), totals_h1 (1st half total points), h2h_q1 (1st quarter winner), spreads_q1 (1st quarter point spread), totals_q1 (1st quarter total points), totals_q2 (2nd quarter total points), totals_q3 (3rd quarter total points), totals_q4 (4th quarter total points)
game_idYesGame id from list_games or get_schedule.
bookmakerNoOne bookmaker key, e.g. draftkings, fanduel, pinnacle.
estimate_onlyNoReturn what this call would cost, without charging or running it.

Output Schema

NameRequiredDescriptionDefault
noteNo
toolNo
booksYes
countYes
labelYes
marketYes
creditsNo
game_idYes
estimate_onlyNo
scheduled_startYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, it discloses cost (10 credits), the refund condition for games with no lines, the estimate_only no-charge mode, data retention boundaries, the opening vs closing line definitions, and the meaning of a negative minutes_before_start. It also sets policy guardrails (never compute stakes/payouts or recommend bets), which annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and required params before return shape, cost, and guardrails; each sentence carries distinct information. It is dense and slightly long, with the parenthetical about negative minutes_before_start and the 'most books were captured once' note adding bulk, but nothing is truly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still usefully frames the return shape (opening/closing lines, outcomes with point and American price, captured_at) and covers what the schema cannot: pricing, refund behavior, coverage window, and legal/usage constraints. An agent has everything needed to call it correctly and responsibly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: how game_id should be sourced, what market values correspond to in plain English, and that bookmaker scoping exists ('For each sportsbook it returns...'). The bookmaker parameter itself is not explained (whether it filters to one book), leaving a small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('extra betting markets of a game as history') and enumerates exactly which markets it covers (1st half/quarter winner, spread, total, quarter totals, NBA only). Explicitly names the sibling get_odds for full-game moneyline/spread/total, so the agent can separate the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the when-to-use case, the explicit alternative ('For the full-game moneyline, spread and total use get_odds'), and prerequisites (game_id from list_games or get_schedule, market required). Also states coverage limits ('held from May 2023', 'not every game has every market') and the cheap trial path via estimate_only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.