Live and prematch FanDuel odds, price drops and feed health. No key, no signup.
Scored across 6 tools
Each tool targets a distinct slice of the odds feed: health, live, prematch, fixture lookup, market summary, and price drops. The only mild overlap is get_live_fixtures vs get_prematch_fixtures, but the inplay flag and descriptions make the boundary clear.
All six tools follow a consistent get_<noun> pattern with clear, descriptive nouns: feed_health, fixture_by_name, live_fixtures, market_summary, prematch_fixtures, price_drops. No mixed conventions or vague verbs.
Six tools is well-scoped for a real-time odds feed server: health, coverage summary, live slice, prematch slice, fixture lookup, and price-move signal. Each tool earns its place and there is no bloat.
The surface covers the core read-only needs of an odds feed: health, coverage, live/prematch prices, fixture search, and price drops. Minor gaps exist—no direct odds-by-sport fetch and no historical archive—but the descriptions explicitly note those are out of scope.
Feed liveness and freshness: whether the odds collector answered, how long it took to build the document (X-Server-Ms), generated_at, sequence, seconds since the last tick and the current board size. Call it before describing any price as current, and after an outage. This tool does NOT fail when the collector is down — reachable:false with ok:false IS the answer, so a data tool's isError can be told apart from a real outage. generated_at is the newest tick the collector recorded, so a settled board (no live games moving) shows a growing age without being broken; judge health by generated_at advancing, never by the row count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavior not visible from annotations: the tool does NOT fail when the collector is down, reachable:false with ok:false is a valid answer, and generated_at advancing is the correct health signal rather than row count. This goes well beyond the readOnlyHint annotation and prevents serious misinterpretation.
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 dense but every clause earns its place. The key purpose and metrics are front-loaded, and the outage/false-failure nuance is delivered in a compact, structured way. No filler or repetition.
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?
Given no output schema, the description does the necessary work: it names the returned fields, explains the failure mode, gives interpretation guidance, and tells the agent when to call it. Nothing needed to use this tool correctly is missing.
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?
There are zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter syntax needs, but it compensates by explaining the meaning of the output fields, which is the relevant semantics for this parameterless tool.
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 identifies the tool as a feed health/freshness check and enumerates the specific metrics it exposes (ok, reachable, generated_at, sequence, seconds since last tick, board size). This is a distinct resource-level purpose that is easily separated from the sibling fixture/data 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 gives explicit call conditions: before describing any price as current and after an outage. It also clarifies how to distinguish a real outage from a data tool's isError state. It does not explicitly name an alternative tool for comparison, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tape rows by fixture name: a case-insensitive substring match over the fixture strings in the current window ("peliwo" finds "Filip Peliwo v Tai Leonard Sach"; "v " finds every head-to-head). Use it when the user names a match or a player rather than a sport, to check whether their fixture is on the tape and what its prices are. Every row of a matching fixture is returned — all its markets, live and prematch alike. This searches the ~20-row tape window only, so a fixture the collector is tracking can be absent from the window; an empty answer is not proof the game is missing from the board. Not a fixture-id lookup (the public snapshot carries no ids), not a schedule or results source, and not a bet-placement service.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Substring of the fixture name, case-insensitive. Required — an empty value would otherwise return the whole window, which is a wrong answer rather than an error. | |
| limit | No | Max matching rows returned. Default 20 (the whole window), max 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry readOnlyHint=true, so the description carries the behavioral burden and delivers richly: the case-insensitive substring behavior, the 'every row of a matching fixture is returned' behavior spanning live and prematch markets, the ~20-row window scope, and the critical caveat that an empty answer does not prove the fixture is off the board. No contradiction with the readOnly annotation.
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 front-loaded with purpose and examples, then usage, then scope caveat, then exclusions. It is dense but information-rich, and every sentence adds behavioral or routing value. Slightly long, but the length is justified by the tool's non-obvious window limitation and empty-result semantics.
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?
With no output schema present, the description compensates by explaining the return behavior (all markets, live and prematch) and the window limitation. It covers the main agent-facing risks (empty result meaning, not an ID lookup). It could specify the exact output field structure, but for a search tool the behavioral expectations are well covered.
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?
Schema coverage is 100%, so both parameters are already documented in the schema, giving a baseline of 3. The description adds marginal value through examples illustrating the name parameter's substring semantics, but it does not substantially extend what the schema already states for either parameter.
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 a specific verb and resource — 'Find tape rows by fixture name' — and immediately defines the exact matching semantics (case-insensitive substring) with two concrete examples. It then names what the tool is not (fixture-id lookup, schedule/results source, bet-placement service), distinguishing it from its siblings without needing their schemas.
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?
It gives explicit when-to-use guidance ('Use it when the user names a match or a player rather than a sport') and explicit negative exclusions. It stops short of naming the specific sibling that should handle sport-level queries (e.g., get_live_fixtures or get_prematch_fixtures), which would make the routing fully explicit, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
In-play (live) rows from the FanLine Wire tape: the markets that just ticked while a game is running, with their American prices. Use it for live odds displays, in-play modelling or feature engineering, cross-book middles and arbitrage checks on the live FanDuel prices, and any agent workflow that needs what is moving right now. Only rows with status "OPEN" carry a tradeable price — never present a SUSPENDED or CLOSED row as live, and never render an unpriced selection (american:null) as a number. The rows are the live slice of a rolling ~20-row tape window, not the full live board: read live_total for coverage. Not a bet-placement service, not a multi-book comparison (one book, no best-price or line-shopping output), and not a historical archive — prices are current only and nothing is stored here.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows returned. Default 20 (the whole window), max 20. | |
| sport | No | Sport name as the tape spells it (FanDuel's own names): "Tennis", "American Football", "Ice Hockey". Case-insensitive substring match, so "hockey" finds "Ice Hockey". Optional — omit for every sport in the window. The full vocabulary with counts is in get_market_summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important runtime semantics: only OPEN rows carry tradeable prices, SUSPENDED or CLOSED rows must never be presented as live, null American prices must not be rendered as numbers, and the result is a rolling ~20-row window rather than the full live board. This is exactly the kind of behavioral context annotations do not provide.
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 front-loaded with the core definition, followed by use cases and hard operational caveats. It is long but every clause earns its place by preventing misuse — the warnings about OPEN/null prices and the rolling window are high-value, not filler.
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?
Even though there is no output schema, the description covers return semantics well enough to use the tool correctly: row statuses, American price nullability, live window size, and live_total as a coverage indicator are all disclosed. It also clarifies persistence and scope, leaving no critical ambiguity.
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?
Schema description coverage is 100%, with both parameters fully documented: limit has bounds and default, and sport has case-insensitive substring behavior. The description adds window context around the limit but does not need to repeat the schema; this lands at the baseline for fully covered parameters.
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 a precise definition: in-play rows from the FanLine Wire tape, specifically markets that just ticked while a game is running, with American prices. It clearly separates this live, current-only tool from siblings like get_prematch_fixtures and excludes historical or multi-book comparison 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 explicitly lists intended use cases — live odds displays, in-play modelling, feature engineering, cross-book arbitrage checks — and explicitly states exclusions: not bet-placement, not multi-book comparison, not historical archive. It also directs the agent to read live_total for full coverage, which is concrete guidance beyond just saying what the tool is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the collector is tracking right now: live and prematch market totals plus the per-sport breakdown (FanDuel's own sport names). Use it before a board fetch to see whether anything is live, to resolve a sport= filter to a name that actually has markets, and to describe coverage honestly — the totals are market counts, not rows in the tape window. Cheap and free: it is one read of the same cached document. With sport given it also reports that sport's own live/prematch counts. Carries no prices: it answers "how much is covered", not "what are the odds", and it is not a schedule, an uptime record or an upsell meter.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Optional. Case-insensitive sport name to break out — "Tennis", "American Football". An unknown name answers with matched:false and the names that do have markets rather than an error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true. The description adds valuable behavior: it is one cheap cached read, totals are market counts not rows in the tape window, unknown sport names return matched:false with available names rather than an error, and with sport given it reports that sport's counts. 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?
Dense but well-organized: core purpose first, then usage, then caveats and exclusions. Every sentence adds information needed for correct selection and interpretation; no filler.
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?
With no output schema, the description explains what is returned: totals, per-sport breakdown, and optional sport-specific counts. It could have given a more explicit response shape, but it covers the key ambiguity risks such as counts vs rows and unknown sport handling.
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?
Schema coverage is 100% and already documents that sport is optional, case-insensitive, and handles unknown names with matched:false. The description reinforces the purpose of the sport parameter but adds little beyond 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 states a specific resource and scope: live and prematch market totals plus per-sport breakdown using FanDuel sport names. It also disambiguates from siblings by explicitly saying it is not a schedule, uptime record, or upsell meter, and carries no prices.
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?
Explicit when-to-use guidance is given: before a board fetch to check if anything is live, to resolve a sport= filter to a name with markets, and to describe coverage accurately. When-not-to-use is also clear via exclusions like 'not a schedule', 'not an uptime record', and 'not what are the odds'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-match (pre-game) rows from the FanLine Wire tape: the upcoming markets that just ticked, with their American prices. Same shape as get_live_fixtures, with inplay false. Use it for pre-game prices, model inputs and no-vig-style work on the FanDuel card. These rows are the prematch slice of the same rolling ~20-row tape window, not the whole card — prematch_total carries the real coverage number (it counts markets, not rows), so never describe the row count as the size of the card. Only status "OPEN" is tradeable. Not a bet-placement service, not a multi-book comparison, not an opening/closing-odds archive: snapshot the responses yourself if you want line history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows returned. Default 20 (the whole window), max 20. | |
| sport | No | Sport name as the tape spells it (FanDuel's own names): "Tennis", "American Football", "Ice Hockey". Case-insensitive substring match, so "hockey" finds "Ice Hockey". Optional — omit for every sport in the window. The full vocabulary with counts is in get_market_summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the `readOnlyHint` annotation, the description discloses that rows are only a rolling ~20-row slice, not the full card, that `prematch_total` counts markets not rows, that only `OPEN` status is tradeable, and that history must be snapshotted by the caller. This is substantial behavioral context that prevents realistic misuse.
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 dense but every sentence earns its place: purpose, cross-reference, use cases, windowing caveat, tradeability, and exclusions. It is front-loaded with the core definition and organized so critical limitations come before broad exclusions.
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?
With no output schema, the description compensates by pointing to `get_live_fixtures` for shape, and it covers usage, data-window limitations, status tradeability, and persistence expectations. There are no significant gaps for an agent to safely invoke this tool.
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?
Schema description coverage is 100%, so the schema already documents `limit` and `sport` fully. The description reinforces the rolling-window semantics for `limit` but does not add significant meaning beyond the schema; baseline 3 is appropriate.
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 names a specific resource (pre-match rows from the FanLine Wire tape), states what they contain (upcoming markets with American prices), and distinguishes the tool from its sibling `get_live_fixtures` by explicitly noting `inplay false`. An agent can tell exactly what this tool returns and how it differs from related 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?
It gives explicit intended use cases ('pre-game prices, model inputs and no-vig-style work on the FanDuel card') and clear exclusions ('not a bet-placement service, not a multi-book comparison, not an opening/closing-odds archive'). The reference to `get_live_fixtures` and `get_market_summary` also helps route the agent to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent price moves against the bettor: outcomes whose price just shortened on the FanLine Wire tape, newest first, with the American price before and after and the move in implied-probability terms. Use it for dropping-odds / steam-move signal, market-movement narratives and as a candidate list for value screening. The feed holds only the most recent few moves (up to 12) and states no cause — it never proves a move is informed money, and it is not a line-movement history, a multi-book comparison or a bet-placement service. Snapshot results yourself if you need history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max drops returned. Default 12 (everything the feed holds), max 12. | |
| min_pct | No | Only drops whose implied-probability move is at least this percent. Default 0, which returns everything the feed is holding. The feed itself only records moves of about 1% or more. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint being true, the description adds essential behavioral context: the feed holds at most 12 moves, doesn't state cause, and is not proof of informed money. It also advises snapshotting for history, which is beyond the annotation.
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 well-structured, front-loading the core purpose and then clarifying limitations. Every sentence adds value with no redundancy.
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 read-only feed with simple parameters, the description covers purpose, limitations, and usage guidance fully. The output is self-explanatory from the schema, so no further detail is needed.
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?
Schema coverage is 100% so both parameters are documented. The description clarifies that 'limit' defaults to 12 and 'min_pct' is a filter on implied-probability move, adding context about the feed's inherent ~1% threshold.
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 identifies the tool as listing recent price drops against the bettor, with specifics about the sort order and stats shown. It is clearly distinct from siblings, which cover feed health, fixtures, and market summaries.
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?
Explicitly states when to use it (dropping-odds signal, market-movement narratives, value screening) and what it is not (not a line-movement history, not multi-book, not bet-placement), which steers the agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_feed_healthget_fixture_by_nameget_live_fixturesget_market_summaryget_prematch_fixturesget_price_dropsLive odds, cross-book +EV and graded player-prop results across 27 books. Hosted endpoint included.
NFL/NBA/MLB/NHL/PGA + DFS and prediction-market data. Browse free; query with a free API key.
Real-time sports betting data: odds, player props, edges and arbitrage from 35+ books and DFS apps.
Sports odds, player props and source coverage for AI assistants. Connect with your own API key.
Add one secure layer between your agents and this server.
