who_do_i_draftIn season: the Kalshi props listed on the players you name (2–4), with the best price per strike. Free. Pass roster: ['Player A', 'Player B'].
| Name | Required | Description | Default |
|---|---|---|---|
| roster | No | 2–4 player names on your roster (full or partial). |
Changes observed during successful MCP inspections.
Input schema / properties / rosterAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ ],
+ "description": "2–4 player names on your roster (full or partial)."
+}Input schema / properties / draftedRemoved value: -{
- "description": "Player names already drafted by ANY team. Optional — without it the board is estimated from pick_number using consensus ADP. Supplying it is always more accurate.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / pick_numberRemoved value: -{
- "description": "The overall pick number on the clock.",
- "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 / rosterRemoved value: -{
- "description": "Player names already on the user's team.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}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"
-}Input schema / requiredRemoved value: -[
- "roster",
- "pick_number"
-]Input schema / properties / platform / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "enum": [
+ "yahoo",
+ "espn",
+ "sleeper",
+ "nfl",
+ "cbs",
+ "fantrax",
+ "draftkings",
+ "underdog"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / platform / descriptionPrevious value: -"League platform — applies its default scoring, size, roster + best-ball settings (overridable by explicit scoring/teams). Underdog/DraftKings are best ball."New value: +"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 / platform / enumRemoved value: -[
- "yahoo",
- "espn",
- "sleeper",
- "nfl",
- "cbs",
- "fantrax",
- "draftkings",
- "underdog"
-]Input schema / properties / platform / typeRemoved value: -"string"Input schema / properties / scoring / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "enum": [
+ "standard",
+ "half_ppr",
+ "ppr"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / scoring / descriptionPrevious value: -"Scoring format: standard, half_ppr (default), or ppr (full PPR). Overrides a platform preset. Works for Yahoo/ESPN/Sleeper defaults."New value: +"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 / scoring / enumRemoved value: -[
- "standard",
- "half_ppr",
- "ppr"
-]Input schema / properties / scoring / typeRemoved value: -"string"Input schema / properties / draftedAdded value: +{
+ "description": "Player names already drafted by ANY team. Optional — without it the board is estimated from pick_number using consensus ADP. Supplying it is always more accurate.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds genuinely non-structured traits: that the call is 'Free' (cost behavior) and only valid 'In season' (availability constraint). It does not explain behavior out of season, but the annotations plus these two facts give solid coverage.
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?
Very short and front-loaded: season condition, output, cost, and call format. The telegraphic fragments ('Free.') are efficient, though the style is slightly clipped and the example could be trimmed without loss.
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?
For a single-optional-parameter, read-only tool with no output schema, the description covers what is returned (props with best price per strike) and gives an invocation example. Only the out-of-season behavior and the meaning of 'best price per strike' tie-breaking remain unspecified.
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%, so the 'roster' parameter and its 2–4 name constraint are already documented. The description adds a literal call example ('Pass roster: ["Player A", "Player B"]'), which is marginally useful, so the baseline 3 applies.
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?
The description states a concrete return: Kalshi props on 2–4 named players, with the best price per strike. It differs from the tool name ('who_do_i_draft' suggests draft advice) but clarifies the actual behavior, though it never names a sibling tool to differentiate itself among the many prop/edge tools.
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?
'In season:' implies a usage window and 'Free' signals no cost, which is mild context. However, no alternatives are named (e.g., nfl_prop_board, nfl_prop_edge) and there is no explicit when-not guidance, leaving routing to inference.
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.