draftkingsapi-mcp

Pick6 against sportsbook

get_compare

Read-only

Compare Pick6 lines with DraftKings Sportsbook lines for the same player, stat, and game, showing the gap so you can spot line differences.

Instructions

Pick6 lines next to DraftKings Sportsbook lines for the same player, stat and game, with the gap. Needs DRAFTKINGS_API_KEY (free key, no card, at https://draftkingsapi.com/sign-up).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_compare"
  }
}

Input Schema

Name	Required	Description
`sort`	No
`stat`	No
`task`	No	Optional: the user's task in one plain sentence, nothing personal. Helps the API return what fits.
`limit`	No	Rows to return, at most 200.
`sport`	No	Sport code in upper case, for example NFL, NBA, NHL, MLB, NCAAF, NCAAB, SOCCER.
`player`	No
`min_gap`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 15, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description usefully adds the auth requirement and a signup path, which is real context beyond structured fields. It says nothing about rate limits, empty-result behavior, or freshness of the book lines, which matters for an open-world external API call.

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?

Two tight sentences with the core comparison front-loaded and the prerequisite second. The signup URL is slightly promotional but is genuinely actionable for a caller that lacks a key.

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

Completeness3/5

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

For a 7-parameter, open-world tool with no output schema and under-half schema coverage, the description is thin: no return-shape hint (row fields, ordering) and no coverage of the tuning parameters. Adequate to identify the tool, not adequate to call it optimally.

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 only 43%, so the description must compensate more than it does. It conceptually covers player, stat and game (which maps to sport/player/stat) and hints at the gap, but leaves sort, min_gap, limit and task entirely undocumented in either place.

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 comparison: Pick6 lines beside DraftKings Sportsbook lines for the same player, stat and game, plus the gap. The verb+resource+scope is concrete enough that an agent can distinguish it from get_compare_books and the raw odds tools without opening a schema.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not guidance, and the nearest sibling (get_compare_books) is never referenced, so an agent must guess which comparison tool to pick. The only conditional information given is the API key prerequisite, not selection criteria.

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