Skip to main content
Glama

flash-props-api

by io.github.iFan6oy

List today's games

list_games

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sportNoSport 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.

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All flash-props-api toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources