DunkAPI

Line movement

get_line_movement

Read-onlyIdempotent

Use to see how a game's line moved before tip-off: our pre-game snapshots of each sportsbook's moneyline, spread and total (captured once a day, and every hour for games in the next four days). Costs 10 credits. Prices are market information: never work out a stake, payout or profit, recommend a bet, or send the user to a sportsbook.

Input Schema

Name	Required	Description
`league`	No	League. Defaults to nba. One of: nba, wnba, ncaam, ncaaw.
`game_id`	Yes	Game id.
`provider`	No	One sportsbook, e.g. DraftKings.
`all_snapshots`	No	Every hourly capture. By default a capture identical to the one before it is left out (the latest is always kept), which keeps every move and its time.

Output Schema

Name	Required	Description	Default
`game`	Yes
`note`	No
`movement`	Yes
`snapshots`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / all_snapshots

Added value: +{
+  "description": "Every hourly capture. By default a capture identical to the one before it is left out (the latest is always kept), which keeps every move and its time.",
+  "type": "boolean"
+}

First observedOct 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safe-read profile, and the description layers on non-obvious behavior: a 10-credit cost, snapshot cadence (daily, plus hourly for games within four days), and a compliance boundary on how prices may be used. Cost disclosure and capture cadence are things an agent cannot learn from annotations or schema.

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

Conciseness5/5

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

Two sentences, purpose front-loaded, and every clause in the long second sentence carries distinct information: capture cadence, credit cost, and the market-information constraint. Nothing is restated from the title or schema.

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?

With an output schema present, return values need no explanation, and the description still covers the things schema cannot: pre-game-only scope, credit cost, snapshot frequency, and the prohibition on stake or bet advice. An agent has everything needed to call it correctly and interpret the result within its constraints.

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 the baseline is 3, but the description adds meaning to the snapshot concept behind all_snapshots by explaining what a snapshot is and how often one exists. It does not add anything about game_id, league defaults, or the single-book provider filter beyond what the schema already says.

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

Purpose4/5

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

States a specific verb and resource — pre-game snapshots of each sportsbook's moneyline, spread and total — so the agent knows this returns historical line movement rather than current prices. It is distinguishable in substance from get_odds, but it never names that sibling, so the differentiation is inferred from the word 'moved' rather than stated.

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

Usage Guidelines4/5

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

The opening 'Use to see how a game's line moved before tip-off' gives a clear triggering condition, and the final sentence sets hard exclusions on what the agent must not do with the returned prices. What is missing is an explicit alternative for current lines (get_odds) or a statement of when this tool is the wrong choice.

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

All DunkAPI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.