Flash Props API
Server Details
Live sports betting player props (NBA/MLB/NFL/NHL/NCAA/soccer) over REST and MCP. No scraping.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 9 of 9 tools scored. Lowest: 3.8/5.
Each tool targets a distinct purpose: game discovery (find_game vs list_games), prop retrieval (get_game_props vs scan_props vs find_player_props), specific analytics (scan_movers, get_prop_history, get_player_context), and meta-info (list_sports). No two tools have overlapping functionality.
Tool names follow a consistent verb+noun pattern within subsets (find_, get_, list_, scan_), but the variety of verbs across subsets introduces mild inconsistency. However, the naming is predictable once the pattern is understood.
9 tools cover the essential operations for a sports props API without unnecessary clutter. Each tool serves a clear role in the workflow of discovering and retrieving props data.
The tool set covers all typical use cases: listing sports and games, resolving games by teams, fetching props per game or per player, scanning all props, viewing line movement, and accessing player context and prop history. No obvious gaps for a read-only data API.
Available Tools
9 toolsfind_gameResolve team names to an event idAInspect
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 (e.g. "Yankees" or "New York Yankees" resolve for MLB) — short codes like "NYY" or "NY" do NOT match unless they are literally a substring of the team name. If no game is found, the matchup may not be scheduled for today or the sport may be off-season. When to use: when you know both team names and want the eventId without browsing the full slate. When not to use: use list_games instead when you want to browse all games on the slate. Use 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. Examples: "Red Sox", "Warriors", "Buffalo Bills", "Arsenal". | |
| home | Yes | 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. | |
| sport | No | Sport id (mlb, nba, nfl, nhl, soccer, etc.). Omit to default to the current in-season sport. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses read-only, no side effects, requires API key, rate limits, success/failure behavior, multiple match handling, matching logic (case-insensitive substring), and reasons for failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with core purpose front-loaded. Every sentence adds value, though slightly verbose. Could be more concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values on success and failure, covers edge cases (multiple matches, no match, sport off-season), and integrates with 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% and the description adds extra meaning: matching logic details, examples, and default behavior for the optional sport parameter. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Translate a matchup (home team + away team) into the eventId needed by get_game_props.' It uses a specific verb and resource, distinguishes from siblings by mentioning get_game_props and list_games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('when you know both team names') and when not to use ('use list_games instead when you want to browse all games on the slate. Use get_game_props directly if you already have the eventId.'). Also provides alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_player_propsFind all active props for a playerAInspect
Every active prop for one player across today's board for a sport — same rows as scan_props, filtered by name (case-insensitive contains match) 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses the core behavior: returns same rows as scan_props but filtered by name with case-insensitive contains match. However, it does not mention edge cases (e.g., no matching players) or 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?
Two sentences, no filler. Front-loaded with purpose and filtering method. Every sentence is essential and informative.
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 simplicity (2 parameters, no output schema), the description is largely complete. It references sibling scan_props for context, and covers the filtering logic. Minor gaps like pagination or limit details are acceptable for a straightforward lookup.
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% with descriptions for both parameters. The description adds value by specifying that the name filter is case-insensitive contains match, which is not in the schema. For sport, it clarifies default behavior. Baseline 3, plus added value gives 4.
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 finds all active props for a player across today's board, filtering by name (case-insensitive). It distinguishes from sibling scan_props by specifying the filtering criterion. The verb 'find' and resource 'active props for a player' are precise.
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 says 'Use this when you know the player but not which game/event they're in.' This provides clear guidance on when to use the tool versus alternatives like scan_props.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_game_propsGet player props for a specific gameAInspect
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 (CoD only, when available) is { value, sampleN, method, marketKey }, the Flash season-baseline projection, 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 NBA, "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 (e.g. all strikeout props today). 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 (nba, mlb, nfl, etc.). 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 NBA 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only, no side effects, API key requirement, rate limits, return structure, flashProjection details, null handling, stat filtering, event ID prefixes, and error conditions.
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 well-structured and front-loaded with main action, then details. It is somewhat lengthy but every sentence adds value; minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description comprehensively covers parameters, return structure, auth, rate limits, errors, and sibling differentiation. No missing context for agent to use the 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 coverage is 100% so baseline is 3. Description adds value by explaining typical workflow, stat key examples, event ID prefixes, and when to omit sport parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch all player props for one game identified by eventId'. Uses specific verb+resource and distinguishes from siblings like scan_props and 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?
Explicitly states when to use (when you have eventId) and when not to use (use scan_props or find_player_props instead). Provides typical workflow with list_games and find_game.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_player_contextPer-mode averages, recent form, and sample size for a playerAInspect
Season per-mode stats + Flash projection markets for a player, from the Flashpoint CDL context pack. CoD only today — other sports (and unmatched gamertags) return an honest empty context, never fabricated data. Free on every tier.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Player gamertag, e.g. "Shotzzy". Exact match (case-insensitive) — no fuzzy guessing. | |
| sport | No | Sport id. Only 'cod' has context data today; defaults to cod. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It guarantees 'never fabricated data' and 'honest empty context', which builds trust. However, it does not disclose potential performance traits like rate limits, authority requirements, or whether the operation is read-only.
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 brief (two substantive sentences plus a note on pricing) and front-loaded with key information (stats and projections). It wastes no words, though the title could be integrated into the description for 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?
Given low complexity (2 parameters, no nested objects, no output schema return values barely described—only 'stats + Flash projection markets' without structure). The description does not specify what exact stats are returned, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described well in JSON schema). The description repeats the exact match constraint and case-insensitivity already in the schema, and adds no new semantic meaning beyond stating the context pack. Baseline 3 applies since description value is marginal.
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?
Title and description clearly state the tool's purpose: returning per-mode averages, recent form, sample size, and Flash projection markets for a player. It specifies the scope (CoD only, from Flashpoint CDL context pack) and distinguishes from other tools by noting that other sports return empty context.
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?
Description explicitly states when to use (CoD) and when not (other sports, unmatched gamertags return empty context). It also mentions 'free on every tier' to indicate no cost barrier, but does not contrast directly with sibling tools like find_player_props or get_game_props.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_prop_historyLine history for a prop (Pro)AInspect
Chronological line/odds history for a player prop, with opened/current/movement. Pro tier and above — free/starter keys get a deny message pointing at the upgrade. 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tier-based access restriction and the data archival start limitation. However, it doesn't state that the operation is read-only, or discuss error handling, rate limits, or what happens if the player doesn't exist. The disclosure is useful but not exhaustive.
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 only two sentences. The first states the core functionality, and the second adds important usage constraints. Every word earns its place; no fluff.
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 has no output schema, the description gives a reasonable sense of the return (chronological line/odds history). It mentions data start time, which is helpful. Could elaborate on output format or pagination, but for a query tool with sibling context, it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), so the schema already explains most parameters clearly. The description adds no extra detail about parameters like limit or event. The baseline of 3 is appropriate as the description doesn't significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving chronological line/odds history for a player prop, including opened, current, and movement fields. It distinguishes itself from sibling tools like find_player_props and get_game_props by focusing on history rather than current props or game-level 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?
The description provides context on when to use: it's for Pro tier users, with free/starter accounts receiving a deny message. It also notes that history starts from whenever archiving began, so early results may be incomplete. It doesn't explicitly compare to alternatives, but the specificity is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_gamesList today's gamesAInspect
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, mlb, nfl, nhl, ncaab, ncaaf, soccer, or cod. Omit to default to the current in-season sport. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: read-only, no side effects, requires API key, rate-limited, return structure with field details (id prefix, live sorting, empty array handling), and recommended workflow.
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 verbose but well-structured with front-loaded purpose and subsequent details. Every sentence adds value, though could be slightly tighter 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?
Despite no output schema, the description fully specifies the return structure, fields, and edge cases (empty array not error). It also provides workflow context and distinguishes from sibling tools, making it complete for a tool of this 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 covers all parameters (100% coverage) with descriptions. The description adds meaning by explaining that omitting sport defaults to the active in-season league, enhancing understanding beyond the schema alone.
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?
Title and description clearly state the tool returns today's games with player props for a sport. It distinguishes from siblings like find_game (when you know team names) and get_game_props (for a specific eventId), fulfilling the purpose clarity dimension well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (browse slate or find eventId), when not to use (if eventId known, use get_game_props), and suggests find_game as alternative when team names are known, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sportsList sportsAInspect
List every sport supported by Flash Props API and whether your API key tier can access it. Read-only. No side effects. No authentication required. Never fails or returns an error. Returns an array of objects: { id: string, name: string, enabled: boolean }. The id field is what you pass as the sport parameter to list_games, get_game_props, scan_props, and find_game. enabled=false means the sport exists in the catalog but your current tier does not include it — upgrade at https://api.flashodds.live/#pricing to unlock. When to use: call list_sports first when you do not know which sport ids are valid, or to check tier access before calling other tools. When not to use: if you already know the sport id (e.g. "nba"), skip this and call list_games or scan_props directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: read-only, no side effects, no authentication required, never fails, return format, and meaning of the enabled field. No hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
All sentences are purposeful and well-organized. The description is comprehensive without redundancy, covering purpose, behavior, output, usage guidance, and integration with other tools.
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, the description fully explains the return structure and semantics. It also contextualizes the tool's role within the broader API, making it complete for an agent to use 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?
No parameters exist (baseline 4), but the description adds value by detailing the output fields and how the id field is used across sibling tools, which is more than minimally expected.
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 lists every sport supported by the API and checks tier access. It distinguishes from siblings by explaining that this tool is for discovering sport ids and tier status before using other tools like list_games or 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?
Explicitly states when to use (when you don't know sport ids or need to check tier access) and when not to use (if sport id is already known), with direct references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_moversBiggest line movers (Pro)AInspect
Props whose line moved most within a lookback window (default 24h, max 7d), sorted by absolute movement. Pro tier and above — free/starter keys get a deny message pointing at the upgrade.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses sorting, default lookback window (24h), max window (7d), and tier restriction. However, missing details on rate limits or data freshness.
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 purpose, then tier note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description is fairly complete. It explains core behavior and restriction. Lacks return structure details, but acceptable for a scan 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 75%, baseline 3. Description adds value by clarifying default for 'since' (24h) and sorting behavior. It does not repeat schema but enhances context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns props with the biggest line movement within a lookback window, sorted by absolute movement. It distinguishes from siblings like scan_props by focusing on movers.
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 mentions the Pro tier restriction but does not provide explicit guidance on when to use this tool vs alternatives like scan_props or get_prop_history. The use case is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_propsScan all props across today's slate (market-wide feed)AInspect
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 — there is no team or opponent field; use homeTeam/awayTeam instead. overOdds/underOdds are American-format integers; null when odds unavailable. Use scan_props when you need a broad cross-game market view — e.g. every player with a strikeouts prop today, all passing-yards lines for the slate, or which players have the most active markets. Returns count=0 with an empty rows array (not an error) when no props are posted for the day yet. When to use: broad market discovery across all games for a sport. When not to use: use get_game_props instead when you already have an eventId and want one game only — it is faster and not row-capped. Use find_player_props instead when you want all markets for one player by name.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | No | Filter to exactly one stat market, e.g. "strikeouts", "points", "passing_yards". 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 (nba, mlb, nfl, etc.). Omit to use the current in-season sport. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses all important behavioral traits: read-only, no side effects, requires API key, rate-limited and row-capped per tier, return structure (including field meanings like overOdds being American-format integers), and edge cases (empty rows when no props posted). Compensates fully for lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main purpose, return details, when to use/not use). Slightly verbose but every sentence adds value; could be tightened slightly without loss.
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 has 3 parameters, no output schema, and moderate complexity, the description covers everything needed: purpose, parameters, return format, edge cases, usage guidance, and behavioral traits. It is complete and self-contained.
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%, but the description adds substantial meaning beyond schema: explains the stat filter, limit capped by tier, sport default, return fields (overOdds format, no team/opponent field, use homeTeam/awayTeam instead), and the significance of count=0.
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 core action: 'Flatten every active player prop across all of today's games for a sport into a single list.' It uses a specific verb (flatten/scan) and resource (player props across games), and distinguishes itself from siblings like get_game_props and find_player_props by clarifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use and when-not-to-use guidance, naming specific alternative tools (get_game_props, find_player_props). Also mentions API key requirements, rate limits, row caps per tier, and that an empty result is not an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!