best_availableIn season: where the best available PRICE is on this week's NFL props — strikes where Kalshi and the book consensus are 5¢+ apart. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows (default 15). Values above 50 are clamped to 50. | |
| roster | No | Optional: player names on the USER's team — their strikes are shown first. |
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 / draftedRemoved value: -{
- "description": "Player names already drafted (any team). Removed from the pool.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / pick_numberRemoved value: -{
- "description": "The overall pick number that is 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 on the USER's team — enables a bye-stack warning on the top pick (byes are shown per-player regardless).",
- "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: -[
- "pick_number"
-]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds two useful non-schema facts: the tool is only meaningful 'in season' and it is 'free.' It says nothing about pagination behavior or how many rows come back by default, so the added value is modest.
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?
A single tight sentence with the seasonality caveat front-loaded and the 'Free' note trailing. Fragmented punctuation ('In season:' / 'Free.') but no wasted words and the core criterion is stated early.
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 carries more of the burden and it does convey the gist of the result set (price strikes where Kalshi and consensus diverge by 5¢+). It does not describe the row shape (columns, prices shown, ordering) which a 2-param analytical tool would benefit from. Adequate but with clear gaps.
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% — both `limit` (with its 50-row clamp) and `roster` (user-team prioritization) are fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 is correct.
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 names a specific resource (this week's NFL props) and a precise criterion (strikes where Kalshi and book consensus are 5¢+ apart), which tells the agent exactly what the tool surfaces. It is not verb-led and does not explicitly distinguish itself from close siblings like nfl_prop_edge, scan_mispricings, or nfl_prop_board, but the 'Kalshi vs book consensus' angle is distinctive enough to separate it.
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:' prefix gives a genuine applicability condition (NFL season only), which is more than most siblings offer. However, it never names an alternative tool or states when to prefer nfl_prop_edge / nfl_prop_board instead, so the routing decision is left 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.