Skip to main content
Glama

Lumify Sports Intelligence

by ai.lumify

get_injuries

Read-onlyIdempotent

Beta. Get late-breaking player injury and availability status for an event (out / doubtful / questionable / probable / day_to_day / ir / suspended / available), with previous_status, body_part, note, source_url, and severity (info / material / critical). Beta coverage: NFL and MLB (more sports rolling out). NFL monitoring starts ~4.5 days before kickoff (Wednesday/Thursday practice reports); MLB stays on a 48-hour window. Returns available:false with no charge until the injury monitor has written a first structured report. Checks run on cadence, on a significant main-market odds move, and at a guaranteed pre-kickoff checkpoint. Subscribe to webhook event_type=injury for material/critical changes. No in-game feed. Use exclude_status to drop noisy long-standing designations (e.g. ir) from the response — does not affect available or credit cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYesEvent id, from list_events, query_events, or search results.
exclude_statusNoComma-separated statuses to drop, e.g. "ir" to hide injured-reserve/long-term-IL rows (long-standing roster designations, not late-breaking news). Valid values: out, doubtful, questionable, probable, day_to_day, ir, suspended, available.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idNo
injuriesNoPer-player rows: player, player_id, team, team_id, status, previous_status, body_part, note, source_url, severity, last_changed_at. team/team_id prefer the player's current roster team when that team is a participant in this event.
availableNo
confirmed_atNo
next_check_atNo
last_checked_atNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / properties / injuries / description
      Previous value: -"Per-player rows: player, player_id, team, team_id, status, previous_status, body_part, note, source_url, severity, last_changed_at."New value: +"Per-player rows: player, player_id, team, team_id, status, previous_status, body_part, note, source_url, severity, last_changed_at. team/team_id prefer the player's current roster team when that team is a participant in this event."
  2. Changed1 schema field changed
    • addedInput schema / properties / exclude_status
      Added value: +{
+  "description": "Comma-separated statuses to drop, e.g. \"ir\" to hide injured-reserve/long-term-IL rows (long-standing roster designations, not late-breaking news). Valid values: out, doubtful, questionable, probable, day_to_day, ir, suspended, available.",
+  "type": "string"
+}
  3. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with annotations already marking readOnly/openWorld/idempotent, the description adds substantial behavioral detail: beta status, league coverage windows, the 'no charge' behavior before a first structured report, polling triggers, the absence of an in-game feed, and the non-effect of exclude_status on availability or credit. This goes well beyond the annotations.

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 dense but every sentence contributes operational knowledge an agent needs. It is front-loaded with the primary purpose and then efficiently covers coverage, timing, webhooks, and parameter behavior without redundancy.

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?

The description is exceptionally complete for a complex data tool: it covers availability semantics, timing, charge behavior, update triggers, webhook subscription, limitations, and parameter nuances. The presence of an output schema means return-value documentation is handled elsewhere, so no essential calling context is missing.

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?

Schema coverage is 100%, so the schema already documents both parameters. The description adds extra semantic value for exclude_status, explaining its purpose as dropping noisy long-standing designations and clarifying that it does not affect availability or credit, which is not evident from the schema alone.

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 clearly states the tool's function: 'Get late-breaking player injury and availability status for an event,' naming a specific verb, resource, and scope. It also enumerates the specific statuses and fields returned, and it is clearly distinct from sibling tools like get_event or get_player because it targets injury intelligence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong contextual guidance: Beta coverage is limited to NFL and MLB, with specific monitoring windows and cadence. It also explains when the tool may return 'available:false' and directs users to webhooks for material/critical changes, though it does not explicitly contrast with alternative tools since no direct sibling exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Lumify Sports Intelligence 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 maps to a distinct data resource or operation: events, live scores, odds, odds history, splits, stats, intelligence, player props, players, teams, sports, and seasons. Pairs like list_events vs query_events and get_event vs get_live_score are clearly differentiated by structured vs natural-language filtering and lightweight vs full detail.

Naming Consistency5/5

Tool names consistently follow a verb_noun snake_case pattern: get_*, list_*, search_*, query_*, batch_get_*, and estimate_cost. The naming conventions make the resource family immediately obvious, and deviations like batch_get_events are still predictable variants.

Tool Count4/5

19 tools is on the higher side, but each tool covers a specific sports-intelligence data product or workflow with little redundancy. The count feels intentional for the breadth of the domain rather than bloated.

Completeness4/5

The surface covers event discovery and retrieval, live scores, odds and line movement, splits, statistics, player props, intelligence, player/team/sport/season lookups, batch fetching, and cost estimation. Minor gaps like team standings or full rosters are not exposed, but core agent workflows are well supported.

Resources