GridIron Data

Weekly fantasy projections

get_projections

Read-onlyIdempotent

Returns projected fantasy points for every player in an NFL week (1-18), in PPR, half-PPR or standard scoring, optionally for one position or team. Use it for start/sit, rankings and "top N at a position this week". Each row also has gridiron_projection, GridIron Data's own model (with model_version and as_of; null when none), which unlike projected_points may be displayed under Pro + Commercial. Players who can't play project 0 with available=false. Free plan: the current week of the current season; other weeks and seasons need Basic; Pro adds projected_stats per row (pass_yds, rec, rush_yds, ...).

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": {
      "week": "<week>"
    },
    "name": "get_projections"
  }
}

Input Schema

Name	Required	Description	Default
`team`	No	Only this team's players. Team code, e.g. BUF or KC. LA/LAR, WSH/WAS and JAC/JAX are interchangeable.
`week`	Yes	NFL regular-season week, 1-18.
`season`	No	Season year, 2020 or later. Default: the current season.
`scoring`	No	Fantasy scoring: ppr (full PPR, the default), half (half-PPR) or standard.	ppr
`position`	No	Only this position.
`weekly_only`	No	true = only real weekly projections, without the season-prorated fallback used for weeks not yet published.
`gridiron_only`	No	true = only GridIron Data's own model projections (gridiron_projection).

Output Schema

Name	Required	Description
`note`	No	A sentence for the user saying which plan is needed.
`team`	No	Present when filtered by team.
`week`	No	The NFL week.
`count`	No	Rows returned.
`error`	No	Present only when the call failed: what went wrong.
`reason`	No	Machine-readable failure reason, e.g. basic_required or pro_required.
`season`	No	The season.
`source`	No	Present when only GridIron's own projections were asked for.
`status`	No	HTTP status of the failed API call.
`scoring`	No	Scoring used.
`projections`	No	One row per player: projected_points, player_id, team, injury status, available, gridiron_projection, and projected_stats on Pro.
`upgrade_url`	No	Where to see the plans.
`required_plan`	No	The plan that unlocks this data: basic or pro.
`prorated_count`	No	Rows that use the season-prorated fallback.
`projected_stats`	No	Below Pro only: a note that per-stat projections need Pro.
`unavailable_count`	No	Players who can't play (OUT, IR, bye) and project 0.
`gridiron_projections`	No	The week's GridIron projection run (model_version, as_of), or null.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: licensing constraints on gridiron_projection, null-model handling with model_version/as_of, the sentinel behavior for unavailable players (0 points with available=false), and per-tier field gating. These are exactly the behavioral facts an agent cannot infer from structured fields.

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 core purpose, then layered with the model/licensing caveat and the plan tiers — a sensible ordering. It is dense and slightly run-on in the middle, but each clause supplies information the caller needs; little could be cut without losing an operational constraint.

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?

For a 7-parameter read tool with an output schema and full annotation coverage, the description is complete: it explains the projection semantics, the fallback model column, the unavailable-player sentinel and access tiers. An agent could decide to call it and interpret the response shape's meaningful oddities without further help.

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%, including team-code aliasing, week bounds, season pattern, scoring enum and position enum, so the schema carries the parameter burden. The description restates the dimensions (week, scoring, position, team) at a high level but adds no syntax or format detail beyond that, and never explains weekly_only or gridiron_only, which remain schema-only.

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 and resource ("Returns projected fantasy points for every player in an NFL week (1-18)") plus the scoring formats and optional position/team narrowing. The explicit week scoping and the plan tiers let an agent separate it from rest-of-season or per-player lookups without opening the schema.

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 concrete when-to-use guidance: "Use it for start/sit, rankings and 'top N at a position this week'." It also states plan-gated availability (Free = current week of current season, Basic for other weeks/seasons, Pro for projected_stats), which affects when the call will succeed. It stops short of naming an alternative sibling to use instead when a different scope is wanted.

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

All GridIron Data 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.

Resources

Need Help?