Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_sportsbook_builder_quotes

Prices individual FanDuel bet-builder choices as single bets, returning live decimal, American, and fractional odds; unknown choices appear in failures instead of failing the request.

Instructions

FanDuel Sportsbook bet builder quotes. Prices bet-builder choices as single bets and returns, for each, the live decimal, American and fractional odds. A choice the pricing service does not know is returned in failures (for example CHOICE_NOT_FOUND) instead of failing the request. This is the price of each choice on its own: the combined price of several choices is a separate call that requires an account and is not available.

Input Schema

NameRequiredDescriptionDefault
stateNoMarket code, including `on` for Ontario; default `nj`
choice_idYesChoice ids from the builder response (`choices[].choice_id`); 1 to 25, repeated or comma-separated
ramp_event_idYesThe builder response's `ramp_event_id` (not its `event_id`)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses the return format (decimal/American/fractional per choice), partial-failure behavior (unknown choices go to `failures` e.g. CHOICE_NOT_FOUND rather than failing the request), and the single-vs-combined scope and account caveat. It leaves auth, rate limits, and explicit read-only status unstated, keeping it below a full 5.

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?

Purpose is front-loaded in the first sentence, followed by return format, error handling, and scope in a logical order. There is mild redundancy between "as single bets" and the closing sentence restating "the price of each choice on its own," but it stays efficient overall.

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

Completeness4/5

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

No output schema and no annotations, yet the description conveys return shape, failure handling, and scope boundaries, which is most of what an agent needs to call it correctly. It omits the full response envelope and whether any auth applies to this call, which keeps it from a 5.

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 100%, so every parameter is already documented at the schema level, including the note to use `ramp_event_id` rather than `event_id` and the 1-25 choice_id range. The description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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 verb and resource ("Prices bet-builder choices") and describes exactly what it returns per choice. It also draws a clean scope line against the combined-price call, so an agent can tell it apart from the parlay/combined-pricing tools without opening the schema.

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

Usage Guidelines4/5

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

Explicitly frames this as per-choice pricing and says the combined price is "a separate call that requires an account and is not available," which steers the agent away from misusing it. It stops short of an explicit "call fanduel_sportsbook_builder first to obtain ramp_event_id/choice_id" instruction, though the schema covers the sourcing.

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

Deploy Server

Other Tools