Skip to main content
Glama
Odds-API MCP Server

Odds-API MCP Server

Official

Closing lines

get_closing_lines
Read-onlyIdempotent

Fetch closing odds for settled events across up to 10 leagues and a 366-day range to calculate closing line value and run model backtests; page results with limit and skip.

Instructions

Closing odds for every settled event across up to 10 leagues in one request, for closing line value (CLV) and model backtests. Date range up to 366 days, so a season fits in one sweep; at most 100 events per response, page with limit and skip. Paid plans. Each event is shaped like get_historical_odds.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sport": "<sport>",
      "leagues": "<leagues>",
      "from": "<from>",
      "to": "<to>",
      "markets": "<markets>",
      "bookmakers": "<bookmakers>"
    },
    "name": "get_closing_lines"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesEnd date in RFC3339 format, at most 366 days after from
fromYesStart date in RFC3339 format
skipNoEvents to skip, for pagination
limitNoEvents per response (max 100)
sportYesSport slug from get_sports (e.g. 'football', 'basketball', 'tennis')
leaguesYesComma-separated league slugs (max 10)
marketsYesComma-separated market names (e.g. 'ML')
bookmakersYesComma-separated bookmaker names (max 30)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.3

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful non-annotation context: settled events only, paid-plan requirement, 366-day date range, 100-event response cap, and pagination via limit/skip.

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: purpose first, then operational limits, then plan constraint and output-shape reference. Every sentence contributes useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter read-only data endpoint with no output schema, the description covers scope, key limits, pagination, billing constraints, and output shape reference. It stops short of explaining market/bookmaker selection nuance, but the schema already documents those parameters.

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 parameter definitions already carry most semantic detail. The description reinforces constraints like the 10-league maximum, 366-day range, and pagination limit, but adds little beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource and scope: closing odds for every settled event across up to 10 leagues in one request. It implies the CLV/backtest use case and references get_historical_odds for output shape, but it does not explicitly distinguish when to use this over that sibling.

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

Usage Guidelines3/5

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

It gives implied usage context through 'for closing line value (CLV) and model backtests' and mentions paid plans, date range limits, and pagination. However, it does not explicitly state when not to use it or name alternatives such as get_historical_odds for non-closing-line use cases.

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