EndzoneAPI

Plays

get_plays

Read-only

Use for play-by-play with nflfastR 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

TableJSON 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

TableJSON 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.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: pagination via offset and a cost of 10 credits per call, plus a per-query EPA/success-rate summary on the return. It does not mention auth requirements or the default limit (schema covers the latter).

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?

Front-loaded with the use case, then filters, then return shape, pagination, and cost in a tight sequence with no filler sentences. The metric enumeration is long but every item earns its place given 17 parameters to advertise.

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?

An output schema exists, so return values need no elaboration, yet the description still calls out the EPA/success-rate summary. Combined with cost, pagination, and filter-combination rules for a 17-param, zero-required tool, an agent has everything needed to call it correctly.

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 description coverage is 100%, so the schema already documents all 17 parameters, making 3 the baseline. The description mostly restates schema field names, though it adds mild semantics by framing min_wp/max_wp as a 'win-probability band' and describing how game vs. season+week/team/player filters combine.

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?

States a specific verb-resource (play-by-play) and enumerates the nflfastR play-level metrics it exposes (EPA, WPA, CPOE, air yards, formation flags), which cleanly separates it from aggregate siblings like get_advanced_stats, get_player_stats, and game-level get_game_detail.

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?

Gives explicit filter recipes: by game, or by season plus week/team/player, plus play type, down, quarter, win-probability band, red zone, third down. It provides clear context for when the tool is the right one but names no alternative or when-not conditions (e.g., when to prefer get_player_stats for aggregates).

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.