Skip to main content
Glama

DraftCall

by io.draftcall

Look up a player matchup for one week

get_weekly_matchup
Read-onlyIdempotent

Who a player faces in a given week of the 2026 season, whether it is home or away, and how generous that opponent has been to that position. Use this for in-season start or sit questions that name a week, which the season-long tools cannot answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
weekYesRegular-season week, 1 through 18.
playerYesPlayer name, e.g. "Puka Nacua".
scoring_formatNoScoring format. ppr awards 1 point per reception, half_ppr 0.5, standard 0. Defaults to half_ppr, the most common league setting.half_ppr

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe draftcall.io page these figures came from. This is the citation to use.
homeNo
teamYes
weekYes
on_byeYesTrue when the team has no game that week, in which case the opponent fields are null.
playerYes
seasonYes
gamedayNo
opponentNo
positionYes
player_ppgYes
refreshed_atYesWhen this dataset was last refreshed, as an ISO 8601 timestamp.
stats_seasonYesThe completed NFL season every figure in this result describes.
scoring_formatYes
opponent_allowed_ofNo
opponent_allowed_ppgNoFantasy points this opponent allowed per game to the position over the completed season.
opponent_allowed_rankNoRank among teams, where 1 allowed the MOST and is therefore the softest matchup.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful behavioral context beyond annotations: the data is tied to the 2026 season, and the tool returns venue (home/away) plus opponent-tier generosity for the position. No annotation contradiction exists.

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?

Two sentences with no filler. The first sentence front-loads the core lookup result, and the second explains the intended use case and limitation of alternatives. Every sentence earns its place.

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 simple read-only lookup with full schema coverage, rich annotations, and a present output schema, the description is complete. It covers the temporal scope, the key result dimensions, and the exact scenario in which an agent should choose this tool. Nothing essential for selecting or invoking it is missing.

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 player, week, and scoring_format clearly. The description adds some context about what the week/player pair resolves to, but it does not materially extend parameter meaning beyond the schema, making the baseline 3 appropriate.

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 states a specific verb and resource: it reports who a player faces in a given week, home/away status, and opponent generosity to that position. It also distinguishes itself from season-long tools by scoping to weekly in-season questions, so an agent can tell it apart from sibling tools like get_rankings or get_strength_of_schedule.

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?

The description explicitly says to use this for 'in-season start or sit questions that name a week' and notes that 'season-long tools cannot answer' those questions. This gives a clear when-to-use signal and an implicit when-not-to-use condition, but it does not name specific alternative sibling tools, so it stops short of a 5.

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

All DraftCall toolsInspect
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

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct query type: single-player lookup, two-player comparison, rankings, scarcity, ADP gaps, schedule, bye conflicts, weekly matchup, search, and claim verification. Even related tools like compare_players and get_player have clearly separated purposes that an agent can reliably distinguish.

Naming Consistency4/5

Seven tools follow the get_ noun pattern, while search_players, compare_players, and verify_claim use verb_noun without get. The convention is still highly readable and predictable, with only minor deviations.

Tool Count5/5

Ten tools is well-scoped for a fantasy football data server. Each tool covers a meaningful slice of draft, in-season, and fact-checking workflows without unnecessary overlap or bloat.

Completeness4/5

The set covers player lookup, head-to-head comparison, rankings, scarcity, schedule, bye conflicts, weekly matchups, and stat verification. A direct standalone ADP lookup and projections are missing, but agents can work around those gaps using the provided tools.

Resources