EndzoneAPI

Plays

get_plays

Read-onlyIdempotent

Use for play-by-play with advanced metrics: EPA, WPA, win probability, success, CPOE, air yards, formation flags, and the players involved. Filter by game, or by season plus week/team/player, plus play type, down, quarter, win-probability band, red zone, third down. Returns a per-query EPA and success-rate summary. Paginate with offset. Costs 10 credits.

Input Schema

Name	Required	Description
`down`	No	Down
`week`	No	Week
`limit`	No	Max plays (default 200)
`max_wp`	No	Maximum pre-play win probability
`min_wp`	No	Minimum pre-play win probability for the offense
`offset`	No	Pagination offset
`season`	No	Season year (required when game_id is not set)
`defteam`	No	Defense team code
`game_id`	No	Game id, e.g. 2025_01_KC_BUF
`posteam`	No	Offense team code
`quarter`	No	Quarter (5+ = overtime)
`red_zone`	No	Only plays inside the 20
`passer_id`	No	GSIS id of the passer
`play_type`	No	Play type
`rusher_id`	No	GSIS id of the rusher
`third_down`	No	Only third downs
`receiver_id`	No	GSIS id of the receiver

Output Schema

Name	Required	Description	Default
`note`	No
`count`	Yes
`plays`	Yes
`summary`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 17, 2026

removedInput schema / properties / include_charting

Removed value: -{
-  "description": "Attach FTN manual charting to each play (2022+): alignment, motion, play action, screens, RPO, blitzers, drops",
-  "type": "boolean"
-}

removedInput schema / properties / is_drop

Removed value: -{
-  "description": "Charting filter: charted drop (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_motion

Removed value: -{
-  "description": "Charting filter: pre-snap motion (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_no_huddle

Removed value: -{
-  "description": "Charting filter: no huddle (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_play_action

Removed value: -{
-  "description": "Charting filter: play action (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_qb_out_of_pocket

Removed value: -{
-  "description": "Charting filter: quarterback out of the pocket (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_rpo

Removed value: -{
-  "description": "Charting filter: run-pass option (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_screen_pass

Removed value: -{
-  "description": "Charting filter: screen pass (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / is_trick_play

Removed value: -{
-  "description": "Charting filter: trick play (2022+)",
-  "type": "boolean"
-}

removedInput schema / properties / min_blitzers

Removed value: -{
-  "description": "Charting filter: at least this many blitzers (2022+). FTN counts rushers beyond the base rush, so this is typically 0-3; 5+ is almost never charted.",
-  "maximum": 11,
-  "minimum": 0,
-  "type": "integer"
-}

removedOutput schema / properties / charted_plays
```
Removed value: -{
-  "type": "number"
-}
```

removedOutput schema / properties / plays / items / properties / charting

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": {},
-      "propertyNames": {
-        "type": "string"
-      },
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

First observedSep 27, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's real contribution is the cost disclosure ('Costs 10 credits'), the pagination mechanism, and the fact that a per-query EPA/success-rate summary comes back. That is meaningful operational context an agent cannot get from the 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?

Five tight sentences, each carrying distinct information in priority order: purpose, filter paths, return summary, pagination, cost. No restatement of the title and no filler.

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 a 17-parameter tool with an output schema, the description covers the decision-critical pieces: which identifier combinations are valid, what summary comes back, how to page, and the cost. Nothing essential is missing, though a note on default result size or the limit cap would close the last gap.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds value by grouping the 17 filters into coherent paths (game_id vs season+week/team/player) and calling out the win-probability band, red zone, and third-down toggles as a set. It does not explain the GSIS id parameters, which the schema handles on its own.

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?

States a specific verb and resource ('play-by-play with advanced metrics') and enumerates the metrics returned (EPA, WPA, CPOE, air yards), which clearly separates it from aggregate siblings like get_team_stats or get_player_stats. It never names a sibling explicitly, so the differentiation is implied by granularity rather than stated.

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

Usage Guidelines4/5

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

'Use for play-by-play with advanced metrics' plus the two supported filter paths (by game, or by season plus week/team/player) tells the agent how to scope a query. It stops short of saying when to prefer get_advanced_stats or get_player_stats instead, so a boundary case is left to inference.

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

All EndzoneAPI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.