Skip to main content
Glama

Lumify Sports Intelligence

by ai.lumify

get_intelligence

Read-onlyIdempotent

Get predictive bet intelligence for an event: vig-stripped probability, fair_price, Price overlay, main-line ev (Beta), and forecasts[] — forecasted wagers from the model (same objects as list_forecasts): player props plus tennis moneyline/spreads/totals. bets[] is live for MLB, tennis, soccer (MLS + big-five), NFL, and NCAAF. forecasts[] covers MLB, NFL, NCAAF, NBA, NCAAB, NHL, and tennis and can populate when available is false. Fair-price + line-shopping on bets[] today (edge/tier null; has_recommend false). bookmaker is ignored. Match-level tokens (OVER, UNDER, ML_DRAW) have null player/team attribution. Free only when available is false and forecasts is empty. Field catalog: https://lumify.ai/docs/reference#event-intelligence

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYesEvent id, from list_events, query_events, or search results.
bookmakerNoIgnored. Intelligence always reports the book the assessment was priced against. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, hardrock, betonline.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
betsNo
sportNoSport slug for this event.
leagueNoLeague slug for this event, if any.
matchupNoNot returned. Use get_stats for pitcher/lineup Data.
playersNoHome/away (or p1/p2) participant identification, keyed by role: {role: {name, player_id, team_id}}.
event_idNoLumify event ID this intelligence describes.
availableNoFalse when no predictive bets[] have been computed for this event yet. forecasts[] can still populate on MLB/NFL/NCAAF/NBA/NCAAB/NHL. Free only when available is false and forecasts is empty.
forecastsNoForecasted wagers for this event (same object as list_forecasts) — a model prediction, not a beat-the-market claim. Player-prop rows on team sports; tennis main-line via bet_type ML_P1/ML_P2 (moneyline), SPREAD_P1/SPREAD_P2 (game handicap), OVER/UNDER (total games). selected marks the top-conviction rows on the daily slate; the rest of the event catalog is included with selected:false. Read p_hit as P(the picked outcome hits). How + field catalog: https://lumify.ai/docs/forecasts
rationaleNoEvent-level factual pre-game matchup chips (injuries, recent form, lineup/availability news — sport-shaped). Written before kickoff; the request path only reads the stored row.
odds_sourceNoBookmaker bets[].market prices were sourced from. For probability-model sports this is the book the assessment was priced against, not a bookmaker overlay; per-bet market.book is authoritative if they ever differ.
has_recommendNoTrue when at least one bet meets the recommendation threshold; null when intelligence has not been computed. False while Edge is not published (current MLB/soccer/tennis Stage 1) — a recommendation requires a non-null tier derived from edge.
match_overviewNoNatural-language pre-game matchup preview — form, context, what to watch. Written before kickoff by a Search-backed overlay on every event sport (MLB, NFL, NCAAF, NBA, NCAAB, NHL, soccer, tennis); sport-shaped queries. The request path only reads the stored row. Null when the pre-kickoff job has not run or the fixture was not eligible.
intelligence_updated_atNoISO-8601 UTC timestamp of the most recent change anywhere in this payload (max of per-bet computed_at). Use per-bet computed_at to reason about a specific bet.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description goes well beyond this by revealing important behavioral quirks: bookmaker is ignored, edge/tier are null and has_recommend is false, match-level tokens have null attribution, and free access only applies when available is false and forecasts is empty. There is no contradiction with annotations.

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 dense and longer than average, but nearly every clause carries operational information: sports availability, free-tier conditions, token attribution, and the field reference link. It is not perfectly front-loaded, but the main purpose appears first and no sentence is filler.

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 tool's complexity, the output schema handles return structure, and the description covers the key invocation concerns: parameter provenance, ignored parameters, live coverage by sport, forecast coverage, and free-access restrictions. A field catalog link is provided for deeper reference. Nothing necessary for correct selection or invocation is missing.

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 description coverage is 100%, so the input schema already documents both event_id and bookmaker. The description adds no new parameter-level meaning beyond confirming bookmaker is ignored, which the schema also states. This is the baseline case where the schema does the heavy lifting and the description adds little parameter value.

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: 'Get predictive bet intelligence for an event', then enumerates the distinct payload fields (fair_price, forecasts[], bets[]) that make this tool unique. It also differentiates forecasts[] as 'same objects as list_forecasts', helping an agent separate it from sibling forecast tools.

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 practical usage context: which sports have live bets[], which sports forecasts[] cover, and the condition under which the tool is free via the API. It does not explicitly say 'use this instead of get_odds or list_forecasts', but the coverage lists and the mention of list_forecasts give clear contextual guidance.

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