Skip to main content
Glama

Lumify Sports Intelligence

by ai.lumify

get_odds_history

Read-onlyIdempotent

Get line-movement history for an event: a list of past odds snapshots (movements), each with its own timestamp, up to limit entries. bookmaker defaults to pinnacle. Use get_odds instead if you only need the current line.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax line-movement entries to return. Default 50.
event_idYesEvent id, from list_events, query_events, or search results.
bookmakerNoBookmaker slug. Defaults to pinnacle. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, westgate, wynn, south_point, stations, hardrock, betonline, betr, betrivers, lowvig, all, or a comma-separated list.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalNo
event_idNo
movementsNoOdds snapshots over time; each entry carries its own timestamp.

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / bookmaker / description
      Previous value: -"Bookmaker slug. Defaults to pinnacle. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, westgate, wynn, south_point, stations, hardrock, betonline, betr, betrivers, all, or a comma-separated list."New value: +"Bookmaker slug. Defaults to pinnacle. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, westgate, wynn, south_point, stations, hardrock, betonline, betr, betrivers, lowvig, all, or a comma-separated list."
  2. Changed1 schema field changed
    • changedInput schema / properties / bookmaker / description
      Previous value: -"Bookmaker slug. Defaults to pinnacle. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, hardrock, betonline, all, or a comma-separated list."New value: +"Bookmaker slug. Defaults to pinnacle. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, westgate, wynn, south_point, stations, hardrock, betonline, betr, betrivers, all, or a comma-separated list."
  3. Changed1 schema field changed
    • changedInput schema / properties / bookmaker / description
      Previous value: -"Bookmaker slug; defaults to pinnacle."New value: +"Bookmaker slug. Defaults to pinnacle. Valid: pinnacle, fanduel, draftkings, betmgm, caesars, bet365, circa, hardrock, betonline, all, or a comma-separated list."
  4. Changed4 schema fields changed
    • addedInput schema / properties / bookmaker / description
      Added value: +"Bookmaker slug; defaults to pinnacle."
    • addedInput schema / properties / event_id / description
      Added value: +"Event id, from list_events, query_events, or search results."
    • addedInput schema / properties / limit / description
      Added value: +"Max line-movement entries to return. Default 50."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "event_id": {
+      "type": "integer"
+    },
+    "movements": {
+      "description": "Odds snapshots over time; each entry carries its own timestamp.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
  5. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish this as a safe, read-only, idempotent operation. The description adds behavioral context by specifying that it returns a list of past snapshots, each with a timestamp, capped by the limit parameter, and noting the default bookmaker. This is useful context 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 compact and front-loaded: it states the core purpose first, then important defaults, then the alternative tool. Every sentence earns its place and there is no redundant information.

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?

With a full input schema, explicit annotations, and an output schema, the description provides enough context for correct invocation. It covers the operation, the result shape, the limit behavior, the default bookmaker, and when to use a sibling tool instead.

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 schema fully documents event_id, limit, and bookmaker. The description reinforces the meaning of limit ('up to limit entries') and mentions the bookmaker default, but it does not add substantial meaning beyond the schema.

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: retrieving line-movement history for an event, i.e. past odds snapshots with timestamps. It explicitly distinguishes itself from get_odds, which returns only the current line, making the tool's purpose unambiguous.

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 names the alternative get_odds and gives the condition for choosing it instead: 'Use get_odds instead if you only need the current line.' This gives the agent clear routing 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