Flash Props API: player-prop analysis, projections, evidence, and line movement over REST/MCP.
Scored across 12 tools
Each tool targets a distinct resource+action, and descriptions include explicit 'when not to use' cross-references (e.g. find_player_props vs get_player_context vs get_prop_evidence, scan_props vs get_game_props vs find_player_props). The overlapping concepts (finding games, browsing props) are cleanly separated by input type and scope. An agent can reliably pick the right tool.
Consistent verb_noun snake_case throughout: find_*, get_*, list_*, scan_*. The verb prefixes map to clear semantic roles (find=resolve, get=fetch one, list=browse, scan=bulk). No camelCase or style mixing.
12 tools is well-scoped for a sports-props API spanning discovery, retrieval, context, and analysis. Each tool earns its place with no obviously redundant or filler entries.
As a read-only props API, the surface covers discovery (list_sports, list_games), resolution (find_game, find_player_props), retrieval (get_game_props, scan_props), metadata (get_market_metadata), context (get_player_context), and analysis (get_leaders, get_prop_evidence, get_prop_history, scan_movers). No obvious lifecycle gaps for its stated read-only purpose.
Translate a matchup (home team + away team) into the eventId needed by get_game_props. Read-only. No side effects. Requires an API key; rate-limited per your tier. Use this when you know the teams playing but don't have the eventId. On success returns: { eventId }. Pass that id straight to get_game_props. On failure returns an error explaining that the game was not found on today's board. If multiple games match the team names (rare), returns the first match sorted by start time. Matching is case-insensitive substring containment against the full team name. When not to use: use list_games to browse a slate, or get_game_props directly if you already have the eventId.
| Name | Required | Description | Default |
|---|---|---|---|
| away | Yes | Away team name or city, matched the same way. | |
| home | Yes | Home team name or city, matched as a case-insensitive substring of the full team name. | |
| sport | No | Sport id. Omit to default to the current in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral traits beyond the annotations: it is read-only (consistent with readOnlyHint), requires an API key, is rate-limited, returns the first match if multiple games match, and uses case-insensitive substring matching. It also describes the success and failure return shapes. The only minor gap is not detailing the exact error format, but the description covers the key behaviors.
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 and front-loaded: it starts with the core purpose, then covers behavior, success/failure, edge cases, and alternatives. Every sentence adds useful information without redundancy. It is appropriately sized for the tool's complexity.
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 the tool's complexity, the description is complete. It covers the input semantics, output shape, error behavior, edge cases, and usage boundaries. The annotations provide safety hints (read-only, idempotent, non-destructive), and the description fills in the operational details an agent needs to call it correctly.
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 schema already covers 100% of parameters with descriptions. The description adds value by explaining the matching semantics (case-insensitive substring containment against the full team name) and clarifying that 'sport' is optional and defaults to the current in-season sport. This goes beyond the schema's basic descriptions.
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's function: translating a matchup (home + away team) into an eventId. It uses a specific verb ('Translate') and names the resource (eventId) and the sibling tool (get_game_props) that consumes the result, distinguishing it from other 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 states when to use this tool ('when you know the teams playing but don't have the eventId') and when not to use it ('use list_games to browse a slate, or get_game_props directly if you already have the eventId'). It also names the alternative tools, providing clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every active prop for one player across today's board for a sport; same rows as scan_props, filtered by name (exact normalized match preferred, case-insensitive contains match as a fallback; see matchType in the response) instead of stat. Read-only. No side effects. Requires an API key. When to use: you know the player but not which game or event they are in, and you want their posted lines. When not to use: get_prop_evidence explains ONE prop with its line, gap and form; get_player_context gives season baselines and recent form but no posted lines; scan_props is the whole board.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Player name or gamertag, e.g. "Judge" or "Shotzzy" | |
| sport | No | Sport id. Defaults to the in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the matching fallback behavior (exact normalized match preferred, case-insensitive contains fallback), the matchType field in the response, the requirement for an API key, and the read-only/no-side-effect guarantee. This adds meaningful behavioral context beyond what annotations already 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 densely packed and front-loaded with the core behavior and differentiation. A few phrases like 'Read-only. No side effects.' slightly repeat annotations, but every other sentence earns its place, especially the when-to-use/when-not-to-use section.
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 the simple 2-parameter schema, high schema coverage, and no output schema, the description provides enough context for an agent to decide when to invoke this tool and what to expect. It explains the filtering behavior, the matching semantics, and the relationship to scan_props, covering the key knowledge needed to call it correctly.
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 baseline is 3. The description adds extra value by explaining how the name parameter behaves (exact match preferred, contains fallback, matchType in response), which goes beyond the schema's simple 'Player name or gamertag' example. It does not add much about the optional sport parameter, but the schema already covers it.
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 verb and resource: 'Every active prop for one player across today's board for a sport.' It also explicitly differentiates itself from siblings by positioning it as the same rows as scan_props filtered by name instead of stat, so an agent can distinguish it without opening 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 provides explicit 'When to use' and 'When not to use' guidance, naming get_prop_evidence, get_player_context, and scan_props as alternatives with clear criteria for choosing between them. This is direct routing information with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all player props for one game identified by eventId. Read-only. No side effects. Requires an API key; rate-limited per your tier. Returns: { eventId, sport, homeTeam, awayTeam, startTime, props: Array<{ player, stat, line, overOdds, underOdds, bookCount, gameState?, flashProjection? }>, sources: string[], fetchedAt, delayed, snapshotId, snapshotConsistency }. flashProjection is present when that sport + market has a registered Flash model and a player baseline is available; it is { value, sampleN, method, marketKey, basis, seasonId, basisNote } and is never fabricated. basis prior_season means a prior-season baseline, never current form. overOdds and underOdds are American-format integers (e.g. -110, +115); null when odds are not available. The stats parameter filters to specific markets (e.g. "points,rebounds" for basketball, "strikeouts,hits_allowed" for MLB). Typical workflow: (1) call list_games to get eventIds, (2) call get_game_props with the eventId. Alternatively, call find_game with team names to resolve the eventId when you know the matchup. Event ids are prefixed ud- (Underdog Fantasy source) or sc- (soccer odds board). Returns an error when the event id is not found, the game has ended with no active props, or lines have not been posted yet. When to use: when you have an eventId and want all props for that specific game. When not to use: use scan_props instead when you want a cross-game market view. Use find_player_props when you know the player name but not which game they are in.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Sport id. Must match the sport the event belongs to. Omit to use the current in-season sport. | |
| stats | No | Comma-separated list of stat keys to return, e.g. "points,rebounds,assists" for basketball or "strikeouts,hits_allowed" for MLB. Omit to return all available markets. | |
| eventId | Yes | Event id from list_games or find_game. Prefixed ud- or sc-, e.g. "ud-119284". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent, and the description adds meaningful context: API key requirement, rate limiting, error conditions, odds format, and the caveat that flashProjection is never fabricated. This goes well beyond the structured annotations and clarifies important behavioral edges.
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 long but appropriately sized for a tool with no output schema and nuanced return semantics. It is front-loaded with the core operation, then organized into return shape, parameter behavior, workflow, errors, and sibling alternatives, with every sentence earning its place.
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?
Because there is no output schema, the description thoroughly documents the return object shape, optional fields, error cases, and parameter specifics. An agent can invoke this tool and interpret results correctly without needing additional external documentation.
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 the baseline is 3, but the description adds real value by explaining stats filtering with concrete examples, eventId prefix conventions, and the workflow for resolving event IDs. It does not substantially expand on the sport parameter, but the schema already documents that adequately.
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: "Fetch all player props for one game identified by eventId." It clearly distinguishes this tool from siblings such as scan_props and find_player_props by stating the exact scope of the operation.
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 an explicit typical workflow (list_games then get_game_props), an alternative path via find_game, and explicit when-to-use and when-not-to-use guidance naming scan_props and find_player_props. An agent has everything needed to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked boards for a sport with a registered Flash pack. Read-only. No side effects. Tier-shaped exactly like REST: Free sees the top 3 teaser, Builder the top 10, and Pro the full board. metric=gap ranks Flash-vs-book gaps; metric=form ranks recent mean vs Flash Line; metric=sample ranks baseline size. Paywall metadata includes totalAvailable and the next unlock when rows are capped. No picks. Use list_sports to discover which sports have deep context. When to use: "where does Flash disagree most with the books", "biggest projection gaps", "who has the strongest sample". When not to use: one player is get_player_context; the posted board is scan_props; one prop end to end is get_prop_evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | No | Restrict the gap board to one market. | |
| limit | No | Max rows before tier shaping (default 20). | |
| sport | No | Sport id with a registered Flash pack. Defaults to cod. | |
| metric | No | gap (default), form, or sample. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds important behavioral details: tier-based shaping (Free/Builder/Pro), paywall metadata with totalAvailable and next unlock, and the fact that rows are capped. It does not contradict 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 dense but every sentence carries weight: each metric is defined, tier behavior is specified, paywall metadata is mentioned, and sibling routing is included. Information is front-loaded with the core purpose, then details, then usage guidance.
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 tool with no output schema, the description is thorough. It covers tier behavior, metric semantics, paywall metadata, and when to use. Minor gaps: it doesn't specify the exact output format or the meaning of 'stat' parameter, but given the low complexity and no required parameters, this is sufficient.
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 each parameter has a description, but the description adds critical value: it explains what the 'metric' enum values mean (gap ranks Flash-vs-book gaps, etc.) and clarifies that 'limit' is before tier shaping, adding context 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 clearly states the tool returns ranked boards for a sport, with three specific metrics (gap, form, sample) each defined precisely. It distinguishes itself from siblings by explicitly naming get_player_context, scan_props, and get_prop_evidence as alternatives for different use cases.
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?
Provides explicit when-to-use examples ('where does Flash disagree most with the books', etc.) and explicit when-not-to-use cases with sibling tool names. Also instructs to use list_sports to discover eligible sports, giving clear guidance on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the machine-readable stat vocabulary for a sport: for each live market, its label, family, scope (map1/maps13/full_game), unit, display order, and whether a Flash projection is supported (with a reason when not). Read-only. No side effects. Rate-limited per your tier. Returns { sport, count, markets: Array<{ statKey, label, family, scopeKind, scope, scopeLabel, unit, displayOrder, uiGroup, projection: { supported, reason }, contextSupported, lineOnly, alternateLine }> }. This is what turns a raw stat key like "kills_on_game_1" into a labeled, scoped market so you can group props without guessing. Projection support is provider-driven per market, so partially modeled sports stay honest. When to use: after scan_props / get_game_props, to explain or group the raw stat keys you got back. When not to use: if you only need one sport's existence/access, list_sports already carries marketFamilies.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Sport id (cod, nba, mlb, ...). Omit for the current in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, but the description adds crucial context beyond those: it states 'Read-only. No side effects. Rate-limited per your tier.' It also discloses that projection support is provider-driven per market, so partially modeled sports stay honest, which is a behavioral nuance not captured in annotations. No contradiction exists.
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 longer than the average tool description but every sentence earns its place. It leads with the primary purpose, then lists return fields, then provides a concrete use case, then usage guidelines, then an exclusion. The structure is logical and front-loaded with the most decision-relevant information. A small cut could be made to the detailed field list, but it serves as a contract for the return shape and is not redundant.
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 that this is a read-only metadata tool with a single optional parameter and no output schema, the description provides a complete picture: the full return shape, the purpose, the usage context, the rate-limit caveat, and the exclusion criterion. An agent has everything needed to decide when to call this tool and what to expect from the response, without needing to open the schema or infer anything.
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 single parameter 'sport' is already fully described in the schema ('Sport id (cod, nba, mlb, ...). Omit for the current in-season sport.'), and schema description coverage is 100%. The description does not add additional semantics about the parameter beyond the schema, which meets the baseline of 3 for full schema coverage. It does not hinder usage, but also does not add value beyond what the schema provides.
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-resource-scope triad: 'Return the machine-readable stat vocabulary for a sport.' It then enumerates exactly what is returned (label, family, scope, unit, display order, projection support) and provides a concrete example of its purpose: turning a raw stat key like 'kills_on_game_1' into a labeled, scoped market. It explicitly differentiates from the sibling list_sports by stating that list_sports already carries marketFamilies, so the agent knows exactly what this tool adds.
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 usage guidance: 'When to use: after scan_props / get_game_props, to explain or group the raw stat keys you got back. When not to use: if you only need one sport's existence/access, list_sports already carries marketFamilies.' This directly answers when to use this tool versus alternatives, with a clear exclusion condition and a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Season context from the sport's registered Flash pack: per-market baselines, recent form, and sport-native splits. Free and Builder receive the same basic context shape as REST; Pro adds the dense recent map/game log when available. If the sport has no registered pack or the player is unmatched, returns an honest empty context, never fabricated data. Use list_sports first when you need to discover which sports currently advertise deep context. When to use: "what is this player averaging", "how has this player been playing lately". When not to use: it returns NO posted lines; use find_player_props for the board and get_prop_evidence for one prop against its line.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Player name or gamertag. Exact match is preferred; no invented identity mapping. | |
| sport | No | Sport id. Use list_sports to discover contextCapability. Defaults to cod for backward compatibility. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond that: tier-dependent response shape (Free/Builder vs Pro), dependency on a registered Flash pack, and the honest empty context behavior with no fabricated data. This meaningfully informs an agent about edge cases.
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: it front-loads the core function, then covers tier differences, empty behavior, discovery guidance, and sibling routing. It is structured with clear 'when to use' and 'when not to use' sections, making it easy for an agent to parse.
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 does a good job summarizing return content: basic context shape, per-market baselines, recent form, splits, and the Pro-only dense map/game log. It also covers empty-result behavior. It stops short of detailing the exact response structure, but for selection and invocation purposes it is nearly 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?
Schema description coverage is 100%, so the schema fully documents both parameters, including the default sport value and exact-match preference. The description adds context about pack registration and sport-native splits but does not substantially extend parameter-level meaning. 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 verb and resource: it retrieves season context (per-market baselines, recent form, sport-native splits) from the sport's Flash pack. It clearly distinguishes itself from siblings by explicitly stating it returns NO posted lines and pointing to find_player_props and get_prop_evidence for those needs.
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 when-to-use examples ('what is this player averaging', 'how has this player been playing lately') and when-not-to-use guidance with named alternatives. It also instructs using list_sports first when discovering which sports advertise deep context, which is actionable routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assemble the whole story of a single prop in one call. Read-only. No side effects. Requires an API key and is tier-shaped exactly like REST: Free gets the book/Flash/gap teaser, Builder adds recent form + Confidence summary + movement delta + teaser splits, and Pro gets the full evidence stack including movement series and deep splits. Paywall metadata says exactly which fields are withheld. No picks, no advice. Available when the sport has a registered Flash provider; otherwise returns found:false with a reason, never fake data. When to use: explain one prop end-to-end. When not to use: scan_props for broad discovery or get_player_context for a player overview.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | Yes | Stat key. Call get_market_metadata for the vocabulary. | |
| event | No | Optional event id to disambiguate multi-game slates. | |
| sport | No | Sport id. Use list_sports/get_market_metadata to discover whether the sport + market is modeled. Defaults to cod. | |
| player | Yes | Player name or gamertag (exact normalized match preferred, contains-match fallback). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds rich behavioral context beyond annotations: tier-shaped response (Free/Builder/Pro), paywall metadata indicating withheld fields, 'no picks, no advice', and the found:false-with-reason behavior when no Flash provider exists. 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 a bit longer than necessary but every sentence earns its place: purpose, behavioral tiering, availability, missing-data behavior, and explicit usage guidance. It is front-loaded with the core purpose and ends with when-to/not-to-use. Minor redundancy exists ('Read-only. No side effects.' repeats annotations), but it does not detract significantly.
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 four parameters, no output schema, and annotations covering safety, this description covers everything an agent needs to decide whether and how to call: purpose, tier behavior, provider availability, missing-data behavior, and sibling differentiation. The paywall metadata note signals output shape despite the lack of an output schema. Nothing critical 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?
Schema coverage is 100%, so all four parameters already have descriptive entries in the input schema. The description does not add parameter-level semantics beyond what the schema provides; it focuses on tool-level behavior and tiering. Baseline 3 is appropriate because the schema does the heavy lifting.
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?
States a specific verb+resource: 'Assemble the whole story of a single prop in one call.' The title lists the exact contents (book line, Flash line, gap, form, splits, movement), and the 'When not to use' line explicitly distinguishes it from scan_props and get_player_context. An agent can clearly tell what this tool does and what it does not cover.
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?
Provides explicit 'When to use: explain one prop end-to-end' and 'When not to use: scan_props for broad discovery or get_player_context for a player overview.' It also gives an availability condition (registered Flash provider) that should determine whether the tool can be used, which is exactly the kind of routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chronological line/odds history for a player prop, with opened/current/movement. Free is locked with a structured tier_required response naming Builder as the first unlock. Builder receives the most recent history window; Pro receives full history. History accrues from when archiving started, so early results may be short. When to use: "has this line moved since it opened", "what did this prop open at", the timeline of ONE player prop. When not to use: scan_movers ranks movement across the whole board; get_prop_evidence already includes the movement delta beside the line.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | No | Stat key, e.g. total_bases. | |
| event | No | Restrict to one event id. | |
| limit | No | ||
| sport | No | Sport id, e.g. mlb. | |
| player | Yes | Player name (case-insensitive contains match). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds substantial behavioral context: tier-based access (Free gets a structured tier_required response, Builder gets a window, Pro gets full history) and the note that history accrues only from when archiving started, so early results may be short. This not only complements annotations but enriches them with access-control and data-availability details.
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 somewhat lengthy but each sentence carries weight: it front-loads the core function, then explains tier restrictions and history accrual, and ends with clear use-case routing. It is structured logically and avoids fluff, though it could be tightened slightly by trimming parenthetical examples.
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 the tool's tiered access and the absence of an output schema, the description covers the critical context: what data is returned (opened/current/movement), the tier_required response for Free, and the window difference between Builder and Pro. It also clarifies data availability limitations. Minor gaps like exact pagination or field names are not essential for correct invocation, and the explicit use-cases make it complete enough for an agent.
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 covers 80% of parameters (only 'limit' lacks description), so the description need not compensate. The description does not add parameter-specific meaning beyond the schema examples (e.g., 'total_bases', 'mlb'), and it stays focused on tool behavior rather than parameter syntax. It meets 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 states a specific verb and resource: 'Chronological line/odds history for a player prop' with opened/current/movement. It clearly differentiates from siblings by explicitly naming scan_movers and get_prop_evidence as alternatives for different use cases, making the tool's unique scope (timeline of ONE prop) unambiguous.
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?
Provides explicit when-to-use examples ('has this line moved since it opened', 'what did this prop open at', 'the timeline of ONE player prop') and when-not-to-use with named alternatives (scan_movers for board-wide movement, get_prop_evidence for movement delta). This gives the agent concrete routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return today's games that have player props available for a sport. Read-only. No side effects. Requires an API key; rate-limited per your tier. Returns: { sport, count, games: Array<{ id, sport, homeTeam, awayTeam, startTime, live, source }> }. id is the eventId to pass to get_game_props (prefixed ud- for Underdog or sc- for the soccer odds board); live is true when the game is in progress; source is "underdog" or "theoddsapi". Live games sort first; scheduled games follow. Typical workflow: call list_games to discover eventIds, then pass an eventId to get_game_props. If sport is omitted the server selects the active in-season league automatically. Returns count=0 with an empty games array (not an error) when no props are posted yet for the day. When to use: to browse all games on the slate or to find an eventId before calling get_game_props. When not to use: if you already have the eventId, skip this and call get_game_props directly. Use find_game instead when you know the team names but want a single-game eventId without browsing the full slate.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Sport id: nba, basketball, mlb, nfl, nhl, ncaab, ncaaf, soccer, tennis, cs2, valorant, dota2, esports, or cod. Omit to default to the current in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint and idempotentHint, the description adds substantial behavior: API key requirement, rate limiting, live-game sorting, count=0 as a non-error, source enumeration, and automatic league selection. These details go well beyond the 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 long but densely packed; every sentence earns its place. It is front-loaded with the core purpose, then covers output shape, behavior, and usage guidance in a logical order with 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 provided, the description fully documents the return structure, field meanings, sort order, source values, and count=0 behavior. It also covers the parameter default and typical workflow, so nothing needed for correct invocation 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?
Schema description coverage is 100% and the sole parameter 'sport' is fully documented in the schema, including its default behavior. The tool description essentially repeats 'sport is omitted to select the active league' without adding meaning 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 uses a specific verb and resource: 'Return today's games that have player props available for a sport.' It clearly distinguishes itself from siblings by describing discovery of eventIds, and contrasts with get_game_props and find_game in the usage section.
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' and 'When not to use' sections are present, with concrete alternatives named: 'skip this and call get_game_props directly' and 'Use find_game instead.' This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every sport supported by Flash Props API with its live status and how deep the Flash model goes. Read-only. No side effects. Rate-limited per your tier. Returns { sports: Array<{ id, name, category, enabled, status, activeGames, activeProps, projectedProps, projectionCapability, effectiveProjection, contextCapability, marketFamilies, supportedMarkets, sources, lastFetchedAt, cacheAgeSeconds, shapeCanaryTripped, legalLine, notes, dataStatus, dataReason, projectableMarkets, projectionBasis, coverage, snapshotId, event, season }> }. id is what you pass as the sport parameter to other tools. status: "live" = props posted now, "idle" = none posted now but lines were archived recently, "offseason" = no lines archived for an extended period (observed, never a calendar). snapshotId identifies the exact board the counts describe. projectionCapability is the structural model ceiling; effectiveProjection tempers that by what is actually posted right now. contextCapability "deep" means a registered Flash pack can serve player context; "none" means it cannot. Call this tool instead of hard-coding which sports are modeled. enabled=false means the sport is outside your tier. When to use: to discover valid sport ids, or to check which sport actually has projections/context before asking for them. When not to use: if you already know the sport id and just want its props.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds substantial value by disclosing rate limiting, the exact output shape, the meaning of 'status' values, snapshotId, projectionCapability vs effectiveProjection, contextCapability, and the enabled=false tier restriction. This goes well beyond annotations, though it doesn't discuss error handling or authentication, which are reasonable omissions for a read-only list endpoint.
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 longer than average but every sentence carries useful information. It is front-loaded with the core purpose, then methodically explains the output structure and field meanings, and ends with explicit usage guidance. It is dense but not bloated, and the structure is logical and scannable.
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 zero-input tool, the description provides an extremely thorough explanation of the return value, including nested field meanings, status semantics, and the distinction between structural capability and current availability. It also covers when to use the tool and the enabled flag. There is no output schema, so the description carries the full burden of explaining the response, and it succeeds admirably. Nothing essential 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?
The tool takes zero parameters, so the baseline for parameter semantics is 4 per the rubric. The description fully explains the output fields, which is not strictly parameter semantics but compensates for the lack of an output schema, giving the agent complete understanding of what to expect. The schema coverage is 100% vacuously, so no extra input guidance is needed.
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 verb+resource statement: 'List every sport supported by Flash Props API with its live status and how deep the Flash model goes.' It clearly differentiates from sibling tools by focusing on sport discovery and model capability, and explicitly tells agents not to hard-code sports. It is unambiguous and distinctive.
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 explicit when-to-use and when-not-to-use guidance: 'to discover valid sport ids, or to check which sport actually has projections/context before asking for them' vs 'if you already know the sport id and just want its props.' It also instructs to call this tool instead of hard-coding sports, giving a clear decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Props whose line moved most within a lookback window (default 24h, max 7d), sorted by absolute movement. Free is locked with Builder as the first unlock. Builder gets a limited board; Pro gets the full movement board. When to use: "biggest movers", "which lines moved the most today", steam across a sport. When not to use: the history of one prop is get_prop_history; the current board without movement is scan_props.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | No | Stat key, e.g. passing_yards. | |
| limit | No | ||
| since | No | Lookback window: e.g. 6h, 24h, 3d (1h min, 7d max). Defaults to 24h. | |
| sport | No | Sport id, e.g. nfl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds value by explaining the lookback window behavior (default 24h, max 7d), the sorting criteria (absolute movement), and the tiered access (free is locked, Builder vs Pro). It does not mention any potential delays or data freshness, but for a read-only scanning tool this is adequate. A high score is justified because it enriches beyond 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 fairly concise and front-loaded: the main purpose is in the first sentence. The usage guidance is structured clearly with 'When to use' and 'When not to use'. However, the tier information (free locked, Builder board) is somewhat tangential to the tool's direct usage and adds a bit of noise. Overall, it's well-organized and efficient.
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?
The description covers the tool's core function, lookback parameters, sorting, and usage scenarios. It does not detail the output format, but since there is no output schema, an agent might wonder what the response looks like. However, for a scanning tool, the description provides enough to call it correctly, including hints about the 'since' parameter's format. The tier information is extra context but not necessary. Overall, it's complete for practical use, missing only explicit return shape.
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 75%, with descriptions for stat, since, and sport, but not for limit. The description adds context for the 'since' parameter by explaining the lookback window and its constraints, which is useful beyond the schema. However, it does not explain 'limit' semantics beyond what the schema states (max 500, min 1). Since coverage is high, baseline is 3, and the added context is minimal, so a 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 clearly states the tool's purpose: to list props whose lines moved the most within a lookback window, sorted by absolute movement. It specifies the resource (props), the action (scan for movers), and the distinguishing feature (movement focus). This differentiates it from siblings like scan_props (current board without movement) and get_prop_history (history of one prop).
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' and 'When not to use' sections provide clear guidance. It gives natural language examples ('biggest movers', 'which lines moved the most today') and names alternatives (get_prop_history, scan_props) with their contexts. This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flatten every active player prop across all of today's games for a sport into a single list. Read-only. No side effects. Requires an API key; rate-limited and row-capped per your tier (Free 15 rows, Builder 100, Pro 3,000, Enterprise 5,000). Returns: { sport, stat, count, rows: Array<{ player, stat, line, overOdds, underOdds, bookCount, gameState?, flashProjection?, eventId, sport, homeTeam, awayTeam, startTime, source, fetchedAt }>, snapshotId, snapshotConsistency }. Each row is a player prop merged with its event context; use homeTeam/awayTeam for matchup context. overOdds/underOdds are American-format integers; null when odds unavailable. Use scan_props when you need a broad cross-game market view. Returns count=0 with an empty rows array (not an error) when no props are posted for the day yet. When not to use: use get_game_props when you already have an eventId; use find_player_props for one player.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | No | Filter to exactly one stat market. Omit to return all stat types. | |
| limit | No | Maximum number of rows to return. Capped at your tier limit (Free 15 rows, Builder 100, Pro 3,000, Enterprise 5,000). Omit to return up to your tier maximum. | |
| sport | No | Sport id. Omit to use the current in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds material context beyond them: API-key requirement, per-tier rate limiting and row caps with concrete numbers, and the important empty-case semantic that count=0 with empty rows is not an error. That empty-result disclosure is exactly the kind of behavioral detail agents otherwise misread as failure.
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?
Front-loaded with purpose, then constraints, then return shape, then routing -- a sensible order. It runs long, and the tier cap appears in both the description and the schema, but with no output schema the inline return-shape enumeration largely earns its space.
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?
No output schema exists, so the description compensates by enumerating the return object, row fields, odds format, and the empty-day behavior. For a read-only 3-param flatten query, an agent has everything needed to call and interpret it.
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 stat, limit, and sport are already fully documented including the tier cap on limit. The description's tier-cap recital duplicates the schema rather than extending it; the American-odds/null details describe output fields, not the three input parameters. 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?
States a specific verb and resource -- 'Flatten every active player prop across all of today's games for a sport into a single list' -- with explicit scope (market-wide, cross-game, single sport). An agent can distinguish it from get_game_props and find_player_props without opening the schema, since those siblings are named directly.
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?
Contains an explicit positive trigger ('use scan_props when you need a broad cross-game market view') and an explicit exclusion block routing to get_game_props when an eventId is known and find_player_props for a single player. Both when-to-use and when-not-to-use are covered.
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.
scan_props1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of rows to return. Capped at your tier limit (Free 25 rows, Builder 100, Pro 3,000, Enterprise 5,000). Omit to return up to your tier maximum."New value: +"Maximum number of rows to return. Capped at your tier limit (Free 15 rows, Builder 100, Pro 3,000, Enterprise 5,000). Omit to return up to your tier maximum."scan_props1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of rows to return. Capped at your tier limit (Free 25 rows, Builder 100, Pro 500, Enterprise 5,000). Omit to return up to your tier maximum."New value: +"Maximum number of rows to return. Capped at your tier limit (Free 25 rows, Builder 100, Pro 3,000, Enterprise 5,000). Omit to return up to your tier maximum."get_game_props1 field changedInput schema / properties / eventId / descriptionPrevious value: -"Event id from list_games or find_game. Prefixed ud- or bv-, e.g. \"bv-26839935\" or \"ud-119284\"."New value: +"Event id from list_games or find_game. Prefixed ud- or sc-, e.g. \"ud-119284\"."scan_props2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of rows to return. Capped at your tier limit (free=25, starter=100, pro+=500). Omit to return up to your tier maximum."New value: +"Maximum number of rows to return. Capped at your tier limit (Free 25 rows, Builder 100, Pro 500, Enterprise 5,000). Omit to return up to your tier maximum."Input schema / properties / limit / maximumPrevious value: -500New value: +5000find_game3 fields changedInput schema / properties / away / descriptionPrevious value: -"Away team name or city, matched the same way. Examples: \"Red Sox\", \"Warriors\", \"Buffalo Bills\", \"Arsenal\"."New value: +"Away team name or city, matched the same way."Input schema / properties / home / descriptionPrevious value: -"Home team name or city, matched as a case-insensitive substring of the full team name. Examples: \"Yankees\", \"Lakers\", \"Kansas City Chiefs\", \"Manchester City\". Short codes like \"LAL\" will not match unless literally a substring of the full name."New value: +"Home team name or city, matched as a case-insensitive substring of the full team name."Input schema / properties / sport / descriptionPrevious value: -"Sport id (mlb, nba, nfl, nhl, soccer, etc.). Omit to default to the current in-season sport."New value: +"Sport id. Omit to default to the current in-season sport."get_game_props2 fields changedInput schema / properties / sport / descriptionPrevious value: -"Sport id (nba, mlb, nfl, etc.). Must match the sport the event belongs to. Omit to use the current in-season sport."New value: +"Sport id. Must match the sport the event belongs to. Omit to use the current in-season sport."Input schema / properties / stats / descriptionPrevious value: -"Comma-separated list of stat keys to return, e.g. \"points,rebounds,assists\" for NBA or \"strikeouts,hits_allowed\" for MLB. Omit to return all available markets."New value: +"Comma-separated list of stat keys to return, e.g. \"points,rebounds,assists\" for basketball or \"strikeouts,hits_allowed\" for MLB. Omit to return all available markets."get_leaders3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max rows (default 20)."New value: +"Max rows before tier shaping (default 20)."Input schema / properties / sport / descriptionPrevious value: -"Sport id with a Flash pack (cod, mlb). Defaults to cod."New value: +"Sport id with a registered Flash pack. Defaults to cod."Input schema / properties / stat / descriptionPrevious value: -"Restrict the gap board to one market, e.g. \"kills_on_game_1\"."New value: +"Restrict the gap board to one market."get_player_context2 fields changedInput schema / properties / name / descriptionPrevious value: -"Player gamertag, e.g. \"Shotzzy\". Exact match (case-insensitive) — no fuzzy guessing."New value: +"Player name or gamertag. Exact match is preferred; no invented identity mapping."Input schema / properties / sport / descriptionPrevious value: -"Sport id (cod, mlb, ...). Sports with a Flash pack (cod, mlb today) return data; others an empty context. Defaults to cod."New value: +"Sport id. Use list_sports to discover contextCapability. Defaults to cod for backward compatibility."get_prop_evidence4 fields changedInput schema / properties / event / descriptionPrevious value: -"Optional event id (ud-...) to disambiguate multi-game slates."New value: +"Optional event id to disambiguate multi-game slates."Input schema / properties / player / descriptionPrevious value: -"Player gamertag, e.g. \"Dashy\" (exact normalized match preferred, contains-match fallback)."New value: +"Player name or gamertag (exact normalized match preferred, contains-match fallback)."Input schema / properties / sport / descriptionPrevious value: -"Sport id. Sports with a Flash pack (cod, mlb today) return full evidence; others found:false with a reason. Defaults to cod."New value: +"Sport id. Use list_sports/get_market_metadata to discover whether the sport + market is modeled. Defaults to cod."Input schema / properties / stat / descriptionPrevious value: -"Stat key, e.g. \"kills_on_game_1\". Call get_market_metadata for the vocabulary."New value: +"Stat key. Call get_market_metadata for the vocabulary."get_strategy_doclist_games1 field changedInput schema / properties / sport / descriptionPrevious value: -"Sport id: nba, mlb, nfl, nhl, ncaab, ncaaf, soccer, or cod. Omit to default to the current in-season sport."New value: +"Sport id: nba, basketball, mlb, nfl, nhl, ncaab, ncaaf, soccer, tennis, cs2, valorant, dota2, esports, or cod. Omit to default to the current in-season sport."scan_props2 fields changedInput schema / properties / sport / descriptionPrevious value: -"Sport id (nba, mlb, nfl, etc.). Omit to use the current in-season sport."New value: +"Sport id. Omit to use the current in-season sport."Input schema / properties / stat / descriptionPrevious value: -"Filter to exactly one stat market, e.g. \"strikeouts\", \"points\", \"passing_yards\". Omit to return all stat types."New value: +"Filter to exactly one stat market. Omit to return all stat types."get_strategy_docget_prop_evidence1 field changedInput schema / properties / player / descriptionPrevious value: -"Player gamertag, e.g. \"Dashy\" (case-insensitive contains match)."New value: +"Player gamertag, e.g. \"Dashy\" (exact normalized match preferred, contains-match fallback)."get_prop_evidence1 field changedInput schema / properties / player / descriptionPrevious value: -"Player gamertag, e.g. \"Dashy\" (exact normalized match preferred, contains-match fallback)."New value: +"Player gamertag, e.g. \"Dashy\" (case-insensitive contains match)."get_prop_evidence1 field changedInput schema / properties / player / descriptionPrevious value: -"Player gamertag, e.g. \"Dashy\" (case-insensitive contains match)."New value: +"Player gamertag, e.g. \"Dashy\" (exact normalized match preferred, contains-match fallback)."get_leaders1 field changedInput schema / properties / sportAdded value: +{
+ "description": "Sport id with a Flash pack (cod, mlb). Defaults to cod.",
+ "type": "string"
+}get_player_context1 field changedInput schema / properties / sport / descriptionPrevious value: -"Sport id. Only 'cod' has context data today; defaults to cod."New value: +"Sport id (cod, mlb, ...). Sports with a Flash pack (cod, mlb today) return data; others an empty context. Defaults to cod."get_prop_evidence1 field changedInput schema / properties / sport / descriptionPrevious value: -"Sport id. Only 'cod' has evidence today; defaults to cod."New value: +"Sport id. Sports with a Flash pack (cod, mlb today) return full evidence; others found:false with a reason. Defaults to cod."get_leadersget_prop_evidenceget_market_metadatafind_game2 fields changedInput schema / properties / away / descriptionPrevious value: -"Away team name, city, or abbreviation. Examples: \"Red Sox\", \"GSW\", \"Buffalo Bills\", \"Arsenal\"."New value: +"Away team name or city, matched the same way. Examples: \"Red Sox\", \"Warriors\", \"Buffalo Bills\", \"Arsenal\"."Input schema / properties / home / descriptionPrevious value: -"Home team name, city, or abbreviation. Examples: \"Yankees\", \"LAL\", \"Kansas City Chiefs\", \"Manchester City\"."New value: +"Home team name or city, matched as a case-insensitive substring of the full team name. Examples: \"Yankees\", \"Lakers\", \"Kansas City Chiefs\", \"Manchester City\". Short codes like \"LAL\" will not match unless literally a substring of the full name."find_gamefind_player_propsget_game_propsget_player_contextget_prop_historylist_gameslist_sportsscan_moversscan_propsLive odds, cross-book +EV and graded player-prop results across 37 books. Hosted endpoint included.
NFL/NBA/MLB/NHL/PGA + DFS and prediction-market data. Browse free; query with a free API key.
Pro football play-by-play, stats, injuries, and odds. REST API and MCP server. Free to start.
Sportsbook-derived no-vig fair value with confidence, provenance, and history over REST/MCP.
Add one secure layer between your agents and this server.
