Fantasy Football MCP — Draft, Start/Sit, Waivers

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

Annotations already declare this as a safe read-only, non-destructive, closed-world operation. The description adds useful behavior context such as 'Free', 'widest first' ordering, and seasonal availability, but it does not explain return fields, pagination, or data freshness beyond 'this week'.

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?

The description is compact and front-loaded with the in-season scope, then gives ordering, filtering, and a naming caveat. Every sentence carries useful information with no waste.

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 simple two-parameter read-only tool, it is mostly sufficient, but with no output schema it does not explain what a gap row contains, units, or return shape. The agent can call it, but the description leaves some result-interpretation 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 coverage is 100%, and both parameters are documented in the schema: limit has a default and position has an enum-like list. The description repeats 'filter by position' but adds no syntax or semantics beyond the schema, so baseline 3 is appropriate.

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 specific resource and scope: Kalshi vs book-consensus gaps on this week's NFL props, sorted widest first. It also clarifies the ADP-related naming caveat, so an agent can immediately tell what the tool returns.

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?

It gives an implied usage window ('In season') and notes that ADP gaps return in the 2027 offseason, but it does not explicitly say when to use this versus alternatives or what scenarios it is not for. Guidance is present but mostly implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds two pieces of real value beyond that — 'Free' (no cost/auth barrier) and the 5¢ divergence filter that governs which rows appear — but says nothing about result volume, pagination, or freshness of the lines.

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-loads the qualifying condition before the trailing 'Free.' marker. The opening is a sentence fragment ('In season: where the best available PRICE is...') which reads slightly awkwardly, but nothing is wasted.

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 some burden for explaining what comes back; it communicates that rows are mispriced strikes but never defines 'strikes' or the row shape. For a two-optional-parameter read-only query with full schema coverage this is adequate, though not fully self-sufficient.

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% for both parameters, so `limit` (default 15) and `roster` (user's-team players shown first) are already fully documented in the schema. The description adds no semantics for either parameter, 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 names a concrete resource (this week's NFL prop strikes) and states the defining criterion — where Kalshi and book consensus diverge by 5¢ or more. The tool name 'best_available' is vague on its own, but the description resolves it and the betting/market domain clearly separates it from the fantasy-football siblings. It stops just short of explicit sibling differentiation.

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:' signals a temporal applicability condition, which is genuinely useful guidance, and the 5¢ gap threshold implies what qualifies for inclusion. However, no alternative tool is named and there is no explicit when-not guidance (e.g., out of season, or when the user wants consensus prices rather than gaps).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value by disclosing what comes back: per-strike best prices across venues, model probabilities only where published, and a ranked verdict — the caveat "where we publish one" correctly signals the probability field can be absent.

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?

Front-loaded with the core capability and output shape, then routed by short quoted user phrasings. The utterance list is somewhat long but each entry maps to a distinct query form, so it largely earns its space.

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 compensates by enumerating the response contents (strikes, best price per side, probability, ranked verdict). an agent can anticipate the shape of the result; only cross-venue sourcing/pagination details are unstated, which matters little for a read-only comparison.

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 schema already documents players, scoring, and platform in detail including enum lists. The description only restates the 2–4 player count and adds no extra syntax or format guidance, which is the expected baseline when the schema carries the load.

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?

A specific verb (compare) applied to a bounded resource (2–4 NFL players this week) with the output enumerated: prop strikes, best price per side, published probability, and a ranked disagreement verdict. That is clearly separable from siblings like explain_player or start_sit, which answer different questions.

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 quoted example phrasings ("<A> or <B> this week", "who has the better prop", "<A> vs <B> receiving yards") give strong routing signals for when to pick this tool. It stops short of naming a sibling or a when-not-to-use condition, so not quite a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds useful context by identifying the data source (median Kalshi prices), included metrics, and that the tool is 'Free.' It does not describe return shape or pagination beyond what the schema provides.

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?

The description is short and front-loaded, starting with the season and then the specific ranking content. Every element earns its place: data source, metrics, cost, and the availability note that resolves the misleading tool name.

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 two-parameter, read-only ranking tool with fully described schema parameters and safety annotations, the description supplies enough detail about what the rankings contain and when they apply. The only minor gap is that it does not mention sibling tools or alternatives, but that is not essential to invoking this tool correctly.

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 both parameters are already documented: limit with its default and position with its allowed values. The description does not add syntax or filtering meaning beyond the schema, so the baseline of 3 is appropriate.

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 gives a specific resource and scope: this week's QB/RB/WR/TE rankings based on median Kalshi prices, including pass/rush/rec yards and anytime-TD price. It also clarifies the seasonality by noting the draft board returns in 2027. It does not explicitly distinguish itself from siblings such as compare_players or player_outlook, so it stops short of a 5.

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 phrase 'In season' tells the agent when this tool applies, and '(Draft board returns in 2027.)' makes clear it is not the draft tool now. However, it does not name alternatives or explain when another sibling tool would be more appropriate.

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

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

Annotations already cover the read-only, closed-world safety profile, so the description wisely spends its words elsewhere: it discloses the 30–70% calibration window and explicitly flags that some factors are not accounted for. That is genuine context beyond the annotations, though it says nothing about what happens when a player is uncalibrated (no number returned?).

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?

Front-loaded with the purpose, then the output inventory, then the usage triggers — a sensible order. The first sentence is long and packs several clauses together, but no sentence is filler.

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?

No output schema exists, and the description compensates by enumerating the four things the answer contains. For a two-optional-param read tool this is close to sufficient; only the uncalibrated-player case is left ambiguous.

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 coverage is 100% and both parameters are documented there, including the stat-narrowing examples. The description adds no parameter-level detail (e.g., what happens with a partial player name or whether stat defaults to all stats), so 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?

States a specific verb and resource — explaining why the model prices an NFL player's Kalshi prop strikes where it does — and enumerates the outputs (projection, The Ladder's verdict, widest published gap, model gaps). It is not explicitly differentiated from nearby siblings like explain_prop or explain_ladder, so the agent must infer the boundary.

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?

Gives concrete trigger phrasings ("why do you price <player> there", "explain <player>'s prop") that map user intent to this tool, which is strong routing guidance. It stops short of naming an alternative or stating when not to use it.

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

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

With readOnlyHint/openWorldHint already declared, the description still adds real context: this is live market data, best price per side is computed, and weekly projections are gated behind Pro. It does not say whether prices are delayed, whether a missing/unknown username errors out, or how much data a response can carry.

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?

Two sentences, both earning their place, with the usage triggers front-loaded. The second sentence is a fairly dense comma-list of return fields, but each item is informative rather than filler.

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?

There is no output schema, so the description must describe return values and it does so thoroughly, including the tier-gated projection. Missing only edge behavior: no-username defaults, empty leagues, and whether an unresolvable league name fails or falls back.

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 coverage is 100% and both parameters are already documented, so the schema does the heavy lifting. The description only restates the username/league relationship; notably all parameters are optional and it never says what happens when sleeper_username is omitted, which is the one ambiguity the schema does not resolve.

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 verb+resource pair ("show my fantasy team", Kalshi pricing for starters) and enumerates exactly what comes back: roster, opponent, kickoff, OUT/QB-gate flags, and prop strikes with best price. It implicitly separates itself from advice tools like start_sit by labeling the output "market data" rather than recommendations, though no sibling is named outright.

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?

It gives explicit trigger phrases ("show my fantasy team", "what is Kalshi pricing my starters at") plus the input condition for the optional league argument ("if you have several"). There are no explicit when-not conditions or named alternatives such as start_sit or player_outlook, so it stops short of a 5.

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

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

Annotations already establish readOnly/no-destruction and closed-world scope; the description adds genuine value by disclosing the return payload shape — all prop lines, the best price across venues, and modeled probability at each strike — plus that it is free. It doesn't cover behavior for ambiguous/partial player names, which is the one remaining gap.

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?

Two tightly packed sentences with the scope and output contents front-loaded before the usage examples. The fragment 'Free.' earns its place as a pricing signal, though the quoted example phrasings at the tail are slightly loose.

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 three-optional-parameter, no-output-schema tool, the description usefully summarizes what comes back (lines, best price, strike-level probabilities), so the agent knows what to expect. Only the ambiguous-name behavior and relationship to adjacent explain_/edge tools are missing.

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 player formatting, the scoring enum with its half_ppr default, and platform-driven presets are already fully documented. The description adds nothing about any of the three parameters, so 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?

States the resource precisely: one NFL player's Kalshi prop lines, best cross-venue price, and model probability at each strike. The 'One NFL player' scope implicitly separates it from board-level siblings like nfl_prop_board, though it never names those siblings explicitly.

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?

Provides example user utterances ('is <player> a good play this week', '<player> props'), which gives usable intent context. However, it offers no when-not guidance and doesn't route to the dense set of near-neighbors (nfl_prop_edge, nfl_prop_board, explain_prop, best_price), leaving the agent to infer boundaries.

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

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

Annotations already cover the read-only/free safety profile, but the description adds real context beyond them: this is the free complete list while the price/size fields live in the Pro sibling, which materially affects whether an agent needs a second call. It does not describe return format or list size, keeping it short of 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense, front-loaded sentences: the result set and its annotation come first, the tier/alternative note second. The quoted example queries are useful but occasionally verbose; nothing is truly wasted.

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?

No output schema exists, so the description must carry the return shape, and it does reasonably: ranked list, under/over labels, the stat driving each call, and the caveat that price and size require the Pro tool. Fine for a zero-required-parameter read.

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 coverage is 100% and the single optional position filter is fully documented in the schema, including the allowed values. The description adds nothing about filtering behavior, 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?

States a specific resource (every NFL player whose Kalshi prop price the model disagrees with this week) plus the output shape: ranked, flagged underpriced/overpriced, with the driving stat. It also separates itself from the sibling nfl_prop_edge by noting that one carries strike/price/size while this is the free complete list.

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?

Explicitly routes usage: it names the alternative Pro tool (nfl_prop_edge) for strike, price and size, and enumerates concrete activation phrasings like "undervalued players this week" and "busts to avoid this week." An agent can pick this tool without guessing.

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

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

Annotations already cover read-only and open-world, so the bar is lower, yet the description still adds real value: the numbers come from each player's own Kalshi strike ladder, the tool returns prices only with no recommendation, and weekly projections are gated behind Pro. That is useful disclosure about scope and limits.

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?

Front-loads usage scenarios in quotes, then the output, then the caveats; nearly every clause carries information. The 'read off his own strike ladder' phrase is colorful but slightly opaque to an agent unfamiliar with Kalshi.

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 does the work of explaining what comes back (median per-stat pricing and anytime-TD price, compared on shared stats). It does not mention error cases such as an unmatched player name, which matters for a lookup tool.

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 coverage is 100%, so the baseline is 3, but the description adds the 2–4 player constraint and the point that players are only compared on stats they share, which shapes how the agent should batch names. Minor arithmetic gap: the count is stated but not tied to the array-or-string flexibility.

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?

States a specific resource (Kalshi market pricing per player stat plus anytime-TD price) and the comparison operation across 2–4 players. It is clear what the tool returns, but it never explains how it differs from the sibling compare_players, which sounds like the same job.

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?

Gives concrete trigger phrases ('should I start Nacua or Adams', 'who does the market like more this week') and the 2–4 player bound, so an agent knows the intended context. It offers no exclusions and does not route the agent away from compare_players.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds two useful traits: it is a 24-hour trending window, and passing username+league excludes already-rostered players. The "Market data only" disclaimer hints at a scope boundary, but no rate limits, data freshness, or failure behavior (e.g., unknown username) are disclosed.

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?

Front-loaded with the user-facing trigger phrases and stays to two sentences with no filler. The nested quoting and em-dash clause make it slightly dense to parse, but nothing is wasted.

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 4-param, all-optional read tool with no output schema, the description conveys the data source (Sleeper), the window (24h), and the second data source (Kalshi prices). Return shape is only gestured at, but annotations plus schema cover the rest.

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 coverage is 100%, so limit, league, position, and sleeper_username are all documented already; the description largely restates those descriptions rather than adding format or edge-case detail. Baseline 3 applies when the schema carries the parameter burden.

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?

States a concrete verb+resource: Sleeper's most-added players in the last 24 hours paired with Kalshi prices. The quoted user phrasings ("who is everyone adding off waivers") make the resource unambiguous and distinguish it from siblings like best_available or my_league.

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?

Gives clear invocation contexts via two quoted user intents and explains the optional narrowing path (position filter; username + league to see only available players). It does not name a sibling alternative or say when NOT to use it versus best_available, which keeps it below a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two pieces of genuinely non-structured context — the in-season gating and the fact that calls are free — plus that results are deduplicated to the best price per strike. It does not say what happens out of season or when a named player isn't found, which is the main remaining behavioral gap.

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 with no filler, and the example is placed at the end where it belongs. The front-loading is weaker — the first clause is a condition ("In season:") rather than the tool's function, and the "Free." sentence fragment reads as loose note-taking rather than structured spec.

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 one optional parameter, full schema coverage, annotations, and no output schema, the definition has modest burden — yet it is thin. An agent still doesn't know the result shape (how many props per player, ranked how), out-of-season behavior, or unmatched-name handling.

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 coverage is 100% and the roster parameter already documents "2–4 player names (full or partial)". The "Pass roster: ['Player A', 'Player B']" example adds modest value by resolving the anyOf ambiguity toward the array form, but nothing else is added beyond the schema.

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 Kalshi props listed on the players you name (2–4), with the best price per strike" does state the resource (props for named players) and an output property (best price per strike). However, the tool name and title ("who_do_i_draft", "Your Roster's Props This Week") suggest draft recommendations, and the description never resolves that tension or positions itself against siblings like player_outlook or draft_board.

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" is an implied usage condition and "Free" signals a cost-free call, which is useful routing context. But no alternative is named and there is no statement of when NOT to use it (e.g., out of season, or for non-prop questions that belong to player_outlook or compare_players).

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