draftkings_event

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

No annotations are provided, so the description must carry behavioral disclosure on its own. It does this well by noting it comes from DraftKings' credential-free public JSON, implying an unauthenticated read operation with no credentials required. It also tells agents what to expect in the response (metadata only, no odds). It stops short of mentioning rate limits, errors, or other runtime caveats, but for a simple read call the disclosed traits are sufficient.

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

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

The description is four sentences, each earning its place: the standalone story, the return payload, the parameter sourcing, and the odds exclusion. There is no wasted text, and the structure front-loads the core purpose before reaching the caveat.

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

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

For a single-parameter tool with no output schema, this description covers virtually everything an agent could need: parameter provenance, the expected return payload, the credential profile, and a clear endpoint boundary. It even enables chaining by noting which downstream endpoint accepts the league_id. No critical gap remains.

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

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

The input schema confirms 100% parameter coverage (event_id as a 'Numeric DraftKings event id'). The description adds meaning beyond that label: it tells the agent how to find the event_id, that it can come from an event's odds response, and how the returned league_id can be reused with other endpoints. This is clear added value rather than a repeat of the schema.

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

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

The description opens with 'Returns one event's metadata' and explicitly lists the fields (league id, sport id, teams, status, start time), so the verb, resource, and scope are crystal clear. It also sets boundaries against odds-focused siblings by explicitly stating this endpoint does not include betting markets/odds, making it easy to differentiate from draftkings_odds, draftkings_event_markets, and similar tools.

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

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

The description provides strong context: it tells where to obtain event_id (from a DraftKings Sportsbook page or the odds response) and explains that the returned league_id can be used with /draftkings/sportsbook/odds and /draftkings/sportsbook/futures. The ending note ('does not include betting markets/odds') implies a when-not-to-use condition, but it does not explicitly say 'use another endpoint when you need odds' or name the exact alternative tool.

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