fanduel_sb_call

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context beyond annotations: it discloses that the tool carries the static public _ak web key and Origin/region headers, so the caller does not need to provide auth. It also mentions 'Auth: none needed' and points to the operations catalogue, which clarifies behavior. No contradiction with annotations.

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 tight and front-loaded with the core purpose, then the auth/headers context, then the catalogue pointer, and finally the return type and auth requirement. No filler or repetition; every sentence serves a purpose.

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 generic operation-based tool with rich schema descriptions and helpful annotations, the description covers the essential behavior: what it does, where to find operations, how auth is handled, and expected return type. It lacks specifics about error handling or pagination, but given the tool's nature and the schema's guidance, it is reasonably complete.

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 already provides 100% coverage with detailed descriptions for operation, path_params, and query_params. The description adds value by listing concrete examples of query parameters (eventId, customPageId, dataEntries, eventIds), giving the agent a sense of what kind of parameters are expected beyond the generic schema. This exceeds the baseline for high schema coverage.

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 clearly states the tool fetches a FanDuel Sportsbook REST resource by operation name, specifying the US/NJ region and the static public _ak web key plus Origin/region headers. This distinguishes it from sibling tools like fanduel_sb_live_score by positioning it as a generic operation-based caller, and it points to the catalogue resource for valid operations.

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 tells the agent to read 'fanduel://sportsbook/operations' for the list of valid operations, which is an explicit prerequisite. It also explains that the caller only supplies variable query params, implying when to use this tool (after consulting the catalogue). It does not explicitly name alternatives or state when not to use it, but the context is sufficient.

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