Skip to main content
Glama

Prop backtest

get_prop_backtest
Read-onlyIdempotent

Use to test an idea about player props without pulling every row: how often a kind of prop went over or under against what the market implied, across every finished game we hold prices for that fits your filters. Returns the hit rate, its 95% interval, the average implied and fair probabilities, and each season on its own. For example, shots on goal overs for players whose team was the underdog at home. One result per player per game at the median closing line. It describes the past and recommends nothing. For one player game by game use get_prop_history. Costs 25 credits.

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": {
      "market": "<market>"
    },
    "name": "get_prop_backtest"
  }
}

Input Schema

NameRequiredDescriptionDefault
sideNoover (default) or under. Yes/no markets are graded on the yes price: over only.
teamNoThe player's team, e.g. TOR.
marketYesThe market, e.g. player_shots_on_goal.
to_dateNoLast game date, YYYY-MM-DD. Default all held.
fair_maxNoHighest fair probability of this side to include, 0 to 1.
fair_minNoLowest fair probability of this side to include, 0 to 1.
line_maxNoHighest median closing line to include.
line_minNoLowest median closing line to include.
opponentNoThe team he played.
from_dateNoFirst game date, YYYY-MM-DD. Default all held.
home_awayNoWhether his team was at home.
player_idNoOne player's id (e.g. 8478402, from search_players).
team_roleNoWhether his team was favored, by the books' closing moneylines.

Output Schema

NameRequiredDescriptionDefault
hitsYes
noteNo
sideYes
toolNo
gamesYes
labelYes
marketYes
methodYes
missesYes
pushesYes
cautionYes
creditsNo
filtersYes
playersYes
resultsYes
avg_lineYes
hit_rateYes
no_priceYes
avg_booksYes
by_seasonYes
no_resultYes
avg_actualYes
avg_fair_probYes
estimate_onlyNo
avg_implied_probYes
hit_rate_minus_fairYes
hit_rate_interval_95Yes
hit_rate_minus_impliedYes
market_inside_intervalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior4/5

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

While annotations only cover safety hints, the description provides crucial behavioral details, such as returning specific metrics (hit rate, 95% interval, fair probabilities) and a critical operational detail (costs 25 credits).

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 definition is perfectly structured: purpose -> output details -> example -> limitations -> alternative tool. It contains zero unnecessary jargon or 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 complexity of a 13-parameter statistical backtesting tool, the description is exceptionally complete. It addresses limitations, provides context, and links it to the broader tool suite.

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

Parameters4/5

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

Though the schema is comprehensive, the description adds valuable context by providing a concrete usage example (shots on goal overs for underdogs at home), helping the agent understand the practical combination of parameters.

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 defines the tool's purpose: testing prop ideas by calculating hit rates and market comparisons across filtered games. It immediately differentiates itself from granular history retrieval tools.

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?

It provides explicit guidance on when and how to use the tool (e.g., testing aggregated patterns), and explicitly directs users to get_prop_history when they need game-by-game data.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.