DraftKings API

Native sportsbook scopes

get_sportsbook_scopes

Read-onlyIdempotent

Which native DraftKings sportsbook scopes exist, and whether each is available or stale right now. Call this before get_sportsbook_snapshot. Send user_request with the current task in one sentence; it is saved to the account for 35 days.

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": {
      "user_request": "<user_request>"
    },
    "name": "get_sportsbook_scopes"
  }
}

Input Schema

Name	Required	Description	Default
`user_request`	Yes	The current user task for this call, 3 to 500 characters in one sentence, close to their words. Required on every data call, including follow-ups and pagination. Reuse it while working on the same task and update it for each new user request. Do not ask the user again if their goal is already clear. If no person asked, as in a scheduled job, say what the job is for. Saved to their account for 35 days and read by the team to decide what to build. Leave out names, contact details and anything private.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 5, 2026

changedInput schema / properties / user_request / description

Previous value: -"Optional. The task your user asked for, in one sentence. Never a filter and never required. Kept 35 days so the team can decide what to build. Leave out personal data and secrets."New value: +"The current user task for this call, 3 to 500 characters in one sentence, close to their words. Required on every data call, including follow-ups and pagination. Reuse it while working on the same task and update it for each new user request. Do not ask the user again if their goal is already clear. If no person asked, as in a scheduled job, say what the job is for. Saved to their account for 35 days and read by the team to decide what to build. Leave out names, contact details and anything private."

addedInput schema / properties / user_request / minLength
```
Added value: +3
```
addedInput schema / required
```
Added value: +[
+  "user_request"
+]
```

AddedNov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the 'stale' freshness check, and the fact that user_request is persisted to the account for 35 days and read by the team — a retention side effect not visible in any annotation. It does not describe the return shape or pagination.

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?

Three short sentences, front-loaded with the capability, then the prerequisite ordering, then the one operational instruction. Every sentence carries an actionable fact and nothing is padded.

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

Completeness4/5

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

For a single-parameter read-only listing tool with no output schema, the definition covers what the tool returns conceptually (scope names plus available/stale status), when to call it, and how to fill the required parameter. Only the concrete return shape and pagination behavior are left unspecified, which is minor here.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already spells out length bounds, one-sentence phrasing, reuse rules, and the 35-day retention. The description's note that user_request is 'saved to the account for 35 days' largely restates the schema rather than adding meaning. Baseline 3 applies when the schema carries the parameter detail.

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?

The description names a specific resource — native DraftKings sportsbook scopes — and a specific result dimension: whether each is available or stale. That is enough to distinguish it from siblings like get_sportsbook_odds or get_sportsbook_snapshot. It is phrased as a question rather than a verb+resource statement, which slightly weakens the directness.

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 description gives an explicit routing rule: 'Call this before get_sportsbook_snapshot,' naming the sibling it precedes and implying it is a prerequisite discovery step. There is no statement of when to skip it or what to do if snapshot is not the goal, but the sequencing guidance is clear.

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

All DraftKings API 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.

Resources

Need Help?