Skip to main content
Glama

Lumify Sports Intelligence

by ai.lumify

search_players

Read-onlyIdempotent

Search players by name, sport, country, ranking, or active status, paginated by id (after_id). Returns the same identity object on every sport (null means unknown, not wrong sport). Tennis standings nest under rankings.{singles, points}; rankings is null on every other sport. Use get_player for full detail on one id, or get_player_events for a player's schedule/results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoName search (partial match).
limitNoMax players to return per page.
sportNoSport slug, e.g. tennis, nba.
activeNoFilter by active status.
rankedNoIf true, only tennis players with an ATP/WTA singles ranking (rankings.singles).
countryNoISO 3166-1 alpha-3 country code, e.g. USA.
after_idNoCursor: last player id from the previous page's next_after_id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
has_moreNo
next_after_idNoPass as after_id to fetch the next page; null on the last page.

Schema Changelog

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

  1. Changed20 schema fields changed
    • changedInput schema / properties / ranked / description
      Previous value: -"If true, only players with a tennis ranking."New value: +"If true, only tennis players with an ATP/WTA singles ranking (rankings.singles)."
    • changedOutput schema / $defs / Player / properties / birthdate / description
      Previous value: -"YYYY-MM-DD."New value: +"YYYY-MM-DD date of birth."
    • addedOutput schema / $defs / Player / properties / country_code / description
      Added value: +"ISO 3166-1 alpha-3 country code."
    • addedOutput schema / $defs / Player / properties / current_team_id / description
      Added value: +"Lumify team ID when the player is on a club roster. Null for tennis."
    • addedOutput schema / $defs / Player / properties / current_team_name / description
      Added value: +"Current team display name. Null for tennis."
    • addedOutput schema / $defs / Player / properties / first_name
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / full_name / description
      Added value: +"Display name."
    • addedOutput schema / $defs / Player / properties / handedness
      Added value: +{
+  "description": "left | right | switch. Meaning is sport-specific (bats for MLB, shoots for NHL, playing hand for tennis). Null when unknown.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / height_cm
      Added value: +{
+  "description": "Height in centimetres. Null when not ingested.",
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / id / description
      Added value: +"Lumify player ID."
    • addedOutput schema / $defs / Player / properties / image_url
      Added value: +{
+  "description": "Lumify media URL for the player headshot (https://lumify.ai/media/players/{sport}/{id}.{ext}). Null until the sport's headshot/enrichment job. Never a vendor CDN.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / is_active / description
      Added value: +"False when deactivated or retired."
    • addedOutput schema / $defs / Player / properties / last_name
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / position / description
      Added value: +"Roster position abbreviation when the sport has one (e.g. C, P, SS for MLB; QB, WR for NFL). Null for tennis and when not yet ingested."
    • addedOutput schema / $defs / Player / properties / rankings
      Added value: +{
+  "description": "Sport ranking block. Tennis: {singles, points} from ATP/WTA standings. Null for every other sport. Tennis /stats also exposes ranking / ranking_points on the tennis player block.",
+  "properties": {
+    "points": {
+      "description": "ATP/WTA ranking points. Tennis only.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "singles": {
+      "description": "ATP/WTA singles ranking. Tennis only.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / retired_at
      Added value: +{
+  "description": "YYYY-MM-DD retirement date when known.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / Player / properties / slug / description
      Added value: +"URL-safe unique slug."
    • addedOutput schema / $defs / Player / properties / sport / description
      Added value: +"Sport slug, e.g. mlb, tennis, nfl."
    • removedOutput schema / $defs / Player / properties / tennis_ranking
      Removed value: -{
-  "type": [
-    "integer",
-    "null"
-  ]
-}
    • addedOutput schema / $defs / Player / properties / weight_kg
      Added value: +{
+  "description": "Weight in kilograms. Null when not ingested.",
+  "type": [
+    "number",
+    "null"
+  ]
+}
  2. Changed6 schema fields changed
    • changedOutput schema / $defs / Player / properties / birthdate / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / $defs / Player / properties / country_code / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / $defs / Player / properties / current_team_id / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
    • changedOutput schema / $defs / Player / properties / current_team_name / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / $defs / Player / properties / position / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / $defs / Player / properties / tennis_ranking / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
  3. Changed4 schema fields changed
    • changedInput schema / properties / after_id / description
      Previous value: -"Cursor: last player id from previous page."New value: +"Cursor: last player id from the previous page's next_after_id."
    • addedInput schema / properties / limit / description
      Added value: +"Max players to return per page."
    • addedInput schema / properties / sport / description
      Added value: +"Sport slug, e.g. tennis, nba."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$defs": {
+    "Player": {
+      "properties": {
+        "birthdate": {
+          "description": "YYYY-MM-DD.",
+          "type": "string"
+        },
+        "country_code": {
+          "type": "string"
+        },
+        "current_team_id": {
+          "type": "integer"
+        },
+        "current_team_name": {
+          "type": "string"
+        },
+        "full_name": {
+          "type": "string"
+        },
+        "id": {
+          "type": "integer"
+        },
+        "is_active": {
+          "type": "boolean"
+        },
+        "position": {
+          "type": "string"
+        },
+        "slug": {
+          "type": "string"
+        },
+        "sport": {
+          "type": "string"
+        },
+        "tennis_ranking": {
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "properties": {
+    "data": {
+      "items": {
+        "$ref": "#/$defs/Player"
+      },
+      "type": "array"
+    },
+    "has_more": {
+      "type": "boolean"
+    },
+    "next_after_id": {
+      "description": "Pass as after_id to fetch the next page; null on the last page.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as readOnly, openWorld, idempotent, and non-destructive, so the bar is lower. The description adds valuable behavioral context: the identity object is the same across sports with null meaning unknown, not wrong sport, and that rankings only nests under tennis while being null elsewhere. This goes beyond the structured 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 three sentences with no filler. The main action and filters are front-loaded in the first sentence, behavior notes in the second, and routing to alternatives in the third. Every sentence earns its place.

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?

Given the output schema exists and annotations cover the safety profile, the description covers the remaining important context: null/unknown semantics, sport-specific rankings shape, and the relationship to sibling tools. Nothing critical is missing for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces the role of parameters like sport, country, ranking, and after_id, and clarifies pagination via id, but it does not significantly deepen the semantics beyond what the schema already states.

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: 'Search players by name, sport, country, ranking, or active status, paginated by id (after_id).' It clearly identifies the action, the target, and the available filters, and distinguishes itself from get_player and get_player_events by naming them as alternatives.

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 alternatives: 'Use get_player for full detail on one id, or get_player_events for a player's schedule/results.' It also provides pagination context with after_id and next_after_id, making the usage conditions clear.

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