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.

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