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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is partly covered. The description adds genuinely useful context beyond that: creds are injected automatically, parameter names are CASE SENSITIVE and must match MFL docs, and site-wide vs league-scoped behavior. It stops short of describing output shape or error behavior for arbitrary exports.

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 the core framing ('Read-only escape hatch') and organizes the rest into purpose, credentials, and an Args list. Most sentences earn their place, though 'cannot change anything in MFL' mildly repeats the readOnly/destructive annotations.

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 an open-ended passthrough tool with no output schema (raw MFL JSON) and 5 params, the description covers the routing decision, credential handling, param naming rules, and the league_scoped toggle. It could note that the return payload varies by type, but is otherwise complete.

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, and the description pushes past it by warning that param names are case-sensitive and must match MFL docs (e.g. W, P, FRANCHISE), which is not stated in the schema. The example param object and league_scoped usage reinforce but largely restate 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?

States a specific verb and resource ('call any MFL export request TYPE and get the raw JSON') and explicitly positions itself as an 'escape hatch' distinct from the dedicated sibling tools. An agent can immediately tell it apart from mfl_get_* 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?

Explicit when-to-use gate ('Use this only when no dedicated mfl_ tool covers the need') plus a concrete list of example types that map to common use cases. It names the alternative category (mfl_ tools) and the condition that selects this one over them.

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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral value by noting that unmade picks appear as 'on the clock / pending' and that the tool covers both rookie and startup drafts — output nuances not captured by annotations.

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 purpose, then a compact Args block. Two sentences and a short list, each carrying distinct information with no 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?

With no output schema, the description compensates by naming the returned fields and the pending-pick state. Complete enough to invoke correctly; only the absence of explicit alternative-tool routing keeps it from a 5.

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 all four parameters are already fully documented in the schema. The description only restates them plus the past-draft hint, adding marginal meaning beyond what the schema provides; 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 ('Get the league's draft results for a season') and enumerates the returned fields (round, pick, picking team, player). The 'rookie/startup draft' qualifier and the 'on the clock / pending' behavior clearly separate it from siblings like mfl_get_future_draft_picks.

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 hints at usage ('Use season to look at a past draft') and documents the franchise shorthand, but it never says when to use this tool versus alternatives such as mfl_get_future_draft_picks or mfl_get_players, nor any prerequisites. Usage is implied rather than explicit.

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 safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuinely useful traits beyond them: results are sorted by year-to-date fantasy points under the league's own scoring rules, and coverage spans offense and IDP.

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 purpose in one sentence, then a compact Args list. The Args block duplicates the schema somewhat, keeping it just short of maximally efficient, but nothing is padded or verbose.

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 necessary work of stating what comes back: available players ordered by league-scored fantasy points. Pagination and format are covered by the schema, so an agent has enough to call it correctly; only the alternative-tool routing is 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 every parameter including ranges, defaults, and the response_format enum is already documented. The Args block mostly restates schema content (limit range, offset default) without adding filter syntax or semantics beyond it, which is the expected baseline.

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 ('List players available (not on any roster) in the league') plus the sort order and scope (offense and IDP), which distinguishes it from the generic sibling mfl_get_players. It never names the sibling explicitly, so the differentiation is inferable rather than stated.

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 parenthetical '(not on any roster)' implies the use case (finding waiver-wire pickups), but the description gives no explicit when-to-use, when-not, or pointer to alternatives such as mfl_get_players. Usage 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.

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

Annotations already declare this a safe, idempotent, non-destructive read (readOnlyHint=true, idempotentHint=true), so the safety profile is covered. The description adds the returned data shape (year, round, original pick), which is useful, but says nothing about pagination, rate limits, or how the year/round filtering behaves.

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 opening sentence is front-loaded and earns its place. The Args block is somewhat redundant with the already-complete schema descriptions, but overall it stays short and readable with no wasted preamble.

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 read-only tool with no output schema, the description compensates by naming the returned fields and the default franchise scope. It is nearly complete, missing only guidance on how it relates to the draft-results sibling.

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 every parameter is already documented in the schema. The description's Args block restates the same franchise and response_format options rather than adding new semantics, which lands at the baseline 3.

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 ('Get the future rookie draft picks each franchise owns') and even enumerates the returned fields (year, round, original pick). It is clearly distinct from peers like mfl_get_roster or mfl_get_players, though it does not explicitly contrast itself with the closest sibling, mfl_get_draft_results.

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 'Essential for dynasty trade analysis' implies a use context, but there is no explicit when-to-use guidance, no exclusions, and no named alternative (e.g., mfl_get_draft_results for completed drafts). Usage must be inferred.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful conditional defaults (scope defaults to 'mine' when a franchise is configured, week omitted = latest) but says nothing about auth requirements, rate limits, or result size.

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 one-sentence purpose followed by a compact Args block; every line carries information. Slight redundancy with the schema descriptions, but nothing is wasted and the structure is easy to scan.

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 naming the returned fields (status, injury details, expected return) and the two response formats. Nothing critical is missing for a read-only report tool, though output shape and pagination limits are not spelled out.

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 baseline is 3, but the description genuinely enriches the scope parameter beyond the schema's terse 'mine (default if configured), league, or all' by explaining what each mode returns (own roster vs. every rostered player with fantasy owner vs. entire NFL report). Week and response_format are only echoed from 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?

States a specific verb+resource ('Get the NFL injury report') and immediately scopes it ('filtered to the players you care about'), which cleanly separates it from roster, standings, and player-lookup siblings. The parenthetical listing of status values (Out/Doubtful/Questionable/IR) further pins down what the resource contains.

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 scope arg is effectively a when-to-use guide: 'mine' = your roster, 'league' = every rostered player with owner, 'all' = entire NFL report, plus the conditional default. It gives clear context for each mode but never names an alternative sibling tool or states when not to call this.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only the defaulting behavior for omitted league/season, which the schema itself already states, so incremental value is limited.

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 the returned payload in the first sentence, then usage, then an arg list. No filler sentences; each element carries information.

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 takes on the burden of describing return content and does so concretely (franchises, roster size, taxi/IR, lineup requirements, weeks). Nothing essential for correct invocation is 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 coverage is 100%, so all three parameters are fully documented in the schema, including the alias/name/ID options and the enum for response_format. The description's restatement adds nothing beyond that; 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 (Get) and resource (league settings and teams) and enumerates the payload: name, franchises with ID/team name/owner/division, roster size, taxi/IR slots, lineup requirements, season weeks. An agent can distinguish it from mfl_get_roster or mfl_list_leagues without opening the schema.

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 names two use cases: mapping franchise IDs to team names, and answering league-rule/lineup questions. Clear context for when to reach for this tool, but it does not name a competing sibling (e.g. mfl_get_roster for per-player rosters) to rule out.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: results include players who have not yet played and remaining game time, which tells the agent the payload is partially-projected live data, not a settled result.

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 in one sentence, followed by a compact Args list. The Args block is largely redundant with the schema but is short and harmless; nothing is padded or buried.

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 annotations covering the safety profile, no required parameters, and no output schema, the definition supplies enough to invoke correctly: scope, defaults for all four optional params, and the markdown/json output switch. Only the routing rationale versus similarly named siblings is 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 every parameter is already documented in the schema. The Args block essentially restates week/league/season/response_format without adding format, constraint, or resolution detail beyond it, 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 verb (get) and resource (live/final fantasy scores for every matchup in a week), plus notable scope detail (players yet to play, game time remaining). It distinguishes the live-scoring nature from statically-oriented siblings like mfl_get_player_scores, but never names an alternative 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?

Gives implied context (omit week for the current week, omit league/season for defaults) but never states when to prefer this over mfl_get_player_scores or mfl_get_standings. Usage is inferable from the purpose rather than spelled out.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavior context beyond that: include_ownership triggers 'one extra API call', sort:'points' adds a points column and ranks under league scoring, and season selects that year's player database.

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 summary sentence followed by returns, then a per-arg list and two example call shapes. The arg bullets largely restate the 100%-covered schema, which is wasted length, but the added examples ('bijan', 'RB,WR') and defaults earn most of it back.

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 the return burden itself and does so: it enumerates returned fields (ID, name, position, team, age, draft year/round/pick, college, ownership), documents defaults for limit/offset/sort/response_format, and warns about the unfiltered result size.

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 baseline is 3; the description still adds value with concrete formats and semantics ('FA' = NFL free agent, owner accepts 'mine'/franchise ID/team name/'available', rookies_only keyed to the selected season). Only mild redundancy with the schema keeps this from a 5.

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 (search) and resource (MFL's player database) with explicit scope: all NFL players, offense and IDP. It also names the return fields and the primary downstream use (find player IDs for other tools), so an agent can distinguish it from mfl_get_roster or mfl_get_free_agents at a glance.

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 strong when-to-use context: 'at least one filter is recommended; the full database has thousands of players' plus two worked filter combinations for common intents. It falls short of naming when to prefer a sibling such as mfl_get_free_agents, whose purpose overlaps with owner:'available'.

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, idempotentHint, openWorldHint and non-destructive, so the safety profile is fully covered. The description adds the default period (ytd), default limit (25), and the ID-lookup cross-reference, but discloses nothing about result ordering, pagination behavior, or scoring-rule edge cases.

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 one-sentence purpose followed by a compact Args list; no filler sentences. The Args block is somewhat redundant with the 100%-covered schema but remains scannable and each line maps to a real parameter.

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 10-parameter, all-optional read tool with a full input schema, no output schema, and complete annotations, the description supplies everything needed to invoke it correctly, including period/week coupling and the default response format.

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 all 10 parameters, and the Args block largely restates it. The only added value beyond the schema is the cross-reference to mfl_get_players for player IDs and the 'mine' shorthand for franchise, which is marginal.

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 (Get) plus resource (fantasy points under the league's scoring rules) and the three temporal scopes (week/ytd/avg). It does not differentiate itself from siblings like mfl_get_live_scoring, so an agent must infer the boundary, but the purpose itself is unambiguous.

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 description lists filtering options (franchise, players, position) and notes mfl_get_players for ID lookup, which implies usage. However it never states when to prefer this over mfl_get_live_scoring or mfl_get_roster, and gives no explicit when-not conditions.

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/idempotentHint/openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the franchise defaulting rule, the season-override semantics for retrieving historical rosters, and the conditional presence of salary/contract fields ('when the league uses them').

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 purpose and default behavior, and the examples earn their space by showing argument composition. The Args block largely restates the JSON schema descriptions verbatim, which is mild redundancy that keeps it from a 5.

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 7 optional parameters, no output schema, and a conditional-field payload, the description compensates by enumerating the returned fields and documenting defaults and history access. Nothing needed to call it correctly is 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 coverage is 100%, so the baseline is 3, but the description goes further by decoding the polymorphic 'franchise' parameter into four accepted forms and by mapping natural-language queries to concrete argument combinations in the examples ('Who has the most linebackers?' -> { franchise: 'all', position: 'LB' }).

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?

Specific verb+resource ('Get the players on a franchise's roster (or every roster in the league)') plus an enumeration of the exact returned fields (name, position, NFL team, age, roster status, salary/contract). The scope statement implicitly separates it from siblings like mfl_get_players (whole player universe) and mfl_get_free_agents (unrostered players).

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?

States the default behavior ('Defaults to YOUR franchise when one is configured') and gives explicit conditions selecting alternatives ('Use franchise="all" to see every team' for ownership questions, trade targets, positional depth; 'Use season to see a previous season's final rosters'). No explicit exclusions against sibling tools, but the usage context is clear.

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, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered. The description usefully notes that scores/results apply to completed weeks, but it contradicts the schema by saying omitting week returns the full season (schema says current week), which undermines confidence.

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 front-loaded and readable, but the Args block largely duplicates a schema that already has 100% description coverage, adding length without new information.

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 should carry more of the return-value burden; it only says scores and results for completed weeks and mentions a markdown/json format. The contradictory week-omission guidance leaves a key behavior unclear.

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 would be 3, but the description actively conflicts with the schema on the week parameter ('Omit for the full season' vs schema's 'Omit for the current week'). That contradiction makes it worse than simply repeating 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 description names a specific verb and resource (get fantasy matchups) and scopes it by week and completed-week results. It is clearly distinct from siblings like standings, roster, or player scores, though it never explicitly names an alternative tool.

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 per-parameter usage hints (omit week for full season, franchise accepts 'mine'/ID/name, response_format default) but offers no explicit when-to-use/when-not guidance relative to tools like mfl_get_live_scoring. Usage is implied rather than stated.

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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the markdown layout is one table per division ranked within division followed by the overall table, and that extra league-tracked columns may appear. Return-format behavior like this is exactly the value-add expected when annotations carry the rest.

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 what the tool returns, then the non-obvious division-table behavior, then a compact Args list. No filler sentences, though the Args block partially duplicates the fully-described schema.

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 carries the return-value burden itself and does so: it names the stat columns and explains the per-division versus overall markdown structure. With all three parameters optional and fully schema-documented, an agent has everything needed to call it 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% and every parameter is documented in the schema, including the league alias/name/ID options and the season default. The Args block mostly restates that plus the response_format enum values, adding a pointer to mfl_list_leagues but little semantic detail the schema lacks. 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?

States a precise verb+resource ('Get league standings') and enumerates exactly which metrics come back (head-to-head record, points for/against, division record, streak, extra columns). An agent knows what it will receive, though it doesn't explicitly differentiate from potentially overlapping siblings like mfl_get_live_scoring or mfl_get_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 a concrete when-to-use signal: for division standings questions, this single tool suffices because markdown emits one table per division plus an overall table. It also routes the agent to mfl_list_leagues for league/season arguments. What's missing is any explicit statement of when NOT to use it (e.g., live/in-progress scoring).

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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely non-structured context: results are rendered in plain English with resolved player names and decoded draft picks, and that `count` caps total output. It does not discuss pagination or truncation behavior beyond the count cap.

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 purpose, then a compact arg list, then two examples — each section earns its place and there is no filler. The arg list duplicates the schema somewhat, which keeps it from a perfect score.

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 zero-required-parameter, read-only query tool with rich annotations and a fully documented schema, the description covers purpose, filters, output format, and result rendering. With no output schema, the note about plain-English rendering and decoded draft picks fills the main gap; remaining omissions (pagination, empty-result behavior) are minor.

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 all seven parameters are already documented in the schema, and the description's arg list largely restates that (enum values, count range, defaults). The examples do add a little semantic value by showing how `franchise` accepts a team name and how filters combine, but the baseline of 3 applies 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?

The description opens with a specific verb and resource ('Get recent league transactions') and enumerates the transaction categories it covers (trades, adds/drops, waivers, IR, taxi). It also notes the output is 'plain English, with player names and decoded draft picks,' which is a real distinguishing trait. It stops short of naming which sibling (e.g., mfl_get_free_agents) to use instead for overlapping queries.

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?

Two worked examples map natural-language questions ('Any trades this week?', 'What has Team X added lately?') directly onto argument combinations, which is strong usage guidance for an agent. There is no explicit when-not-to-use statement or pointer to a sibling for free-agent lookups, so it falls 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 declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful context beyond them: the precise returned fields and the security guarantee that API keys are never returned. It stops short of describing ordering or error behavior, so a 4 rather than 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?

Front-loaded with purpose, then the when-to-use triggers, then args — a sound order with no wasted prose. The Args block duplicates the schema's own description nearly verbatim, which is minor redundancy rather than a structural flaw.

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 present, the description compensates by enumerating the returned fields and their meaning, and it covers triggers, safety, and defaults. An agent has everything needed to call and interpret this 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% and the single parameter is fully documented with default and enum, so the schema carries this dimension. The description's Args section merely repeats response_format without adding format-specific syntax or guidance, 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?

Specific verb (list) + resource (MFL leagues/seasons) plus the exact fields returned (alias, league ID, franchise ID, seasons with API key, default league). This clearly separates it from siblings like mfl_get_league or mfl_get_standings, which fetch league content rather than server configuration.

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 states when to call it: first when the user names a league by nickname, references 'last season', or when another tool reports an unknown league or missing API key. This is a concrete when-to-use rule coupled to observable triggers, not vague advice.

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