DraftKings API

Setup fields

get_setup_fields

Read-onlyIdempotent

The optional project questions and the main data endpoints. Setup is never required before a data call. 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_setup_fields"
  }
}

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

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds the 35-day retention of user_request and that the team reads it, which is genuinely useful context, but says nothing about what the call itself returns or its cost.

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?

Three short sentences, no filler, and the important disclaimer appears early. The vague opening sentence is the weak point but the piece is otherwise tight.

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

Completeness2/5

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

There is no output schema, so the description carries the burden of explaining what comes back, and it never does: neither the shape of the 'project questions' nor the 'main data endpoints' is described. For a discovery-type tool with a sibling complete_setup, this leaves an agent guessing about the response.

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 coverage is 100% and the schema text already explains the sentence format, the 35-day retention and the privacy caveat. The description largely restates that, adding only the 'current task' framing, so it earns baseline rather than extra credit.

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

Purpose2/5

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

The opening is a bare noun phrase, 'The optional project questions and the main data endpoints', with no verb and no statement that this tool returns or lists anything. Against siblings like complete_setup and get_api_directory, an agent cannot tell whether this retrieves setup field definitions, status, or something else.

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

Usage Guidelines3/5

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

'Setup is never required before a data call' gives a useful negative guideline that discourages unnecessary calls, but there is no positive guidance on when to call it or how it relates to complete_setup or start_signup.

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?