Skip to main content
Glama

flash-props-api

List sports with live status + capability

list_sports

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

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 ('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.

Usage Guidelines5/5

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.

Try in Browser

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.