Skip to main content
Glama
Sign In

DraftKings API

by com.draftkingsapi
OverviewDiscussionsAdmin

Sportsbook events

get_sportsbook_events
Read-onlyIdempotent

Stored events with event_status pre, in, post or unknown.

Input Schema

NameRequiredDescriptionDefault
limitNo
sportNo
cursorNoUse pagination.next_cursor unchanged. Every row is reachable and pages never skip or repeat a row under inserts. Cannot be combined with offset.
offsetNo
searchNoCase-insensitive team name match.
statusNoEvent state. Use pre to leave finished games out.
event_idNo
start_afterNoEvent starts at or after this time.
start_beforeNoEvent starts at or before this time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Use pagination.next_cursor unchanged. Every row is reachable and pages never skip or repeat a row under inserts. Cannot be combined with offset.",
+  "pattern": "^[A-Za-z0-9_-]{1,700}$",
+  "type": "string"
+}
    • addedInput schema / properties / search
      Added value: +{
+  "description": "Case-insensitive team name match.",
+  "maxLength": 100,
+  "minLength": 2,
+  "type": "string"
+}
    • addedInput schema / properties / start_after
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    },
+    {
+      "format": "date",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+      "type": "string"
+    }
+  ],
+  "description": "Event starts at or after this time."
+}
    • addedInput schema / properties / start_before
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    },
+    {
+      "format": "date",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+      "type": "string"
+    }
+  ],
+  "description": "Event starts at or before this time."
+}
    • addedInput schema / properties / status
      Added value: +{
+  "description": "Event state. Use pre to leave finished games out.",
+  "enum": [
+    "pre",
+    "in",
+    "post",
+    "unknown"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

C2.4/5.0
Behavior2/5

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

The annotations already establish a safe, idempotent, closed-world read, and the description is consistent with them. "Stored" adds a small amount of source context, but the description says nothing about result scope, ordering, pagination behavior, or whether all statuses are included by default.

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

Conciseness3/5

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

The single sentence is readable and contains no filler, with the resource mentioned immediately. However, its extreme brevity omits the operative verb and essential scope, making it under-specified rather than effectively concise.

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?

The detailed schema and read-only annotations make the tool partly usable, but the description is insufficient for a nine-parameter tool with several closely related siblings and no output schema. It leaves selection between sportsbook events, history, odds, and stats tools largely to inference.

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

Parameters2/5

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

With 56% schema coverage, the description should help fill the remaining gaps, but it only repeats the status enum already present in the schema. It adds no meaning for undocumented parameters such as sport, event_id, limit, or offset, nor does it explain filter combinations.

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

Purpose3/5

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

The description identifies stored events and their possible event_status values, but never explicitly says that the tool lists or retrieves them. It also does not distinguish these events from siblings such as get_sportsbook_history, get_sportsbook_odds, or get_stats_games.

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?

Listing the statuses provides only weak implied context for filtering; it gives no explicit when-to-use guidance. There are no exclusions, prerequisites, or pointers to alternatives for odds, history, or general game statistics.

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

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