draft_boardIn season: this week's QB/RB/WR/TE rankings by the median Kalshi prices each player at (pass/rush/rec yds), plus anytime-TD price. Free. (Draft board returns in 2027.)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows (default 15). Values above 50 are clamped to 50. | |
| position | No | Optional position filter (FLEX = RB/WR/TE). One of: QB · RB · WR · TE · FLEX. |
Changes observed during successful MCP inspections.
Input schema / properties / limit / anyOfRemoved value: -[
- {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "string"
- }
- ]
- },
- {
- "type": "null"
- }
-]Input schema / properties / limit / typeAdded value: +[
+ "number",
+ "string",
+ "null"
+]Input schema / properties / limitRemoved value: -{
- "default": 50,
- "description": "Max players to return, best first (default 50). The full board is ~330 and all of it is free.",
- "maximum": 400,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / platformRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "enum": [
- "yahoo",
- "espn",
- "sleeper",
- "nfl",
- "cbs",
- "fantrax",
- "draftkings",
- "underdog"
- ],
- "type": "string"
- }
- ],
- "description": "League platform — applies its default scoring, size, roster + best-ball settings (overridable by explicit scoring/teams). Underdog/DraftKings are best ball. One of: yahoo · espn · sleeper · nfl · cbs · fantrax · draftkings · underdog."
-}Input schema / properties / positionRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "enum": [
- "QB",
- "RB",
- "WR",
- "TE",
- "FLEX"
- ],
- "type": "string"
- }
- ],
- "description": "Optional position filter (FLEX = RB/WR/TE). One of: QB · RB · WR · TE · FLEX."
-}Input schema / properties / scoringRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "enum": [
- "standard",
- "half_ppr",
- "ppr"
- ],
- "type": "string"
- }
- ],
- "description": "Scoring format: standard, half_ppr (default), or ppr (full PPR). Overrides a platform preset. Works for Yahoo/ESPN/Sleeper defaults. One of: standard · half_ppr · ppr."
-}Input schema / properties / teamsRemoved value: -{
- "description": "League size (number of teams) for draft-round math. Overrides the platform default; falls back to 12.",
- "maximum": 20,
- "minimum": 4,
- "type": "integer"
-}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, closed-world, non-destructive behavior, so the safety profile is covered. The description adds real context beyond that: cost ('Free'), seasonal availability ('In season'), and that the draft-board variant is unavailable until 2027 — all useful for deciding whether to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: the rankings concept leads, with clarifying parentheticals for cost and draft-board availability. Dense but not wasteful, though the 'plus anytime-TD price' clause could sit in a cleaner position.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully sketches the returned content (median market prices for passing/rushing/receiving yards plus anytime-TD). It leaves the exact row/field shape unstated, but for a two-parameter read-only board that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both limit (default 15, clamped at 50) and position (enum including FLEX) fully documented in the schema. The description adds nothing about parameter syntax or defaults, which is acceptable at this coverage level but earns no extra credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a concrete artifact (this week's QB/RB/WR/TE rankings) and the data source (median Kalshi prices for pass/rush/rec yds plus anytime-TD price). That is enough to distinguish it from prop-board and draft-oriented siblings like nfl_prop_board and who_do_i_draft, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'In season' framing and 'Free' note imply when the tool is usable, and the 2027 parenthetical rules out the draft-board use case for now. However, there is no explicit statement of when to pick this over the many other NFL/edge tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.