Flash Props API: player-prop analysis, projections, evidence, and line movement over REST/MCP.
Scored across 12 tools
Each tool has a clearly distinct purpose: listing vs finding games, per-game vs per-player vs cross-game prop retrieval, and separate tools for context, evidence, history, movers, leaders, and metadata. Even the closely related scan/find/get functions are cleanly separated by scope and documented with explicit use cases.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., find_game, list_sports, scan_props, get_prop_history). The prefix clearly indicates the action (find/list/scan/get), making the API predictable and easy to navigate.
12 tools is within the ideal 3-15 range and fits the domain of a read-only sports props API. Each tool serves a distinct query need without redundancy, so the count feels neither sparse nor bloated.
The tool set covers the full read-only lifecycle: discovering sports, listing/finding games, fetching per-game or cross-game props, filtering by player, and accessing contextual data (metadata, context, evidence, history, movers, leaders). No obvious gaps exist for the stated 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?
With no annotations provided, the description carries the full burden and does an excellent job: it discloses read-only/no side effects, API key requirement, rate limiting, matching semantics, tie-breaking by start time, success payload shape, and failure behavior.
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: when to use, safety profile, success/failure behavior, matching semantics, and explicit alternatives. The most important purpose is front-loaded in the first sentence.
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?
Despite no output schema and no annotations, the description is complete enough for an agent to call the tool correctly: it covers input semantics, output format, edge cases with multiple matches, failure mode, authentication/rate limits, and routing to sibling tools.
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. The description adds meaningful semantic detail beyond the schema: case-insensitive substring containment, defaulting sport to the current in-season sport, and passing the resulting eventId directly to get_game_props.
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: translating a home/away matchup into the eventId needed by get_game_props. It clearly distinguishes the tool from siblings by focusing on resolving team names to an ID rather than browsing or fetching props.
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 explicitly states when to use the tool ('when you know the teams playing but don't have the eventId') and when not to use it, naming alternatives: list_games for browsing a slate and get_game_props if you already have the eventId.
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. Use this when you know the player but not which game/event they're in.
| 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?
With no annotations, the description carries the full burden. It discloses matching behavior (exact normalized match preferred, case-insensitive contains fallback), refers to matchType in the response, and reduces ambiguity by stating rows match scan_props. It does not mention response format details or error cases, but covers the most important behavioral traits.
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?
Two sentences, front-loaded with the core purpose and scope, then the key matching detail and a clear usage condition. No filler or redundancy; every sentence earns 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?
For a simple 2-parameter reader with no output schema and no annotations, the description covers what the tool returns (rows like scan_props), how filtering works, and when to choose it. The only implicit dependency is familiarity with scan_props, which is acceptable given sibling context.
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 baseline is 3. The description adds value by explaining how the 'name' parameter behaves (normalized vs. contains matching, fallback logic) and clarifies that 'sport' scopes the board. This goes beyond the schema's basic type labels.
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 action ('find active props for a player') with clear scope ('across today's board for a sport') and explicitly differentiates from scan_props by the filter dimension ('by name ... instead of stat'). The title and description are mutually reinforcing and 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 an explicit 'Use this when' condition — 'you know the player but not which game/event they're in' — and implicitly contrasts with scan_props ('instead of stat'), giving the agent a clear decision rule among siblings.
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 }. flashProjection is present when that sport + market has a registered Flash model and a player baseline is available; it is { value, sampleN, method, marketKey } and is never fabricated. 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 bv- (Bovada source). 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 bv-, e.g. "bv-26839935" or "ud-119284". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and meets it: 'Read-only. No side effects. Requires an API key; rate-limited per your tier.' It also documents error conditions, defensive guarantees (flashProjection is never fabricated), and value formats (American-format odds, null when unavailable).
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 every sentence earns its place: core purpose, safety/rate-limit behavior, return shape, parameter guidance, workflow, and explicit exclusions. It is front-loaded with the main action and scopes later remarks to edge cases and alternatives rather than repeating the schema.
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?
Since there is no output schema, the description fully documents the return shape and key field semantics, including the conditional flashProjection object and null odds. It also covers error conditions and prerequisite eventId resolution, making the tool callable without external docs. Minor fields like sources and delayed are named but their meaning is inferable.
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. The description adds meaningful context beyond the schema: eventId prefix examples ('bv-26839935'), the sport omission default ('current in-season sport'), and concrete stat-market examples for basketball and MLB, which helps an agent form valid parameter values.
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 itself from siblings by naming scan_props and find_player_props as alternatives for different use cases, so an agent can select this tool without ambiguity.
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 explicitly states 'When to use: when you have an eventId and want all props for that specific game' and 'When not to use' with specific sibling tools (scan_props, find_player_props). It also provides a typical workflow pairing list_games or find_game with get_game_props, leaving nothing to inference.
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.
| 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?
Explicitly states 'Read-only. No side effects' and mentions paywall metadata (totalAvailable, next unlock), giving a clear picture of access limits. However, it does not describe error behavior or fallback when a sport lacks a Flash pack.
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-loads the core purpose, but the middle section repeats 'tier-shaped exactly like REST' and enumerates metrics in a way that could be tightened. No fluff or irrelevant details.
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 read-only behavior, paywall metadata, and metric options, but it lacks details about the response format (e.g., whether it returns player names, stats, or just IDs) and does not specify ordering semantics. Given the simplicity of the tool, it is minimally complete but has gaps.
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 descriptions cover 100% of parameters, but they add limited meaning. For example, 'Restrict the gap board to one market' is vague, and 'Max rows before tier shaping' is cryptic. The metric enum is described but not how each metric affects ordering.
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 it returns 'ranked boards' but does not clearly specify the subject (players? teams?) or the action verb. The term 'Flash pack' is ambiguous, and the tiering reference to REST is not self-explanatory.
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 the hint 'Use list_sports to discover which sports have deep context' and clarifies it does not return picks, but it does not explicitly compare to sibling tools like get_player_context or scan_movers or state when this tool is preferred.
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?
With no annotations provided, the description carries the full burden and does so thoroughly: it declares 'Read-only. No side effects. Rate-limited per your tier.' It also discloses the provider-driven nature of projection support, which warns agents that partial data is intentional rather than an error. The returned object shape is fully spelled out, leaving little behavioral ambiguity.
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 fronts the primary result, gives concrete examples, explains why the data matters, states provider-driven behavior, and closes with explicit routing guidance. The return shape is long but directly useful since no output schema exists.
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 simple one-parameter read-only lookup with no output schema and no annotations, the description is complete. It covers the return structure, use cases, non-use cases, rate limiting, and data semantics. The only minor gap is not defining 'Flash projection', but the description already gives enough context that an agent can use the field 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%: the single optional 'sport' parameter is documented in the schema with examples and default behavior ('Omit for the current in-season sport'). The tool description adds no parameter-specific semantics, but the schema already covers it well. 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 states a specific verb ('Return') and resource ('machine-readable stat vocabulary for a sport'), then enumerates exactly what the vocabulary contains: label, family, scope, unit, display order, and projection support. It also distinguishes itself from list_sports by clarifying that this tool resolves raw stat keys into labeled, scoped markets. An agent can tell it apart from all sibling tools without opening 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?
The description gives explicit when-to-use guidance: after scan_props or get_game_props, to explain or group raw stat keys. It also gives an explicit when-not-to-use rule, pointing to list_sports for checking a sport's existence/access. No inference is required.
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.
| 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?
With no annotations, the description carries full responsibility. It discloses that it returns an honest empty context when the sport has no pack or the player is unmatched, never fabricating data. It also reveals tier-based differences in the response shape (basic vs dense map/game log). It does not discuss side effects, but as a 'get' operation, the read-only nature is implied; the honesty disclosure and tier details go beyond minimal expectations.
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 composed of four sentences, each delivering distinct value: the core purpose, tier differences, the honesty guarantee, and a usage pointer. It is front-loaded with the primary function and does not waste words. While not as terse as a single-line description, it is appropriately sized for the complexity and remains well-structured.
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 gives a clear idea of the return content (per-market baselines, recent form, splits, and optional dense map/game log for Pro) and the empty-context behavior. It lacks an explicit return format or field details, but since no output schema exists, the description provides enough for an agent to know what to expect and how to handle missing data. It is complete for a simple two-parameter get 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 coverage is 100%, so both parameters are already described. The description adds extra guidance on the name parameter ('Exact match is preferred; no invented identity mapping') and suggests using list_sports for the sport parameter, which slightly enhances the schema. However, it does not elaborate on formats, allowed values, or defaults beyond what the schema already provides, so it only marginally exceeds the baseline.
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 retrieves season context (baselines, recent form, sport-native splits) for a player, with a specific resource ('the sport's registered Flash pack'). It distinguishes from siblings by focusing on context rather than props, evidence, or history, and adds tier differences (Free/Builder vs Pro) that clarify what is returned.
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 advises using list_sports first to discover which sports advertise deep context, and notes that exact name matching is preferred with no invented identity mapping. It also explains the empty-context fallback. It does not explicitly contrast with other sibling tools (e.g., get_player_props), but the guidance on list_sports and name matching provides clear usage context.
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?
With no annotations, the description carries full behavioral disclosure. It states 'Read-only. No side effects,' 'No picks, no advice,' describes tier-based access and paywall metadata, and explains fallback behavior ('returns found:false with a reason, never fake data'). It also mentions requiring an API key. This is comprehensive and goes beyond a simple action statement.
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 purpose and key attributes, then details tiers and usage. While it is longer than typical, every sentence adds value—tier behavior, fallback, and usage guidance are all essential. The structure is logical, though a slightly more compact version could exist without losing clarity.
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 adequately covers the tool's scope, expected outputs (teaser, form, splits, movement series), tier variations, and fallback behavior. It also clarifies what it does not do (picks, advice). Given no output schema, it gives a good sense of what to expect, though it doesn't enumerate exact response fields. The context is sufficient for an agent to decide when and how to call 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?
The input schema already provides descriptions for all 4 parameters (100% coverage), so the baseline is 3. The description does not add additional meaning beyond what the schema provides—it mentions 'event id' disambiguation but that is already in the schema. No extra parameter context is given.
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: 'Assemble the whole story of a single prop in one call.' It uses a specific verb (assemble) and resource (prop evidence) and explicitly differentiates from siblings by naming when not to use scan_props and get_player_context. The agent can immediately understand this tool is for deep single-prop analysis, distinct from broad discovery or player overview.
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: '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.' It also states tier requirements and provider availability, giving clear conditions for invocation.
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.
| 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?
With no annotations, the description carries the transparency burden and does disclose locking behavior, tier requirements, and that history begins when archiving started. It does not mention side effects, errors, or output format, but the read-only nature is inferable from the name.
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?
Description is compact and front-loaded with the core purpose, then gives necessary tier and data-availability context. No redundant or irrelevant sentences.
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 is provided, and the description does not state the response shape or fields beyond mentioning a tier_required response. However, it gives enough contextual information about access levels and data history for an agent to decide whether to call 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 covers 80% of parameters with descriptions, and the description adds no additional parameter context. The limit parameter lacks a description, but min/max constraints provide some guidance, and player/stat/event/sport are clearly described.
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?
Clearly identifies the tool as providing chronological line/odds history for a player prop, and distinguishes it from sibling prop-related tools by focusing on historical movement rather than current props or evidence. The verb is implied by the tool name and noun-phrase description, but the description is specific enough for selection.
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?
Explains tier-based access and history windows, so an agent understands when results may be locked or limited. It does not explicitly contrast with sibling tools like get_prop_evidence or find_player_props, so guidance for choosing among them is only implied.
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 bv- for Bovada); live is true when the game is in progress; source is "underdog" or "bovada". 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?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it declares read-only/no side effects, API key and rate-limit requirements, return shape, field semantics, sort order, sport defaulting behavior, and the count=0 edge case. This is far beyond the minimum for a tool with no annotation coverage.
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 information-dense, front-loading the core purpose before diving into details. Almost every sentence adds necessary context given the absent annotations and output schema, though a few points (workflow and when-to-use) overlap slightly and could be tightened.
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 simple one-optional-parameter tool with no annotations and no output schema, the description is exceptionally complete: it covers return structure, field meanings, ordering, default behavior, empty results, authentication/rate limits, workflow, and sibling alternatives. An agent has everything 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?
The schema already contains 100% of the parameter information for 'sport', so the baseline is 3. The description adds value by explaining what happens when sport is omitted (server selects the active in-season league) and clarifying the role of the returned eventId, which is useful 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 opens with a specific verb and resource: 'Return today's games that have player props available for a sport.' It also distinguishes itself from siblings like get_game_props and find_game, making it easy for an agent to select the correct tool.
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 the tool ('to browse all games on the slate or to find an eventId before calling get_game_props') and when not to use it ('if you already have the eventId, skip this'). It also names the alternative find_game for team-name-based lookups.
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 }> }. id is what you pass as the sport parameter to other tools. status: "live" = props posted now, "idle" = in-season but none posted, "offseason" = out of season. 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?
No annotations are provided, so the description carries the full load. It states 'Read-only', 'No side effects', and 'Rate-limited per your tier', and it explains subtle state semantics like live/idle/offseason, projectionCapability versus effectiveProjection, and enabled=false meaning tier exclusion.
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 structured: purpose, behavior, return shape, field semantics, and usage guidance each earn their place. It is front-loaded with the main purpose and uses short labeled segments rather than prose, so an agent can scan it efficiently.
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 no-parameter tool with no output schema, the description is unusually complete: it enumerates the full return object and explains the non-obvious status and capability fields. The remaining fields such as sources, lastFetchedAt, and notes are self-evident or peripheral to correct invocation.
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 coverage is 100%, so the input side has no ambiguity. The description adds useful cross-tool context by explaining that the returned id is the value to pass as the sport parameter to other tools, which is a helpful bonus.
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 ('List every sport supported by Flash Props API') and states exactly what is returned: live status and model depth. It clearly positions this as the discovery tool for sport ids, distinguishing it from the game- and prop-focused siblings.
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' and 'When not to use' sections, including the rule to call this tool instead of hard-coding which sports are modeled. It even names the condition under which another kind of tool is appropriate: when the sport id is already known and props are wanted.
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.
| 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?
No annotations are provided, so the description must carry behavioral disclosure. It only mentions access restrictions ('Free is locked with Builder as the first unlock. Builder gets a limited board; Pro gets the full movement board.'), but does not state whether the operation is read-only, rate limits, pagination, or response format. This is insufficient for a tool with no annotation support.
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 two concise sentences, front-loaded with the core function ('Props whose line moved most...') and the access tier note is relevant but not redundant. No wasted words; every sentence earns 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?
The description covers the core functionality and access tiers, but omits output structure, pagination, error handling, and authentication requirements. Given no output schema, the description should explain what the agent receives in return, but it does not. The tool is simple, yet still incomplete for reliable invocation.
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 description repeats the default lookback window from the schema ('default 24h, max 7d') but adds no new parameter meaning. The schema already documents stat, since, and sport; the limit parameter lacks a description in the schema and the tool description does not compensate. With 75% schema coverage, the description should fill the gap but does not.
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+resource: 'Props whose line moved most within a lookback window... sorted by absolute movement.' This clearly distinguishes it from general scanning tools like scan_props by focusing on line movement magnitude, making the tool's purpose immediately 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?
The description does not mention when to use this tool versus alternatives like scan_props or get_prop_history, nor any exclusions. It only mentions access tiers (Builder/Pro), which is about licensing, not usage context. The agent must infer when to choose this tool based solely on its name and definition.
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: 25 rows, starter: 100, pro+: 500). Returns: { sport, stat, count, rows: Array<{ player, stat, line, overOdds, underOdds, bookCount, gameState?, flashProjection?, eventId, sport, homeTeam, awayTeam, startTime, source, fetchedAt }> }. 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=25, starter=100, pro+=500). 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?
Even though no annotations are provided, the description discloses key behavioral facts: the operation is read-only with no side effects, it is API-key gated and rate-limited, results are row-capped per tier, and count=0 with an empty rows array is returned instead of an error when no props exist. It also explains odds formatting (American integers, null when unavailable) and row fields such as gameState? and flashProjection? being optional. This goes well beyond a basic description, though it doesn't go into deeper side effects or failure modes beyond rate limits.
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 well-structured: a clear lead sentence, a return-shape block, THEN when-to-use and when-not-to-use, plus exact null/empty behavior. Every sentence earns its place; the most important scope and usage routing are front-loaded.
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, no-side-effect listing tool with 0 required parameters and full schema coverage, the description covers scope, return semantics, edge cases, and alternatives. It lacks an explicit statement of error codes or network/rate-limit failure behavior beyond mentioning rate-limited, but given the simple parameter surface and no required params, this is complete enough for an agent 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 input schema already documents all three parameters. The description reinforces the tier limit and default behavior (omit limit to use tier maximum; omit sport to use current in-season sport), but it doesn't add a lot of novel parameter detail beyond what the schema provides. Baseline 3 is appropriate when schema carries 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?
The description states an explicit action (Flatten/scan), a precise resource (all active player props across all of today's games for a sport), and a clear output shape. It differentiates itself from siblings like get_game_props and find_player_props by naming them, and even frames itself as a market-wide broad view, so an agent can clearly tell what this tool is for.
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 guidance ('when you need a broad cross-game market view'), explicit when-not-to-use guidance ('use get_game_props when you already have an eventId; use find_player_props for one player'), and mentions the tier limit behavior. This is very strong routing information.
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.
find_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 27 books. Hosted endpoint included.
NFL/NBA/MLB/NHL/PGA + DFS and prediction-market data. Browse free; query with a free API key.
Sportsbook-derived no-vig fair value with confidence, provenance, and history over REST/MCP.
Real-time sports betting data: odds, player props, edges and arbitrage from 35+ books and DFS apps.
Add one secure layer between your agents and this server.
