Flash Props API: player-prop analysis, projections, evidence, and line movement over REST/MCP.
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, Starter 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?
With no annotations provided, the description carries the full burden and does so well: it explicitly states 'Read-only. No side effects,' explains tier-based row shaping, and discloses paywall metadata behavior. The metric definitions and 'No picks' line further clarify what the tool does and does not return.
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: core purpose, safety profile, tiering, metric semantics, paywall metadata, exclusions, and a pointer to a sibling tool. It is front-loaded with the most important identifying information and has 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?
For a tool with no output schema and no annotations, the description covers the key behavioral context: what the board ranks, how tiering affects results, and what paywall metadata is included. It could more fully describe the response row shape or how stat interacts with non-gap metrics, but the existing coverage is strong.
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 semantics for the metric parameter by explaining what each enum value ranks, which goes beyond the schema's terse 'gap, form, or sample' description. Other parameters like stat, limit, and sport are less enriched, but the schema already documents them 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 'Ranked boards for a sport with a registered Flash pack,' giving a specific resource and operation. It further differentiates from siblings by explicitly stating 'No picks' and pointing to list_sports for discovery, so an agent can distinguish it from other read-only tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: when ranked boards for a Flash pack sport are needed. It explicitly names list_sports as the alternative for discovering eligible sports, and the 'No picks' statement serves as an exclusion for users seeking pick recommendations.
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 Starter 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 the behavioral burden and does well: it discloses tier differences (Free/Starter vs Pro), the empty-context fallback, and the never-fabricate guarantee. It stops short of covering error/rate-limit behavior, but the key trust-related traits are transparent.
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?
Four sentences, each earning its place: what the tool returns, tier differences, empty-response honesty, and the list_sports prerequisite. The core purpose is front-loaded and no filler is present.
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 two params, no output schema, and no annotations, the description supplies enough context for an agent to select and invoke the tool: return shape, fallback behavior, and discovery path. It is not exhaustively detailed about output structure, but it is sufficient for this tool's complexity.
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 schema already documents name and sport clearly. The description adds contextual flavor about registered packs and sport-native splits, but it does not materially add meaning beyond the schema's parameter 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 identifies the resource ('player context'), the source ('registered Flash pack'), and the contents (baselines, recent form, splits). It is specific enough to be understood, though it does not explicitly differentiate from sibling prop-scoped tools like find_player_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?
Gives practical usage guidance: use list_sports first to discover sports with deep context. It also implies the tool is the right choice for season-context lookups, but it does not enumerate alternatives or exclusion conditions relative to sibling tools.
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, Starter 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 provided, the description carries the full behavioral burden, and it does so thoroughly: it declares read-only/no side effects, API key requirement, tier-shaped response behavior, paywall metadata, no picks/advice, and the found:false failure mode with reasons. This goes far beyond what the schema alone reveals.
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 one sentence but every sentence carries distinct value: core purpose, safety, tier behavior, failure mode, and usage guidance. It is front-loaded with the primary purpose and structured logically from general to specific. It could be slightly trimmed without loss, but it avoids redundancy and remains 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?
Given the tool's complexity (tiering, provider availability, no output schema), the description covers the essential context: what the response contains per tier, how paywall withholding is communicated, failure behavior with found:false, and when to use alternatives. An agent has enough to decide whether and how to invoke this tool 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 does not add parameter-level detail beyond the schema, but the schema already documents each parameter's purpose (e.g., stat key, sport id, player name). The description's mention of 'player or gamertag' and 'event id to disambiguate' reinforces schema text without significantly adding new semantic meaning.
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: 'Assemble the whole story of a single prop in one call.' It clearly distinguishes this tool from siblings by focusing on one prop's complete evidence, differentiated from scan_props and get_player_context. The title reinforces the scope by enumerating the evidence components.
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: 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 provides a conditional availability guideline about the Flash provider. These explicit routing instructions leave no ambiguity for an agent.
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 Starter as the first unlock. Starter 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?
No annotations are provided, so the description must disclose behavior itself. It reveals the Free tier lock, the tier_required response structure, the difference between Starter and Pro history windows, and the archive start caveat. This is strong behavioral context for a tool with no annotations, but it does not mention pagination or whether limit affects the returned history beyond max 5000.
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 three sentences, each earning its place: first defines what it does, second explains tier access, third explains the archive caveat. No filler or repetition of 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?
For a history/odds tool with 5 parameters and no output schema, the description covers the core behavior, tier restrictions, and data availability caveat. It doesn't explain default values or whether the returned history also includes current odds format, but with 80% schema coverage and the tiering detail, it is largely complete. Minor gaps are the default behaviors of optional parameters.
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 80%, so the schema documents most parameters. The description uses 'player prop' but does not clarify optional parameters beyond 'stat', 'event', 'limit', 'sport'. It adds the meaning of the response behavior by tier but not extra semantic detail for individual parameters. Baseline 3 is reasonable because the schema covers most params.
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 a specific verb and resource: get chronological line/odds history for a player prop, including opened/current/movement. It clearly differentiates from siblings such as find_player_props and scan_movers by focusing specifically on line history for a single prop, not prop discovery or scanning.
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 explains the tiering behavior (Free returns a tier_required response, Starter gets recent window, Pro gets full history) and warns that early history may be short. It doesn't explicitly name when to use this instead of a sibling, but the context of 'history for a prop' is clear given the sibling list. Clear context with minor gap: no alternative tools named.
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 Starter as the first unlock. Starter 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?
With no annotations provided, the description carries the full behavioral disclosure burden and discloses genuinely useful traits: lookback defaults and maximums, sorting behavior by absolute movement, and tier gating (Free locked, Starter gets a limited board, Pro gets the full board). It does not cover what happens when stat/sport/limit are omitted, but the disclosed behaviors substantially exceed what the schema alone conveys.
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 dense sentences with the core function, window behavior, and sort order front-loaded, followed by access-tier context. Every sentence earns its place and there is no filler or repetition of schema content.
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 scan tool with four optional parameters and no required ones, the description explains the core behavior and tiering but does not state what a no-parameter call returns or what the response looks like. With no output schema and no annotations, these gaps leave an agent to guess about default boards and return format.
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 75%, so the schema already documents stat, since, and sport; the description reinforces the since parameter's default and maximum, which overlaps rather than adds. It contributes nothing for limit, the one parameter lacking a schema description, and does not explain how omitting stat or sport affects the returned board.
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 first sentence states a specific function: returning props whose line moved most within a lookback window, with explicit sort order (absolute movement), a default window (24h), and a max (7d). This is clear and concrete, though it does not explicitly differentiate itself from the similarly named sibling scan_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?
There is no guidance on when to select this tool over alternatives. With 11 siblings including the closely named scan_props, the description never steers the agent between 'props that moved the most' and a general prop scan or prop history lookup. The tier-gating sentence is about access levels, not usage selection.
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. Dates show when Glama detected each change.
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_propsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Live 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.
Each tool targets a distinct resource or access pattern: game lookup, game props, player props, cross-game scans, metadata, context, evidence, history, leaders, and movers. Related tools like list_games/find_game and scan_props/find_player_props are clearly separated by scope and reinforced with when-to-use guidance. No two tools appear to do the same job.
All 12 tool names follow a consistent snake_case verb_noun pattern with a small set of meaningful verbs: find_* for lookups, list_* for catalogs, get_* for specific resources, and scan_* for cross-game views. There is no casing or verb-style mixing.
12 tools is well within the ideal range and appropriate for the API's breadth: sports discovery, game discovery, multiple prop-access paths, market vocabulary, player context, evidence/history, and movement/leader boards. Each tool adds a distinct access pattern rather than redundant duplication.
The surface covers the full read-only workflow: discover sports, resolve games/eventIds, fetch props by game/player/cross-game, interpret market keys, and drill into context/evidence/history/movers/leaders. Tool outputs feed naturally into each other, so there are no obvious dead ends or missing operations for the stated domain.
