good-sport
Server Details
Sports-analytics research assistant that grades its own model and reports the losses. $9.99/mo. https://good-sport.ai?src=glama
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 12 of 12 tools scored. Lowest: 3.8/5.
Most tools have distinct purposes with detailed descriptions. However, 'live_props' and 'prop_slate' are very similar, both showing props with model edge, which could cause confusion. Additionally, 'predictions' also includes props, adding overlap. Minor ambiguity exists.
Tool names use a mix of verb+noun, noun+noun, and adjective+noun patterns. While each name is descriptive, there is no consistent naming convention across the set (e.g., analyze_prop vs. prop_slate vs. live_props). This inconsistency could make it harder for an agent to infer tool purpose from name alone.
With 12 tools covering a diverse range of sports prediction and analysis tasks (model predictions, prop analysis, parlay building, performance evaluation, data quality, etc.), the count is well-scoped. Each tool serves a clear purpose, and there is no bloat or redundancy that makes the set unwieldy.
The tool set covers the core functionality one would expect from a sports prediction server: model predictions for games and props, edge analysis, parlay construction, performance tracking, data quality monitoring, and market movement detection. The inclusion of a health check and draft advisor adds value. However, the set is heavily focused on Underdog/PrizePicks and Kalshi, and lacks coverage for other sportsbook types (e.g., traditional spread betting tools). Minor gaps exist.
Available Tools
12 toolsanalyze_propSingle-prop deep diveARead-onlyInspect
Single-prop deep dive: model probability, prediction interval, edge.
Pulls the model's view of one prop (player x market x line) plus the line across books, and auto-flags outsized edges for manual verification.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | optional — restrict the cross-book view to one book. | |
| line | Yes | the prop line (e.g. 5.5). | |
| market | Yes | our prop_type model name (e.g. 'pitcher_strikeouts', 'nhl_shots_on_goal', 'tennis_aces'). | |
| player | Yes | player name (case-insensitive). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms a read-only pull of the model's view. It additionally discloses auto-flagging of outsized edges, which is useful behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first provides a quick summary of key outputs, the second elaborates on inputs and the edge flagging behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with an output schema (indicated), the description covers essential aspects: inputs, outputs (model probability, prediction interval, edge, line across books), and an added behavioral note (auto-flagging). Complete enough for the agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no further parameter details beyond what the schema already provides, so baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes a single prop (player x market x line) by providing model probability, prediction interval, edge, line across books, and flags outsized edges. It distinguishes from siblings like 'prop_slate' or 'predictions' by focusing on a single deep dive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The title 'Single-prop deep dive' and description imply it's for in-depth analysis of one prop, contrasting with tools handling multiple props. However, no explicit when-to-use or when-not-to-use compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_parlayOptimal parlay candidatesARead-onlyInspect
Build optimal parlay candidates from the latest persisted slate.
Reconstructs the legs from slate_prop_predictions (the most recent
slate run for book) and runs the parlay optimizer — it does NOT re-run
the models, so this is read-only. Enforces a same-game cap
(max_correlation) to limit correlated legs.
Longshot guard: legs are required to clear min_leg_prob (default 0.50)
— a pick'em leg should be more-likely-than-not. Without it the EV
optimizer happily stacks 9-13% longshots (a huge payout × a tiny
probability scores as "+EV") into lottery-ticket parlays that hit ~0.1%
of the time and lean entirely on the model's least-reliable tail
estimates. Lower it only to deliberately hunt longshots.
Underdog uses per-leg payout multipliers (combined payout = product of
legs). PrizePicks is priced by a FIXED table per entry size (2-pick=3x …
6-pick=25x); for book='prizepicks' the optimizer maximizes combined
probability and combined_payout is the fixed entry multiplier (per-leg
payout_multiplier is a sentinel, not a real price).
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | platform whose persisted legs to use ('underdog' default; 'prizepicks' for the fixed-payout board). | underdog |
| top_n | No | how many candidate parlays to return. | |
| n_legs | No | parlay size (default 3). | |
| min_edge | No | minimum per-leg model edge to include a leg. | |
| min_leg_prob | No | minimum per-leg model probability (default 0.50). | |
| max_correlation | No | max legs allowed from the same game (anti-correlation). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description significantly goes beyond annotations by disclosing that models are not re-run (read-only), enforcing same-game caps, explaining the longshot guard rationale, and detailing different payout behaviors per platform. No contradiction with annotations (readOnlyHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence summarizing purpose, followed by detailed context. It is reasonably concise but includes necessary explanations; could be slightly shorter without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema exists), the description covers the source, optimizer behavior, platform specifics, and parameter guards. Minor gaps: no mention of prerequisites (e.g., need a persisted slate) or error scenarios, but overall quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description enhances understanding by explaining the rationale for 'min_leg_prob' (longshot guard), the effect of 'max_correlation' (same-game cap), and how 'book' changes optimizer behavior. This adds meaningful context beyond parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Build optimal parlay candidates from the latest persisted slate', providing a specific verb and resource. It distinguishes itself from siblings like 'analyze_prop' and 'predictions' by focusing on parlay optimization, and details the process and platform differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (after a slate run, for parlay optimization) and gives context about platforms (Underdog vs PrizePicks) and the longshot guard. However, it does not explicitly exclude alternatives or provide direct comparisons to sibling tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clv_analysisClosing-line value analysisARead-onlyInspect
Closing-line-value analysis: did we beat the close, and does it pay?
CLV = implied(closing) - implied(bet); positive means the line moved toward our pick after we bet (we beat the close — the gold-standard sign of real edge, independent of whether the bet won). Over settled bets that have a closing line, returns conditional ROI/win-rate split by beat-close vs not.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | filter to one model key; omit for all. | |
| sport | No | 'mlb' / 'nhl' / 'tennis' (omit for all). | |
| market | No | 'game' (default) reads the game/NHL/tennis winner logs (American closing odds). 'props' reads slate_prop_predictions — per-leg prop CLV = closing_implied_prob - implied_prob, stamped at reconcile time by src/ml/clv.py::attach_props. Prop legs are unit-staked, so ROI = pnl / number of legs. | game |
| max_date | No | latest event/prediction date to include (YYYY-MM-DD). | |
| min_date | No | earliest event/prediction date to include (YYYY-MM-DD). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation, explaining that the tool computes CLV as implied(closing) - implied(bet), is independent of bet win/loss, and returns conditional ROI/win-rate split. It also notes it operates on settled bets with a closing line.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two paragraphs that front-load the purpose and provide formula details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and annotations provide readOnlyHint, the description covers the core behavior. It explains the analysis and return metrics, though it could mention handling of missing closing lines or market-specific nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description does not add additional meaning to the parameters beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines CLV analysis, explaining the formula and what it returns (conditional ROI/win-rate split by beat-close vs not). It distinguishes from sibling tools by focusing on closing-line value, a specific analytical metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like model_performance or smart_money. Usage is implied for CLV analysis, but no guidance is given for when not to use it or which sibling is more appropriate for other analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
data_qualityFeed health checksARead-onlyInspect
Feed-health monitor: current data-quality check results across the feeds.
Reads data_quality_checks (written by src/monitoring/data_quality.py after each slate capture and the daily tennis run). Takes the MOST RECENT result per (check_name, scope) within the lookback window, so it reflects current state rather than history. Check families: freshness.* (capture recency, fetch lag, last_update coverage), completeness.* (null rates, row/book volume vs baseline), accuracy.* (value ranges, two-sided vig, cross-book consensus), integrity.duplicate_rows, and tennis.* (serve-stat range + logical-consistency bounds).
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | lookback window for "current" results (default 48h — spans the hourly slate + daily tennis runs). | |
| limit | No | maximum rows to return (default 200). | |
| status | No | filter the returned list to one of 'ok', 'warn', 'fail'; omit to get the actionable subset (warn+fail) in `flagged`. | |
| check_prefix | No | scope to a family, e.g. 'freshness', 'accuracy', 'tennis', 'completeness', 'integrity' (matches check_name prefix). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by detailing the data source, the selection logic (most recent per check_name and scope), and listing check families. This provides rich behavioral context that helps the agent understand what the tool does and how results are aggregated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the tool's purpose. Every sentence adds meaningful information without redundancy, and it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (multiple check families, result logic) and the presence of an output schema and annotations, the description is complete. It explains the data source, time window, result selection, and families, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. However, the description adds value by explaining the check families (e.g., freshness, completeness), which directly aids in using the check_prefix parameter. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a feed-health monitor providing current data-quality check results. It specifies the verb 'reads' and resource 'data_quality_checks', and distinguishes from sibling tools by focusing on feed health, which is unique among the listed siblings like 'analyze_prop' or 'build_parlay'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool returns the most recent result per check, reflecting current state rather than history. It does not explicitly list when to use vs. alternatives, but the context is sufficient to infer its use for monitoring current feed health, not for historical analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
draft_advisorFantasy draft advisorARead-onlyInspect
Fantasy-football draft copilot: best available players by value over replacement, with tiers, positional need, and honest uncertainty.
Mid-draft usage: pass the names already taken (drafted) and your own
picks (my_roster); get back the best AVAILABLE players ranked by
points-above-replacement (PAR) for YOUR league shape, per-position tier
cliffs ("2 RBs left in tier 3"), and which starting slots you still
need. Pre-draft: call with no names for a cheat-sheet board.
Projections are a deliberately humble market blend (FantasyPros expert consensus rank mapped through 3-season positional points curves, nudged 30% by each player's prior-season scoring) — season-long calibration is unproven in year 1 and every row carries the market's own uncertainty (sd/best/worst) so you can see disagreement. This is fantasy roster research, not betting advice; kickers and team defenses are not modeled and should be drafted last on ordinary boards anyway.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max best-available rows (default 15). | |
| teams | No | league size (default 12). | |
| drafted | No | player names already off the board (any owner, best-effort fuzzy match; unmatched names are reported back, not ignored silently). | |
| scoring | No | 'standard' | 'half_ppr' | 'ppr' (aliases like 'full-PPR' accepted). Custom/exotic scoring: pick the nearest preset — the approximation is disclosed in the payload. | ppr |
| position | No | restrict best-available to one of QB/RB/WR/TE. | |
| my_roster | No | the subset of drafted players that are YOURS (also removed from the board; drives the needs report). | |
| superflex | No | True for superflex/2QB leagues (switches to the QB-expensive consensus board AND adds QB replacement demand). | |
| roster_slots | No | starting lineup + bench, e.g. {"QB":1,"RB":2,"WR":2, "TE":1,"FLEX":1,"BENCH":6} (the default). Include "SUPERFLEX":1 for superflex lineups. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and description adds honest disclosure about projection methodology (market blend, uncertainty metrics), limitations (unproven year 1 calibration), and that it's not betting advice. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, then usage modes, then methodology. Every sentence adds value, though slightly long. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (none required) and output schema exists, the description is fully complete: covers usage, limitations, data source, and uncertainty. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value beyond schema: explains fuzzy matching for drafted, the role of my_roster in needs report, alias handling for scoring, and an example for roster_slots. This greatly aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fantasy-football draft copilot' and explains it returns 'best available players by value over replacement, with tiers, positional need, and honest uncertainty.' It distinguishes from siblings like 'live_props' or 'prop_slate' by being a draft advisor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance for mid-draft (pass drafted names and roster) and pre-draft (call with no names) usage. Mentions what is not modeled (kickers, team defenses). Lacks explicit 'when not to use' but sibling names make context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kalshi_edgesKalshi contracts vs modelARead-onlyInspect
Actionable Kalshi contracts: model win probability vs contract price.
Reads the Kalshi h2h rows in mart_slate_with_edge — Kalshi contract prices (implied probability) joined to the model's game prediction via the Phase 1.2 reconciliation. Ranked by model edge.
Same honesty guards as prop_slate: only upcoming events are shown
(the mart retains settled Kalshi contracts, whose stale prices otherwise
top the list with huge phantom edges), and edges are capped at max_edge
(a >25pp edge vs a contract is almost always a settled/deep-longshot
artifact). A verify flag marks large remaining edges.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows returned. | |
| sport | No | 'mlb' / 'nhl' / 'tennis' (aliases accepted); omit for all. | |
| max_edge | No | edge cap — larger edges are usually settled/longshot artifacts, not bets. | |
| min_edge | No | minimum model edge (model_prob - contract_price) to include. | |
| include_started | No | include already-started events (default False = upcoming only). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: it reads from a specific mart, joins on contract prices, ranks by edge, applies honesty guards (upcoming only, edge cap), and mentions a verify flag. This aligns with readOnlyHint and provides rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, then data source, then honesty guards. Every sentence adds value, no fluff, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (data join, ranking, filters), annotations (readOnlyHint), and the presence of an output schema, the description covers all necessary context: data source, join logic, ranking, honesty guards, and edge cap rationale. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description does not add new semantic meaning beyond the parameter descriptions (e.g., max_edge cap is already in the schema). Rephrasing 'include_started' as 'include already-started events' adds no new info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: returning actionable Kalshi contracts by comparing model win probability vs contract price, ranked by edge. It distinguishes from siblings by focusing on Kalshi markets, with explicit mention of data source and ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Kalshi contracts but does not explicitly state when to use this tool versus alternatives like prop_slate. It provides context on honesty guards but lacks direct when-to-use guidance. The mention of 'same honesty guards as prop_slate' provides some orientation but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
live_propsLive props with concentration flagARead-onlyInspect
Currently-offered props ranked by model edge, with a concentration flag.
Like prop_slate (same upcoming-only + max_edge guards), plus a player
filter (case-insensitive substring) and in_n_parlays per row — how many
of today's recommended parlays (parlay_prediction_log, latest
prediction_date) include this prop. A high count flags concentration risk:
many suggested parlays sharing one leg.
Each row also carries the cross-book consensus fields (consensus_implied, n_consensus_books, book_dispersion, edge_vs_consensus, model_outlier) — the per-book model_edge this tool ranks by is vs ONE book and may be the softest line, so consult edge_vs_consensus / model_outlier (see _PROP_EDGE_GUIDANCE) before trusting it.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | filter to one book/source key (e.g. 'prizepicks', 'underdog'); omit for all books. | |
| limit | No | max rows returned. | |
| sport | No | 'mlb' / 'nhl' / 'tennis' (aliases accepted); omit for all. | |
| player | No | case-insensitive substring match on player name. | |
| max_edge | No | edge cap — larger edges are usually stale lines, not bets. | |
| min_edge | No | minimum model_edge to include. | |
| include_started | No | include already-started events (default False = upcoming only). | |
| min_implied_prob | No | floor on the book's implied probability. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: explains concentration risk, cross-book consensus fields, and warns that model_edge is vs one book and may be softest line. Annotations (readOnlyHint=true) are consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but efficiently conveys all necessary information. Could be slightly more structured, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no required fields, and presence of output schema, the description covers core purpose, concentration flag, consensus fields, and edge caveats. References _PROP_EDGE_GUIDANCE for further context, making it comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by explaining the rationale for max_edge (stale lines) and clarifying player filter as case-insensitive substring. Does not significantly extend schema but provides interpretive context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns currently-offered props ranked by model edge with a concentration flag. It distinguishes from the sibling prop_slate by adding player filter and in_n_parlays metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly compares to prop_slate, noting similarities and additions. It advises consulting _PROP_EDGE_GUIDANCE for edge interpretation. However, it does not provide explicit when-not-to-use guidance for other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
model_performanceReconciled model performanceARead-onlyInspect
Reconciled game-prediction performance: ROI, win rate, calibration.
Reads game_prediction_log (settled, reconciled bets only). Filterable by model, target ('winner' or 'spread'), and a game_date window (YYYY-MM-DD).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | filter to one model key (e.g. 'xgb_v10', 'lgb_v8'); omit for all. | |
| target | No | 'winner' or 'spread'; omit for all. | |
| max_date | No | latest game date to include (YYYY-MM-DD). | |
| min_date | No | earliest game date to include (YYYY-MM-DD). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true, indicating safe read-only operation. The description adds context about the data source being reconciled bets only and the output metrics (ROI, win rate, calibration), which is useful beyond the annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the key output metrics, and efficiently conveys the core purpose and filters. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown but indicated as present) and no required parameters, the description is sufficient for an agent to understand what the tool returns and how to filter. Minor omissions: no mention of result ordering or default date range, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description reinforces the date format (YYYY-MM-DD) and filter capabilities but does not add significant new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves reconciled game-prediction performance metrics (ROI, win rate, calibration). It identifies the data source (game_prediction_log) and filter dimensions (model, target, date window). However, it does not explicitly differentiate from sibling tools like 'predictions', which might serve raw prediction data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it reads only settled, reconciled bets, implying it should be used for historical performance analysis on finalized bets. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools (e.g., 'predictions' for raw forecasts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingHealth checkARead-onlyInspect
Health check — confirm the server is reachable over the active transport.
Returns server identity, version, and which DuckDB target it would use
(motherduck when MOTHERDUCK_TOKEN is set, local otherwise).
Does not open a database connection, so it is safe to call from any
environment as a liveness probe.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable context that no database connection is opened, reinforcing safety. No contradictions, and the extra detail justifies a score above baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with 'Health check', no extraneous information. Every sentence adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, zero parameters, and an output schema that likely details the return values, the description fully covers what an agent needs to know: purpose, return content, and safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, so the description naturally cannot add meaning. Baseline score of 4 is appropriate as there is no need for compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a health check to confirm server reachability, specifying the exact returned data (server identity, version, DuckDB target). It is distinct from sibling tools like 'analyze_prop' or 'live_props' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is safe to call from any environment as a liveness probe and clarifies it does not open a database connection, implying ideal usage for health checks. While it doesn't explicitly list when not to use it, the context is clear enough for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predictionsDaily pick boardARead-onlyInspect
Today's model predictions — the FULL pick list, not just high-edge bets.
The honest "here is everything the models said" view, complementary to
prop_slate (which is filtered to >=10% edge bets ranked vs cross-book
consensus). Use this when asked "what are today's tennis/MLB/NHL picks?",
"show me all the Wimbledon predictions", etc. Two prediction families:
games — game/match-WINNER predictions, read straight from the per-sport prediction logs (
game_prediction_logMLB,nhl_prediction_log,tennis_prediction_log). Upcoming + ungraded only. This is the ONLY tool that surfaces moneyline/match-winner picks;prop_slateis props-only.props — player-prop predictions from
slate_prop_predictions(the slate scorer's output for every offered Underdog/PrizePicks line). Reads this table DIRECTLY rather than the edge mart, so it shows tennis props (and any board whose snapshot capture is stale) thatprop_slatecan miss.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | 'all' (default), 'game' (winners only), or 'prop' (props only). | all |
| limit | No | max rows per family (default 200). | |
| sport | No | 'mlb', 'nhl', or 'tennis' (aliases accepted); omit for all. | |
| min_edge | No | minimum edge as a probability delta. Default 0.0 — show the WHOLE board, including no-edge picks. Raise to focus on bets. | |
| days_ahead | No | include events up to this many days out (default 3). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint: true), description reveals data sources (prediction logs, slate_prop_predictions), includes upcoming+ungraded only for games, and explains why it may show props that 'prop_slate' misses. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with paragraphs, bullet points, and clear sections. Some length but each sentence adds value. Front-loaded with purpose, then details. Efficient for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and input schema fully documented, description covers data sources, family types, scope, and edge cases (stale snapshots). Complete for a read-only tool with no missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add significant parameter meaning beyond schema, but provides context for 'min_edge' and 'kind' values implicitly. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the full pick list of model predictions for games and props, with specific verb 'show' and distinct resource. It explicitly distinguishes from sibling 'prop_slate' which is filtered and props-only, enhancing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples like 'today's tennis… picks' and 'show me all the Wimbledon predictions', and contrasts with 'prop_slate' for filtered bets. Clearly guides agent on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prop_slateProp slate with model edgeARead-onlyInspect
Available player-prop slate with model edge per row, ranked by edge.
Reads mart_slate_with_edge — the captured slate (every offered prop line across books) joined to the model's prediction. Each row carries the book's implied probability, our model probability, and model_edge = model_prob - implied_prob (computed vs THIS book's price).
Two guards keep the ranking honest (both tunable): only upcoming
events are shown (the mart retains past games — without this filter the
top of the list is dominated by stale, settled lines), and edges are
capped at max_edge (a >25pp edge is almost always a stale/odd price or
model overconfidence, not a real bet — they carry a verify flag).
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | filter to one book/source key (e.g. 'prizepicks', 'draftkings', 'fanduel', 'underdog'); omit for all books. | |
| limit | No | maximum rows to return (default 100). | |
| sport | No | one of 'mlb', 'nhl', 'tennis' (aliases accepted); omit for all. | |
| max_edge | No | drop edges above this (default 0.25) as likely artifacts; raise to inspect them. | |
| min_edge | No | minimum model_edge as a probability delta. Default 0.10: reconciled history shows edges below ~10pp are net -EV (the 0-5pp bucket was -2.8% ROI and dominates volume), while 10-20pp edges realized +12-23% ROI. Lower it to see the full board. | |
| include_started | No | if True, also show events that have already started (default False — upcoming only). | |
| min_implied_prob | No | drop lines the book implies below this (default 0.05) — deep longshots where a tiny price inflates the edge. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the data pipeline (mart_slate_with_edge), the edge computation (model_prob - implied_prob), and the guards (upcoming only, edge capping with verify flag). This provides rich behavioral context for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (purpose, data source, guards). While every sentence adds value, the description could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with detailed descriptions, an output schema (present but not shown), and annotations indicating read-only, the description fully covers the tool's behavior, including ranking logic and edge computation. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are highly informative. For example, min_edge includes ROI statistics, max_edge explains artifact detection, and include_started clarifies default behavior. This adds significant meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'player-prop slate with model edge per row, ranked by edge.' It specifies the data source (mart_slate_with_edge), the inclusion of implied probability and model edge, and the filtering for upcoming events, distinguishing it from siblings like live_props or analyze_prop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to see upcoming prop slates with edges) and outlines key filters (book, sport, min_edge, max_edge, include_started). However, it does not explicitly state when not to use or compare to alternatives like live_props for in-game betting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smart_moneyLine movement / steam detectionARead-onlyInspect
Where the market is moving — steam / sharp-money signal for upcoming events.
Reads mart_line_movement_features (the hourly slate snapshots windowed
per line identity) and surfaces the lines whose implied probability has
moved the MOST since their opening snapshot, aggregated across books
so it reflects the market's consensus move rather than one book's quirk.
A line drifting toward a side means money is coming in on that side
(steam / sharp action).
IMPORTANT framing for the caller: this reports the market's own revealed
signal (how the price has moved), NOT our model's edge and NOT a pick.
It answers "where is the money going today" — pair it with prop_slate /
kalshi_edges (model edge) to see where the market move agrees or
disagrees with the model.
Two guards keep the signal honest (both tunable): it defaults to the
sportsbook feed (source='the_odds_api') and EXCLUDES Kalshi, whose
exchange contracts legitimately decay toward 0/1 over a multi-day
resolution window (that drift is not pre-game steam); and it caps moves at
max_move (default 30pp) because genuine pre-game steam is single-digit
pp — a larger swing is almost always a stale opening snapshot, not money.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows. | |
| sport | No | 'mlb' / 'nhl' / 'tennis' (omit for all). | |
| source | No | feed to read — 'the_odds_api' (sportsbooks, default), 'underdog', 'prizepicks', 'kalshi', or 'all' for every source (includes Kalshi's multi-day contract decay — use with care). | the_odds_api |
| max_move | No | maximum |move| to report; drops stale-open artifacts (0.30=30pp). Raise to inspect outliers. | |
| min_move | No | minimum |move since open| in implied-prob points (0.02=2pp). | |
| hours_ahead | No | only events commencing within this many hours from now (and still in the future). | |
| market_type | No | 'h2h' (game/match lines), 'props' (player props), or 'all' (default). | all |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, description explains it reads from mart_line_movement_features, aggregates across books, defaults to the_odds_api excluding Kalshi to avoid decay artifacts, and caps moves at 30pp. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear opening, technical details, important framing, and guard explanation. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 100% schema coverage, and existence of output schema, the description fully covers tool behavior, guards, usage context, and relationship to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions (100% coverage), but description adds context like why Kalshi is excluded by default and why max_move defaults to 30pp, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Where the market is moving — steam / sharp-money signal for upcoming events' and distinguishes itself from siblings like prop_slate/kalshi_edges by noting it reports market consensus move, not model edge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'NOT our model's edge and NOT a pick' and advises pairing with prop_slate/kalshi_edges to compare market move with model edge. Also explains default source exclusion of Kalshi and max_move cap for honesty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!