Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fanduel_research_projections

Retrieve FanDuel fantasy projections for MLB, NBA, NFL, NHL and golf by sport and type, including DFS salary, value and sport-specific stat columns.

Instructions

FanDuel Research fantasy projections. Returns numberFire's fantasy projections for MLB, NBA, NFL, NHL and golf in the service's rank order: each row has the player, team, game, FanDuel DFS salary and value (daily projections), and the stat columns of the player kind (points, rebounds and assists for the NBA; passing, rushing and receiving for NFL skill players; kicker, defense and individual defensive player columns; skater, goalie, batter and pitcher columns; golf finish odds). type picks the table: DAILY (needs slate_id), WEEKLY, YEARLY, REMAINING, PPR or SEASON_STATS; not every sport has every type, and position and scope depend on the table, so read them from the projection-tables route. An unknown slate is refused instead of silently returning other projections. Weekly NBA and MLB tables are empty outside their weeks. A player id can appear more than once in a yearly table.

Input Schema

NameRequiredDescriptionDefault
dateNoDay of the slate as `YYYY-MM-DD` when `slate_id` is not from today; MLB, NBA and NHL DAILY only
pageNoPage number, from 1; default 1, at most 10000
typeYesProjection type
weekNoNFL week of the slate when `slate_id` is not from this week; NFL DAILY only
limitNoRows per page, 1 to 200; default 50
scopeNo`TOTAL` or `PER_GAME`; only NBA WEEKLY, YEARLY, REMAINING and SEASON_STATS take it, default `TOTAL`; other tables return `400`
sportYesSport
seasonNoNFL season of the slate; NFL DAILY only
event_idNoGolf event id from the projection-slates route; golf only, defaults to the only current event
positionNoPosition tab of the table; default is the table's default tab. Allowed values: `batters`, `pitchers`, `c`, `1b`, `2b`, `3b`, `ss`, `of`, `sp`, `rp` (MLB); `qb`, `rb`, `wr`, `te`, `flex`, `k`, `defense`, `idp` (NFL); `all`, `pg`, `sg`, `guards`, `sf`, `pf`, `forwards`, `centers` (NBA); `skaters`, `goalies`, `forwards`, `wingers`, `centers`, `d` (NHL); `all` (golf). Which of them a table offers is listed by projection-tables
slate_idNoSlate id from the projection-slates route; required for DAILY (golf defaults to its only slate); other types return `400`

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.16

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses ordering (service rank order), row contents (player, team, game, salary, value, sport-specific stat columns), error behavior (unknown slate refused), empty-table conditions, and duplicate player ids in yearly tables. This is rich behavioral context beyond what the schema alone provides.

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?

The description is front-loaded with purpose and return shape before parameter rules, and every sentence is functional. It is a dense single paragraph and the sport-specific stat-column enumeration is somewhat verbose, but the length is justified by the tool's complexity.

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 an 11-parameter tool with no output schema, the description explains return content, table-type behavior, dependencies, and important edge cases. Combined with the fully described schema, an agent has enough information to invoke it correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: the chosen type determines whether slate_id is required and whether position/scope are applicable, and some weekly tables are empty outside their weeks. These constraints go beyond the per-field schema descriptions.

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 ('Returns') and resource ('numberFire's fantasy projections') and enumerates supported sports, row composition, and table types. It clearly distinguishes this projection-data tool from sibling routes such as projection-slates and projection-tables, which it references only as supporting lookups.

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?

Explains that DAILY requires slate_id, that not every sport has every projection type, and that position/scope should be read from the projection-tables route. It also notes weekly NBA/MLB tables are empty outside their weeks, giving useful usage context, though it does not explicitly say when to choose this tool over other FanDuel research tools.

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