v12-dfs

slate_health

Slate Health

Pre-flight diagnostic for a slate. Returns whether odds, projections, matchup, and FD master-session are ready BEFORE the agent invokes /v1/generate.

Either slate_id or date is required. When slate_id is given, the slate metadata is also returned (games list, lock times). When only date is given, the data-pillar checks still run but game coverage cannot be computed (returned as null).

READING THE PROJECTION FRESHNESS (MLB especially): stokastic.age_min is the age of the cached snapshot FILE, NOT a data-quality signal. For MLB the cache is refreshed only twice a day, so mid-afternoon it routinely reads several hours old AND THAT IS FINE — a user-facing generate fetches projections LIVE (refresh_data=true), and stokastic.generate_fetches_live=true flags this. A stale age_min with a loaded, populated pool is NOT "projections broken / aces at 0 / no edge": probable pitchers are set days ahead (non-zero), and only confirmed BATTING lineups firm up ~1-2h before lock. Do NOT treat a stale cache age as a blocker or tell the user to wait/re-refresh — check the actual pool (get_slate_players) for non-zero pitcher projections instead.

Responses:

200: Successful Response (Success Response) Content-Type: application/json 422: Validation Error Content-Type: application/json

Example Response:

{
  "detail": [
    {
      "loc": [],
      "msg": "Message",
      "type": "Error Type",
      "ctx": {}
    }
  ]
}

Input Schema

TableJSON Schema

Name	Required	Default
`date`	No
`site`	No	fd
`sport`	No	NBA
`slate_id`	No
`include_snapshot`	No
`last_known_fingerprint`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description provides extensive behavioral context: meaning of age_min, that generate_fetches_live indicates live fetch, and guidance on not treating stale cache as a blocker. It also explains limitations when only date is given. However, it does not explicitly state idempotency or absence of side effects, though heavily implied.

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?

Well-structured: starts with one-line summary, then sections on parameters and behavioral notes. The MLB freshness section is lengthy but necessary for correct usage. Some redundancy could be trimmed, but overall efficient.

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

Completeness3/5

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

Covers high-level behavior and critical warnings, but lacks detailed output schema (e.g., the actual response fields indicating readiness). The example only shows validation error. Given 6 parameters and no output schema, the description leaves some gaps that an agent would need to infer from sibling tools or experience.

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 describes 6 parameters with 0% coverage. The description adds meaning for 'slate_id' and 'date' (requirement and behavior difference) but does not explain 'include_snapshot', 'last_known_fingerprint', 'site', or 'sport'. While site and sport are common, the other two lack guidance, partially compensating for low coverage.

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 purpose as a 'Pre-flight diagnostic for a slate' that checks readiness of odds, projections, etc., before invoking /v1/generate. It uses specific verb+resource and distinguishes from sibling 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?

Explicitly states when to use the tool (before /v1/generate). Provides detailed guidance on using slate_id vs date, including behavior differences. Includes a comprehensive note on MLB projection freshness, warning against misinterpretation and advising to check actual player pools instead.

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

All v12-dfs tools Inspect

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

C2.8/5.0

Disambiguation3/5

The betting_* cluster is clearly namespaced, but betting_best_bets and betting_scan_edges both return a ranked board of top prop edges, and betting_market overlaps with betting_game_lines and betting_sharp/cross_book in purpose. The detailed descriptions reduce misselection, but several boundaries are not crisp.

Naming Consistency3/5

The set is uniformly snake_case with helpful cluster prefixes like betting_, list_, and slate_, so it reads predictably. However, it mixes verb_noun names (generate_lineups, run_mlb_postmortem), noun phrases (betting_market, health_check/health_v12), and adjective-noun names (betting_best_bets, betting_sharp), so there isn't one consistent pattern.

Tool Count2/5

34 tools is above the 25+ threshold for a single MCP server, even considering the combined betting/DFS/contest scope. Several tools could be consolidated — betting_best_bets vs betting_scan_edges, health_check vs health_v12, and the two guides — making the surface feel heavy rather than lean.

Completeness5/5

The betting lifecycle is covered end-to-end: raw markets, models, edge scans, value checks, parlay building, bet logging/settlement, and P&L/CLV. The DFS side covers slates, player pools, lineup generation/fill, presets, contests, diff/health/refresh, and postmortems, leaving no obvious dead end for agents.

Resources

Need Help?