Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

fanduel_research_player_news

Retrieve FanDuel Research player news and injury updates for NFL, NBA, MLB, and NHL. Filter by team, player, or news type to get short, newest-first updates.

Instructions

FanDuel Research player news and injuries. Returns short player and team updates, newest first: the fact, the analysis, the news type and the player (name, position, team, number_fire_id, and the Sportsbook roster page, whose slug ends in the same id). With news_type=INJURY it is a league-wide injury feed. Available for the NFL, NBA, MLB and NHL; the news types each sport has are listed by the sports route (the NFL has no LINEUP, MLB no OUTLOOK, the NHL only INJURY, TRANSACTION and GAME_UPDATE). Filter by team, or by player (id and position together).

Input Schema

NameRequiredDescriptionDefault
teamNoA team's `number_fire_id` from the `sports` route
limitNoUpdates per page, 1 to 100; default 25
sportYesSport slug
cursorNoContinue from the previous response's `next_cursor`
playerNoA player's `number_fire_id`; needs `position`
positionNoThe player's position code; needs `player`
news_typeNoUpdate type: `INJURY`, `RECAP`, `TRANSACTION`, `LINEUP`, `GAME_UPDATE`, `OUTLOOK`; a type the sport lacks returns `400` and lists the ones it has
include_non_primaryNo`true` to include updates where the subject is not the main player

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses result ordering ('newest first'), the returned fields, the league-wide scope of INJURY, and failure behavior ('a type the sport lacks returns `400` and lists the ones it has'). Auth and rate-limit behavior and pagination mechanics are left unstated, keeping it below a 5.

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 purpose and return shape, then filters, then sport availability. The middle sentence is dense and carries three clauses, but every sentence supplies information an agent needs; nothing is 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?

Eight parameters, three enums, no output schema, no annotations — and the description covers return fields, ordering, filtering rules, and error semantics for unsupported news types. Complete enough to call correctly; only auth/pagination details are absent.

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 baseline is 3, but the description adds meaning beyond the schema: player and position must be supplied together, INJURY turns the call into a league-wide feed, and news_type filtering is sport-dependent. It does not explain team's `number_fire_id` origin beyond pointing at the `sports` route, which the schema already does.

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 ('FanDuel Research player news and injuries') followed by an explicit inventory of what a record contains (fact, analysis, news type, player name/position/team/number_fire_id/roster page). This clearly separates it from the sibling fanduel_sportsbook_player_news, which is a different surface.

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 selection rules: 'With news_type=INJURY it is a league-wide injury feed', 'Filter by team, or by player (id and position together)', and sport-specific news types are deferred to the `sports` route with examples of what each sport lacks. It stops short of naming the sibling news tool as the alternative, so it is a strong 4 rather than a 5.

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

Deploy Server

Other Tools