The Flash Props API server provides agent-native sports betting player-props data across a wide range of sports (MLB, NFL, NBA, NHL, NCAA, soccer, tennis, and esports like CS2, Valorant, and Dota 2), accessible via REST API or MCP interface for AI agents.
Key capabilities:
List supported sports (list_sports): Retrieve all supported sports and check which your API key tier grants access to.
List today's games (list_games): Get today's games with available player props for a given sport, with live games shown first.
Get props for a specific game (get_game_props): Fetch detailed player props for a single game by event ID, with optional filtering by stat (e.g., points, rebounds, strikeouts).
Scan market-wide props (scan_props): Broad scan of all player props across every game today for a sport, optionally filtered by a single stat and limited by row count (up to your tier's cap).
Find a game by team names (find_game): Resolve a matchup to an event ID using home/away team names or abbreviations, supporting partial and case-insensitive matching.
Access & billing: Token-based authentication with tiered access (Free, Starter, Pro, Enterprise) that determines request volume, scan size, and sport breadth, with self-service billing via Stripe.
Provides access to MLB player props, including pre-game and live odds, with tools to list games, retrieve props for a game, and scan props across the slate.
Provides access to NBA player props, including pre-game and live odds, with tools to list games, retrieve props for a game, and scan props across the slate.
Provides access to NHL player props, including pre-game and live odds, with tools to list games, retrieve props for a game, and scan props across the slate.
Flash Props API is a player-props API and MCP server by Flash AI Solutions for posted lines, Flash projections, evidence, context, and line movement across sports and esports.
This repository is the public connector and metadata surface for the hosted Flash Props API and MCP service. There is no proprietary Flash Props backend server to install from this repository. Point your client at the hosted endpoint and authenticate with a Flash Props API key for board data.
Website: https://api.flashodds.live/
Documentation: https://api.flashodds.live/docs
MCP endpoint: https://api.flashodds.live/mcp
Free API key: https://api.flashodds.live/billing/free
Publisher: https://www.flashaisolutions.org
Related MCP server: Sports Hub MCP Server
Streamable HTTP endpoint:
https://api.flashodds.live/mcpSend your API key in the Authorization header:
Authorization: Bearer <your_api_key>Anonymous access works for capability discovery (list_sports, get_market_metadata) so a client can inspect current coverage on first run. Retrieving board data requires at least a free key. Get one at https://api.flashodds.live/.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"flash-props": {
"type": "streamable-http",
"url": "https://api.flashodds.live/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
}
}
}Tool | What it returns | Access |
| Every sport with live status + projection/context capability | Anonymous |
| Market labels, families, scope, and projectability | Anonymous |
| Today's games with props for a sport | Free+ |
| All player props for one game | Free+ |
| Market-wide prop scan across the slate | Free+; row cap by tier |
| Resolve team names to an event id | Free+ |
| Every active prop for one player | Free+ |
| Season baselines, recent form, and deep context | Free/Starter basic; Pro deep |
| Book line, Flash line, gap, form, confidence, splits, movement | Free teaser; Starter basic; Pro full |
| Chronological line/odds history for a prop | Starter limited; Pro full |
| Biggest line movers in a window | Starter limited; Pro full |
| Ranked boards for gap, form, and sample strength | Free top 3; Starter top 10; Pro full |
REST and MCP share the same entitlement shaping, so a key sees the same product tier regardless of transport.
Do not hard-code a list of sports with Flash projections. Coverage is resolved from the server's registered model providers and can vary by sport + market.
Use list_sports to inspect projectionCapability, effectiveProjection, and contextCapability, then use get_market_metadata to determine whether a specific market is modeled. A partially modeled sport can legitimately expose Flash projections for one stat while keeping another stat posted-lines-only.
Missing analysis is reported explicitly. Flash Props does not fabricate a projection to fill an unsupported market.
Free: 250 requests/day, 25-row scans, evidence teaser, basic player context, top-3 leaders
Starter: 10k requests/day, 100-row scans, basic evidence, limited history/movement, top-10 leaders
Pro: 100k requests/day, 500-row scans, full evidence/context/history/movement/leaders
Enterprise: custom limits
See current pricing and the REST reference at https://api.flashodds.live/.
Data is informational only. Flash Props is not a sportsbook and is not affiliated with any league, team, player, sportsbook, or DFS operator.
API + pricing: https://api.flashodds.live/
REST reference: https://api.flashodds.live/docs
Built by Flash AI Solutions
Resolve a matchup description (home and away team names) to an event id you can pass to get_game_props. Use this when you know the teams but not the event id. Returns { eventId } on success, or an error if no matching game is found for today's slate. Team names are matched case-insensitively and support partial names (e.g. "Yankees", "New York Yankees", "NYY" all work for MLB). If no game is found, the matchup may not be on today's board or the sport may be out of season.
| Name | Required | Description | Default |
|---|---|---|---|
| away | Yes | Away team name or abbreviation, e.g. "Red Sox", "GSW", "Buffalo Bills" | |
| home | Yes | Home team name or abbreviation, e.g. "Yankees", "LAL", "Kansas City Chiefs" | |
| sport | No | Sport id, e.g. mlb, nba, nfl. Defaults to the in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses case-insensitive matching, partial name support, and that it only searches today's slate. It also states the return format ({ eventId }) and error handling. However, it does not mention whether multiple matches are possible or how they are handled.
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 concise and front-loaded with the core purpose in the first sentence. Every subsequent sentence provides useful context without redundancy. 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?
Despite no output schema, the description adequately explains the return format ({ eventId } or error). It covers matching flexibility, error conditions, and limitations (today's slate only). This is sufficient for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds value by explaining matching behavior (partial names, case-insensitive), but does not add new parameter-specific details beyond what the schema provides, so 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 clearly states the tool resolves a matchup description to an event ID for use with get_game_props. It explicitly distinguishes this tool from siblings by mentioning the downstream use case and the type of input (team names vs event IDs).
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 teams but not the event id,' providing clear when-to-use guidance. It also explains what happens if no match is found (not on today's board or out of season), but does not explicitly mention alternative tools like list_games for other lookup strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get player props for one game by event id (from list_games; ids are prefixed ud- or bv-).
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Sport id. Defaults to the in-season sport. | |
| stats | No | Comma-separated stat filter, e.g. points,rebounds | |
| eventId | Yes | Event id, e.g. bv-26839935 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only mentions the tool retrieves props but omits details about return format, read-only nature, or any side effects. The event ID format hint adds minimal transparency.
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?
A single, well-structured sentence delivers the core information without redundancy. Every word adds value, and the most critical information is 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?
The tool lacks an output schema, and the description gives no hint about the return structure or field details. For a tool that outputs props, this is a notable gap. It is minimally complete for a simple get operation but insufficient for confident use.
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 clear descriptions for all three parameters. The description adds no additional parameter meaning beyond noting the eventId prefix, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves player props for a single game using an event ID. It specifies the source of IDs (list_games) and the prefix format, distinguishing it from siblings like 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?
The description implies using list_games first to obtain an event ID with the correct prefix, providing clear context. However, it does not explicitly state when not to use this tool or mention 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.
List today's games with player props for a sport (nba, mlb, nfl, nhl, ncaab, ncaaf, soccer). Live games first.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Sport id, e.g. nba or mlb. Defaults to the in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds behavioral detail: 'Live games first' (ordering) and 'with player props' (inclusion of props in response). No contradictions, but could mention rate limits or pagination.
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 with no fluff. First sentence states purpose and scope; second adds ordering and sport list. Highly efficient and 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?
Given the tool's simplicity (1 optional param, no output schema), the description covers purpose, supported sports, default behavior, and ordering. Sibling tools are distinct, and no additional information is needed for a list operation.
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% for the single parameter 'sport'. The description adds default behavior ('Defaults to the in-season sport'), which is not in the schema description. This enhances 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 states 'List today's games with player props for a sport', clearly identifying the verb (List), resource (today's games), and scope (with player props, specific sports). It distinguishes from siblings like find_game (searches a specific game) and get_game_props (retrieves props for a game).
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 implies usage for getting a list of today's games with props, mentioning supported sports, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No direct reference to siblings or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported sports and whether your API key tier can access each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns accessibility per API key tier, indicating authorization-based filtering. No mention of side effects or destruction, but none expected for a read-only list operation.
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?
Single sentence, front-loaded with verb and resource, no extraneous information.
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 parameterless tool with no output schema, the description is adequate. It explains what the tool retrieves and the access information. However, it could hint at the output format (e.g., list of sport names with boolean flag).
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, so baseline is 4. The description adds meaning beyond the empty schema by specifying that the output includes sports and their accessibility by API key tier.
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 action (list), the resource (supported sports), and additional context (access per API key tier). It distinguishes from sibling tools like list_games and find_game.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool over alternatives like list_games or get_game_props. Usage is implied by the resource (sports).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market-wide scan: all player props across today's games for a sport, flattened into rows. Optionally filter by a single stat.
| Name | Required | Description | Default |
|---|---|---|---|
| stat | No | Filter to one stat, e.g. strikeouts | |
| limit | No | Max rows (capped by your tier) | |
| sport | No | Sport id. Defaults to the in-season sport. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions flattening and optional filter, but lacks details on side effects, auth, rate limits, or return format beyond 'rows'. Adequate but not comprehensive.
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 efficient sentences. Front-loaded with key purpose, no unnecessary 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?
For a simple scan tool with 3 optional params and no output schema, description covers main behavior (all props today, flattening, optional filter). Missing explicit mention of default sport but handled in schema. Reasonably 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 coverage is 100% with descriptions for all 3 parameters. Description adds minimal value beyond schema (e.g., 'optionally filter by a single stat' matches stat param). Baseline 3 applies.
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 it scans all player props across today's games for a sport and flattens them, with optional stat filter. Differentiates from siblings like get_game_props which targets a specific game.
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?
Implied usage through wording 'market-wide scan' and optional filter, but no explicit guidance on when to use versus alternatives (e.g., get_game_props) or when not to use.
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"New value: +"Away team name or abbreviation, e.g. \"Red Sox\", \"GSW\", \"Buffalo Bills\""Input schema / properties / home / descriptionPrevious value: -"Home team name"New value: +"Home team name or abbreviation, e.g. \"Yankees\", \"LAL\", \"Kansas City Chiefs\""Input schema / properties / sport / descriptionPrevious value: -"Sport id. Defaults to the in-season sport."New value: +"Sport id, e.g. mlb, nba, nfl. Defaults to the in-season sport."v1.0.0find_gameget_game_propslist_gameslist_sportsscan_propsEach tool has a clearly distinct purpose: resolving team names to event IDs, retrieving props for a specific game, listing games for a sport, listing supported sports, and scanning all props across games. There is no overlap.
All tool names follow a consistent verb_noun pattern using lowercase with underscores: find_game, get_game_props, list_games, list_sports, scan_props. This pattern is uniform and predictable.
With 5 tools covering the essential operations for a sports props API (listing sports, listing games, resolving matchups, retrieving individual game props, and scanning all props), the count is well-scoped and each tool earns its place.
The tool set covers the full lifecycle of accessing player props: discovering available sports, listing games, resolving matchups, retrieving props for a specific game, and performing a market-wide scan. No obvious gaps are present for a read-only API.
Live odds, cross-book +EV and graded player-prop results across 27 books. Hosted endpoint included.
The Odds API MCP — sportsbook odds across 70+ books, 30+ leagues
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iFan6oy/flash-props-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
