Verified NFL stats and Sleeper league context. Every figure carries its own source rank.
Scored across 15 tools
Most tools have clearly distinct purposes, but there is a cluster of overlapping metric-discovery and lookup tools: list_metrics (what Muffed can answer on) versus search_metrics (metrics matching a topic) largely overlap, and query_stat_leaders versus run_stat_query both return leaders on a metric (pre-computed vs computed). The descriptions do enough to disambiguate them for a careful agent, but the boundaries require reading.
Nearly all tools use snake_case verb_noun, with a consistent 'sleeper_' namespace grouping the five Sleeper tools. Minor deviations exist within that namespace (sleeper_roster_stories, sleeper_standings_story use noun_noun rather than verb_noun), but the pattern is readable and predictable.
At 15 tools this sits squarely in the well-scoped range, with each tool covering a distinct capability (metric discovery, entity lookup, computed queries, comparison, Sleeper fantasy integration, claim verification). Nothing appears redundant or padded.
The surface broadly covers the stated purpose: metric discovery/definition, entity metrics, leaders, ad-hoc queries, comparison, Sleeper league/roster/matchup views, and claim verification. Minor gaps remain (no explicit player/team search or bio/schedule endpoint), but core NFL-stats and fantasy workflows are covered.
Two players or two teams shown side by side — by default on the metrics that matter for their position, on named metrics when metrics is set, and on the full set with all:true. Each side carries its source rank. States both figures and stops: it names no winner, no margin and no recommendation. metrics takes verified panel metric keys ("qb_anya.any_a") or their plain-English names. A measure outside the verified panel, such as yards per attempt, is refused with the nearest panel metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| all | No | ||
| season | No | ||
| metrics | No | ||
| entity_kind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses non-obvious behavior well beyond the readOnly/idempotent annotations: it names no winner, no margin, no recommendation, each side carries its source rank, and out-of-panel measures (e.g. yards per attempt) are refused with nearest panel metrics. That refusal/error contract and the deliberate absence of a verdict are exactly what an agent needs before calling.
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 comparison behavior and packed with signal in three dense sentences. The em-dash clauses in the first sentence and the un-backticked `all:true` slightly reduce scannability, but there is little 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?
No output schema and no parameter descriptions exist, so the description carries the burden, and it covers default behavior, metric input format, and refusal handling thoroughly. The gaps are the undocumented `season` parameter and the assumed semantics of `a`/`b`, which keep it from being fully 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?
With 0% schema description coverage, the description must compensate. It explains `metrics` well (verified keys like "qb_anya.any_a" or plain-English names, max context) and `all` by implication, but never mentions `season` (2016–2026 constraint) and only implies `a`, `b`, and `entity_kind` via "two players or two teams." Partial compensation, so a 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 (compare) and resource (two players or two teams), plus the exact scope of the comparison (position-relevant metrics by default). An agent can immediately distinguish it from get_entity_metrics or query_stat_leaders, which fetch rather than compare side by side.
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 spells out the three operating modes and the condition that selects each — default, when `metrics` is set, and with `all:true` — which is clear usage context. It stops short of naming when to prefer this over siblings like get_entity_metrics, so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Muffed's published handcuff page for one team's backfield, plus the current depth chart and injury status from Sleeper. Answers who backs up a starter, and who replaces one who is out.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate read-only, idempotent, and open-world behavior, the description adds value by specifying data sources (Muffed's handcuff page and Sleeper) and the exact content (depth chart, injury status). This goes beyond the structured annotations and helps set expectations without contradiction.
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 two sentences, front-loaded with the core purpose and data sources, and includes a practical use-case question. Every phrase contributes meaning without redundancy.
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?
Given the single parameter, no output schema, and rich annotations, the description adequately explains what the tool does and what it returns. It could mention the response format or structure, but for a simple lookup tool the provided context is sufficient to understand and invoke it.
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?
The schema has one parameter 'team' with a full enum of NFL team codes but no property description. The tool description clarifies that the parameter selects a single team's backfield, which is sufficient compensation. The enum itself provides the allowed values, so the meaning is clear.
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 clearly states the tool's function: it retrieves a team's backfield handcuff information, depth chart, and injury status. It uses specific verbs like 'answers' and identifies the resource as a specific team's backfield, distinguishing it from sibling tools focused on leagues, players, or metrics.
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 implicitly defines when to use the tool (to find backup running backs and replacements for injured starters). It does not explicitly name alternatives or exclusions, but the context is clear and distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Muffed's published editorial reads on what is real in the NFL right now — each one a dated, sourced claim with its supporting figures, from the /trends board.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| subject | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is covered. The description adds valuable behavioral context: insights are 'dated, sourced claim with its supporting figures,' which gives the agent a better understanding of the returned data structure and provenance, despite no mention of auth or rate 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?
The description is a single, well-structured sentence that is front-loaded with the main subject and provides essential information without unnecessary words. It is concise and directly conveys the tool's purpose and source.
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?
The tool is relatively simple with two optional parameters and no output schema. The description gives a good overview of the data content but misses parameter semantics and does not describe the return format or how limit/subject affect results. This is adequate but leaves room for improvement.
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 0%, and the description does not mention the parameters (limit, subject) at all. Since there are two optional parameters, the description fails to explain their meaning or usage, leaving the agent to infer from the schema alone. This is a significant gap.
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 clearly identifies the tool's purpose: retrieving Muffed's published editorial reads on the current NFL state. It specifies the resource ('editorial reads', '/trends board') and the nature of the content ('dated, sourced claim with its supporting figures'), distinguishing it from sibling tools focused on metrics, backfield data, or league info.
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 implies usage in the context of wanting current editorial insights from Muffed, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. There is no reference to other tools (e.g., for metrics use get_player_metrics), so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The verified figures Muffed holds for one NFL player or one NFL team (by name or abbreviation, e.g. "Bijan Robinson" or "DEN"), with the source's rank where one exists. By default the headline figures for that player or team; scope "all" returns every figure held, and a named metric returns all of that metric's rows. Names are resolved against the players and teams Muffed holds; an unrecognised name returns the closest matches rather than a guess.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| entity | Yes | ||
| metric | No | ||
| season | No | ||
| entity_kind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavior: unrecognised names return the closest matches rather than a guess, headline vs all vs named-metric semantics, and that a source rank is included where one exists. That is meaningful disclosure beyond the 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?
Three sentences, front-loaded with the core purpose, then scope behavior, then name resolution. Dense but every clause carries information; no filler or repeated name/title material.
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 does compensate: it describes what comes back for each scope mode, that rows may carry a source rank, and how unknown names are handled. The undocumented season parameter and the lack of any note on result limits keep 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 0% across 5 parameters, so the description carries the burden. It covers entity (with examples), scope (headline/all/named metric) and implies entity_kind via 'one NFL player or one NFL team', but gives no meaning for params like season or the accepted metric identifier syntax, leaving documented gaps.
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: returns the verified figures Muffed holds for one NFL player or team. An agent can distinguish this from query_stat_leaders or run_stat_query, but the description never explicitly contrasts itself with those siblings, 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?
It explains how to address the entity (name or abbreviation, with concrete examples) and what the scope modes do, which is useful usage context. However there is no explicit when-to-use/when-not guidance versus compare_entities, query_stat_leaders or run_stat_query, so the agent must infer which retrieval tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Muffed's published definition of a verified metric — what it measures, in plain language, from the glossary page for that term — plus which seasons it actually covers, how it is ranked, its licence and its attribution. Accepts a metric key or a common name ("cpoe", "rushing yards over expected"). Season coverage is often narrower than a decade — rushing yards over expectation exists from 2018 onward.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds valuable context about the content returned (definition, seasons, ranking, licence, attribution) and warns that season coverage is often narrower than a decade. This goes beyond the structured 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?
The description is two sentences, front-loaded with the core purpose. The second sentence adds a concrete example and a practical caveat about season coverage. No wasted words.
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-parameter lookup with no output schema, the description covers what the tool returns, accepted input formats, and a data limitation. This is complete enough for an agent to select and invoke the 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?
The input schema only defines `metric` as a string with zero description. The description compensates by explaining it accepts a metric key or common name, with examples ('cpoe', 'rushing yards over expected'), giving clear guidance that the schema lacks.
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 clearly states the tool returns a metric's published definition, including its meaning, coverage, ranking, licence, and attribution. This distinct verb+resource purpose differentiates it from siblings like list_metrics or get_entity_metrics.
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 provides clear context on what the tool does and how to specify the metric (key or common name), but does not explicitly mention when not to use it or name alternative tools. It implies usage for looking up definition details, which is sufficient for a simple lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Muffed can answer on. By default a summary of metric families with their counts and season coverage; with search or detail:true, individual metric keys. Returns keys and coverage only, never figures.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | ||
| search | No | ||
| season | No | ||
| entity_kind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: the default vs detail return shapes and the important constraint that it "Returns keys and coverage only, never figures." That negative guarantee is exactly the kind of info an agent needs to avoid misusing the 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?
Two tight sentences with the core behavior front-loaded (what it catalogs), followed by the mode behavior and the return constraint. Little waste, though the opening phrase is slightly opaque.
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 annotated read-only listing tool with no output schema, the description adequately explains what is returned and in which mode. The gaps are the undocumented filtering parameters (season, entity_kind, limit), which an agent would need to filter the catalog meaningfully.
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 0% across 5 parameters, so the description carries the full burden. It documents only two of them (search, detail) and their effect on output; limit, season, and entity_kind are left entirely unexplained by both schema and description.
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 conveys that this surfaces the metric catalog ("What Muffed can answer on") and describes two output modes, default family summaries vs individual metric keys. However it never uses a clean verb+resource framing and relies on the undefined term "Muffed," so the purpose is inferable rather than stated crisply.
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 explains mode selection (default summary vs search/detail:true for individual keys), which is helpful conditional guidance. But it names no alternatives among siblings like search_metrics or get_metric_definition and gives no explicit when-to-use/when-not-to-use, 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.
Top entities on one verified metric for one season, pre-sorted, each with the source's own rank and the population it was ranked against. Takes a verified panel metric key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order | No | ||
| metric | Yes | ||
| season | No | ||
| position | No | ||
| entity_kind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds useful behavior: results are pre-sorted and each row carries the source's own rank and the comparison population, but it omits defaults for limit/order and any pagination or error behavior.
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 tight sentences, front-loaded with the core operation before the input requirement. No wasted wording, though it is brief enough to leave key semantics unstated.
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 6 parameters, 0% schema coverage, no output schema, and only 1 required field, the description is too thin: it explains the general shape of the result but not the filter parameters or enum meanings needed to invoke the 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 0%, so the description must carry the param burden, yet it only implies metric and season. limit, order, position, and especially the 10-value entity_kind enum are left entirely unexplained, so an agent cannot reliably use half the parameters.
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 operation: 'Top entities on one verified metric for one season,' which is a clear verb+resource and implies a leaderboard/ranking tool. It does not explicitly contrast with siblings like run_stat_query or get_entity_metrics, so the boundary is only partially drawn.
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?
'Takes a verified panel metric key' implies a prerequisite (the metric must be verified/panel-scoped), which hints at when this tool applies. However, it never states when to choose this over run_stat_query or get_entity_metrics, leaving the selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes an NFL figure from a structured query rather than looking one up: a population (position, qualifying threshold), a window (seasons, weeks, a team span, a coach's tenure), one named measure, and one operation (leaders, rank, count, only-who, a per-season streak, or a share of a total). Answers questions the verified panel has no pre-computed row for — qualified superlatives, multi-season streaks, derived rates. Every response carries the executed method, the population size, the measure's definition and the data version it ran against. Figures are computed on request from nflverse data and are labelled as computed, not verified. A figure that cannot be served comes back with the reason and the nearest thing covered.
Fantasy measures answer in the convention scoring names — "standard", "half_ppr" or "ppr" — and default to half-PPR when none is named; the response says which it used. A bare "PPR" means full PPR.
measure.key takes a measure name ("rushing_yards", "half_ppr_points") or a verified panel metric key ("key_player_stats.rushing.yards", "fantasy_scoring.half_ppr_points"). A panel metric key this tool does not compute is refused with the reason.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | ||
| window | Yes | ||
| measure | Yes | ||
| scoring | No | ||
| population | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/idempotent/non-destructive, closed-world), the description discloses what each response carries (executed method, population size, measure definition, data version), that figures are labeled computed-not-verified, that failures return a reason plus the nearest covered result, and the scoring default (half-PPR) with its reporting behavior. This is substantial behavioral context the annotations do not supply.
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 purpose and the panel-vs-computed distinction, then adds the response contract and scoring convention. Dense and nearly waste-free, though the scoring-paragraph and negative-lookup details could be tightened slightly.
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 tool with a very large nested schema, no output schema, and zero schema descriptions, the description covers purpose, response shape, scoring semantics, and failure behavior well. The remaining gap is enumerating the less obvious op/part kinds, which an agent must infer from the schema's const values alone.
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 0%, so the description carries the full parameter burden, which it largely does: it explains measure.key's accepted forms (measure name vs. verified panel metric key), the population (position, qualifying threshold), the window (seasons, weeks, team span, coach tenure), and the operation families. It does not cover every op variant (delta_between_seasons, rank_change, count_weeks_where, longest_streak, share_of parts), leaving some nested branches undocumented.
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 (computes) and resource (an NFL figure) and explicitly frames it as a query-driven computation rather than a lookup, distinguishing it from the pre-computed verified panel and, by implication, siblings like query_stat_leaders and get_entity_metrics. An agent can identify the tool's role 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?
Gives clear conditions for use — 'answers questions the verified panel has no pre-computed row for' with concrete examples (qualified superlatives, multi-season streaks, derived rates) — and notes that unserved figures return a reason plus the nearest covered alternative. It stops short of naming specific sibling tools (e.g. query_stat_leaders, get_entity_metrics) as the preferred alternatives, so routing is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The verified metrics that match a topic — e.g. 'screens', 'blitz', 'time to throw' — ranked by a text match over each metric's key, label, common names and board description. Up to 20 entries, each with its key, subject, season coverage and the board it belongs to. Keys and coverage only, never figures.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| season | No | ||
| subject | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real behavioral context — a hard cap of 20 results and the notable constraint 'Keys and coverage only, never figures'. It does not state what happens when nothing matches.
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, front-loaded with the core action and ranking basis, with the result shape in the second. Efficient overall, though the em-dash example list adds some bulk that could be trimmed.
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 cover the return shape (key, subject, season coverage, board) and the no-figures constraint, which is valuable. However, the near-total absence of parameter guidance leaves the agent guessing on season and subject usage for a 3-param 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 description coverage is 0% and there are 3 parameters, so the description must compensate. It explains the query semantics indirectly through examples, but says nothing about the distinct roles of 'season' and 'subject', nor about the 64-character limit or the 2016-2026 season range. Two of three parameters are effectively undocumented.
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 ('search... verified metrics') plus scope: ranked text match over key, label, common names and board description. An agent can distinguish this from list_metrics, get_metric_definition, or get_entity_metrics without opening schemas.
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 topic-based discovery use case is implied by the example queries ('screens', 'blitz', 'time to throw'), but there is no explicit statement of when to use this versus list_metrics or get_metric_definition, nor any exclusion criteria. 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.
Lists the NFL leagues a Sleeper username belongs to, with each league's id. Muffed stores nothing about the requester.
| Name | Required | Description | Default |
|---|---|---|---|
| season | No | ||
| username | Yes |
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 a genuinely non-obvious privacy note ('Muffed stores nothing about the requester'), but says nothing about rate limits, error behavior when a username doesn't exist, 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?
Two short sentences, front-loaded with the core action and zero filler. Efficient, though the trailing sentence about what Muffed stores is slightly tangential to the tool's invocation.
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 read-only lookup this is close to adequate, and annotations cover the safety profile. However, with 0% schema coverage the unexplained 'season' parameter and the absence of any output shape detail leave gaps an agent must guess at.
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 0% for two parameters. The description only implies the username input and completely ignores the optional 'season' parameter (YYYY pattern), so it does not compensate for the documentation gap in 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 states a specific verb and resource ('Lists the NFL leagues a Sleeper username belongs to') and specifies the payload ('with each league's id'). It is distinguishable from the sibling sleeper_get_league, which implies fetching one league's detail, though it never names that sibling 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?
There is no guidance on when to use this tool versus sleeper_get_league, sleeper_standings_story, or the other sleeper siblings. No prerequisites or exclusions are given, so the agent must infer usage purely from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One league's name, season, size, current week, detected scoring format, and the manager-to-roster map.
| Name | Required | Description | Default |
|---|---|---|---|
| league_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds a useful inventory of returned fields but says nothing about auth requirements, rate limits, or error behavior, so it only modestly exceeds the annotation baseline.
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 efficient sentence with no filler, leading with the resource scope before listing fields. It is slightly list-heavy as a catalog of return values rather than a purpose statement, 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 does the right thing by enumerating return fields, which is reasonably complete for a simple one-ID read. However, it omits any guidance on acquiring the league_id or on when this tool should be preferred over sibling league tools, leaving a real 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 0% and the single parameter league_id carries only a regex pattern, with no description in either the schema or the description text. The description does not explain the ID's origin (e.g., via sleeper_find_leagues) or format, so it fails to compensate for the coverage gap as required when coverage is under 50%.
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 (one league's setup) and enumerates exactly which fields are returned (name, season, size, current week, scoring format, manager-to-roster map). It implies the verb 'get' and the singular scope, which implicitly contrasts with sleeper_find_leagues, but it never explicitly differentiates itself from siblings.
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?
There is no when-to-use guidance, no prerequisites, and no reference to alternatives such as sleeper_find_leagues, which an agent would plausibly need to obtain a league_id first. Usage must be inferred entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Both sides of a league matchup, with the verified figures Muffed holds for the players involved and each team's record. Muffed does not project outcomes, name a winner, or recommend a lineup.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes | ||
| week | No | ||
| league_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent behavior, and the description adds context that this provides verified figures and doesn't make projections, which is useful for setting expectations beyond the 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?
Two sentences, front-loaded with the core purpose, and no wasted words. The description is concise and reads well.
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?
It gives purpose and boundaries, but without an output schema or parameter explanations, it's incomplete for an agent to know exactly what to expect in return or how to construct inputs properly.
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 has no descriptions (0% coverage) and the description does not explain the meaning or format of league_id, team, or week. It only implies league context, leaving the agent to infer parameter semantics.
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 clearly states the tool provides both sides of a league matchup with verified figures and team records, and explicitly distinguishes itself from projection tools by stating what it does not do. This differentiates it from sibling story/insight 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?
It implies when to use (when you need verified matchup context) and explicitly states it does not project outcomes or recommend lineups, which serves as a when-not. However, it doesn't name alternative tools for projections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One team's roster mapped to the verified figures and published Muffed surfaces for each player. Players Muffed does not cover are listed as uncovered rather than omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes | ||
| league_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context by specifying that players not covered by Muffed are listed as 'uncovered' rather than omitted, clarifying the tool's completeness behavior.
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 brief and front-loaded with the core concept. However, it relies on the unexplained term 'Muffed' and the phrase 'published Muffed surfaces' is awkward, slightly compromising clarity for conciseness.
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 and no parameter explanation, the description does not fully cover what an agent needs to know. It lacks return format, parameter semantics, and clarity on the 'Muffed' concept, though the simple structure and annotations partially compensate.
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 0%, and the description does not explain the meaning or format of league_id or team. It only vaguely references 'one team's roster' without connecting to the required parameters, leaving the agent without sufficient information to construct valid arguments.
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 clearly states the tool maps a team's roster to verified figures and published Muffed surfaces, which is a specific resource and operation. It distinguishes itself from sibling tools like sleeper_get_league or sleeper_standings_story by focusing on roster-specific data, though the term 'Muffed' is unexplained.
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?
No guidance is given for when to use this tool versus alternatives. The description implies input via league_id and team but does not state prerequisites, exclusions, or when other Sleeper tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
League standings derived from Sleeper's roster settings — records, points for, and points against where available. Sleeper publishes no standings endpoint, so these are computed from the roster rows.
| Name | Required | Description | Default |
|---|---|---|---|
| league_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safety (readOnlyHint, idempotentHint, destructiveHint=false). The description adds valuable transparency by explaining that standings are computed from roster rows and that points against may not always be available ('where available'). This helps the agent understand data derivation and potential limitations, exceeding the annotation baseline.
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 two sentences long, front-loaded with the core purpose, and immediately followed by a brief explanatory note about the derivation method. Every word earns its place; there is no redundancy or 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?
Given the tool's simplicity (one parameter, no output schema, strong annotations), the description is complete. It explains the computation method, the data fields returned, and a limitation ('where available'). With no output schema, it successfully summarizes the return content. This is sufficient for an agent to use the tool effectively.
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?
The schema has 0% description coverage, so the description must compensate. However, it never mentions the required league_id parameter or its role. The parameter name is self-explanatory, but the description adds no meaning beyond the schema, leaving the agent without explicit guidance on what input to provide or expected formats.
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 clearly states the tool's function: computing league standings from roster settings, specifying the output (records, points for, points against). It also distinguishes itself from siblings by explaining that Sleeper has no standings endpoint, so these are derived from roster rows. This is a specific verb+resource with clear scope.
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 provides clear context for when to use the tool: whenever league standings are needed, because Sleeper does not provide a direct endpoint. It implies the tool is the appropriate choice for this purpose, though it does not explicitly reference alternative tools or exclusions. The context is clear and no misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks structured claims against Muffed's verified panel. Each claim comes back confirmed, wrong (with the actual value), or unverifiable (with the metric's real season coverage). Takes structured fields only, not sentences.
| Name | Required | Description | Default |
|---|---|---|---|
| claims | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that by explaining what each result category returns (actual value for wrong, real season coverage for unverifiable). This is helpful and consistent with the 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?
Two sentences with no filler: the first states the operation, the second explains return categories and input constraint. Key information is front-loaded, and every sentence adds value.
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?
The description explains the outcome categories well despite no output schema, and the schema covers optional season and entity_kind constraints. A small gap is the absence of an example or a fuller definition of Muffed's verified panel, but the tool is still callable correctly from the description plus schema.
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?
With schema_description_coverage at 0%, the description needed to compensate by explaining the meaning of metric, entity, and value, but it only says 'structured fields only, not sentences'. The field names and enum are present in the schema, but the description does not clarify how to populate the required claim object or what counts as a valid metric/entity.
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 clearly states the verb 'Checks' and the resource 'structured claims against Muffed's verified panel', and further specifies the three possible outcomes. It is clear, though it does not explicitly name sibling tools or contrast itself with run_stat_query/query_stat_leaders, so it stops short of full 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?
The sentence 'Takes structured fields only, not sentences' gives a concrete usage boundary and tells an agent what input form is acceptable. It does not, however, point to an alternative tool for free-text claims or explain when a sibling would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_metricscompare_entities1 field changedInput schema / properties / season / maximumPrevious value: -2025New value: +2026get_entity_metrics1 field changedInput schema / properties / season / maximumPrevious value: -2025New value: +2026list_metrics1 field changedInput schema / properties / season / maximumPrevious value: -2025New value: +2026query_stat_leaders1 field changedInput schema / properties / season / maximumPrevious value: -2025New value: +2026verify_claim1 field changedInput schema / properties / claims / items / properties / season / maximumPrevious value: -2025New value: +2026get_entity_metrics1 field changedInput schema / properties / scopeAdded value: +{
+ "enum": [
+ "headline",
+ "all"
+ ],
+ "type": "string"
+}run_stat_query1 field changedInput schema / properties / scoringAdded value: +{
+ "enum": [
+ "standard",
+ "half_ppr",
+ "ppr"
+ ],
+ "type": "string"
+}run_stat_query1 field changedInput schema / properties / op / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "k": {
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
- },
- "kind": {
- "const": "leaders",
- "type": "string"
- }
- },
- "required": [
- "kind"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "direction": {
- "enum": [
- "asc",
- "desc"
- ],
- "type": "string"
- },
- "k": {
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
- },
- "kind": {
- "const": "rank",
- "type": "string"
- }
- },
- "required": [
- "kind",
- "direction"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "count_where",
- "type": "string"
- },
- "op": {
- "enum": [
- ">=",
- ">",
- "<=",
- "<",
- "="
- ],
- "type": "string"
- },
- "value": {
- "type": "number"
- }
- },
- "required": [
- "kind",
- "op",
- "value"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "only_who",
- "type": "string"
- },
- "op": {
- "enum": [
- ">=",
- ">",
- "<=",
- "<",
- "="
- ],
- "type": "string"
- },
- "value": {
- "type": "number"
- }
- },
- "required": [
- "kind",
- "op",
- "value"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "streak_each",
- "type": "string"
- },
- "n_seasons": {
- "maximum": 10,
- "minimum": 2,
- "type": "integer"
- },
- "op": {
- "enum": [
- ">=",
- ">",
- "<=",
- "<",
- "="
- ],
- "type": "string"
- },
- "value": {
- "type": "number"
- }
- },
- "required": [
- "kind",
- "op",
- "value",
- "n_seasons"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "share_of",
- "type": "string"
- },
- "part": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "seasons",
- "type": "string"
- },
- "seasons": {
- "items": {
- "maximum": 2100,
- "minimum": 1999,
- "type": "integer"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- }
- },
- "required": [
- "kind",
- "seasons"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "last_n_seasons",
- "type": "string"
- },
- "n": {
- "maximum": 20,
- "minimum": 1,
- "type": "integer"
- }
- },
- "required": [
- "kind",
- "n"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "weeks",
- "type": "string"
- },
- "season": {
- "maximum": 2100,
- "minimum": 1999,
- "type": "integer"
- },
- "weeks": {
- "items": {
- "maximum": 23,
- "minimum": 1,
- "type": "integer"
- },
- "maxItems": 23,
- "minItems": 1,
- "type": "array"
- }
- },
- "required": [
- "kind",
- "season",
- "weeks"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "since_debut",
- "type": "string"
- }
- },
- "required": [
- "kind"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "with_team",
- "type": "string"
- },
- "seasons": {
- "items": {
- "maximum": 2100,
- "minimum": 1999,
- "type": "integer"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- "team": {
- "maxLength": 4,
- "minLength": 2,
- "type": "string"
- }
- },
- "required": [
- "kind",
- "team"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "coach": {
- "maxLength": 60,
- "minLength": 2,
- "type": "string"
- },
- "kind": {
- "const": "coach_tenure",
- "type": "string"
- },
- "team": {
- "maxLength": 4,
- "minLength": 2,
- "type": "string"
- }
- },
- "required": [
- "kind",
- "coach"
- ],
- "type": "object"
- }
- ]
- }
- },
- "required": [
- "kind",
- "part"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "k": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "kind": {
+ "const": "leaders",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "direction": {
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+ },
+ "k": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "kind": {
+ "const": "rank",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "direction"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "count_where",
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ ">=",
+ ">",
+ "<=",
+ "<",
+ "="
+ ],
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "op",
+ "value"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "only_who",
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ ">=",
+ ">",
+ "<=",
+ "<",
+ "="
+ ],
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "op",
+ "value"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "streak_each",
+ "type": "string"
+ },
+ "n_seasons": {
+ "maximum": 10,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "op": {
+ "enum": [
+ ">=",
+ ">",
+ "<=",
+ "<",
+ "="
+ ],
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "op",
+ "value",
+ "n_seasons"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "share_of",
+ "type": "string"
+ },
+ "part": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "seasons",
+ "type": "string"
+ },
+ "seasons": {
+ "items": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "seasons"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "last_n_seasons",
+ "type": "string"
+ },
+ "n": {
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "kind",
+ "n"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "weeks",
+ "type": "string"
+ },
+ "season": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ },
+ "weeks": {
+ "items": {
+ "maximum": 23,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "maxItems": 23,
+ "minItems": 1,
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "season",
+ "weeks"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "since_debut",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "with_team",
+ "type": "string"
+ },
+ "seasons": {
+ "items": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ "team": {
+ "maxLength": 4,
+ "minLength": 2,
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "team"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "coach": {
+ "maxLength": 60,
+ "minLength": 2,
+ "type": "string"
+ },
+ "kind": {
+ "const": "coach_tenure",
+ "type": "string"
+ },
+ "team": {
+ "maxLength": 4,
+ "minLength": 2,
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "coach"
+ ],
+ "type": "object"
+ }
+ ]
+ }
+ },
+ "required": [
+ "kind",
+ "part"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "k": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "kind": {
+ "const": "count_weeks_where",
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ ">=",
+ ">",
+ "<=",
+ "<",
+ "="
+ ],
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "op",
+ "value"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "longest_streak",
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ ">=",
+ ">",
+ "<=",
+ "<",
+ "="
+ ],
+ "type": "string"
+ },
+ "unit": {
+ "const": "weeks",
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "unit",
+ "op",
+ "value"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ },
+ "k": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "kind": {
+ "const": "delta_between_seasons",
+ "type": "string"
+ },
+ "to": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "kind",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ },
+ "k": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "kind": {
+ "const": "rank_change",
+ "type": "string"
+ },
+ "to": {
+ "maximum": 2100,
+ "minimum": 1999,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "kind",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ }
+]run_stat_querycompare_entities1 field changedInput schema / properties / allAdded value: +{
+ "type": "boolean"
+}list_metrics1 field changedInput schema / properties / detailAdded value: +{
+ "type": "boolean"
+}get_entity_metricsget_player_metricscompare_entitiesget_backfieldget_current_insightsget_metric_definitionget_player_metricslist_metricsquery_stat_leaderssleeper_find_leaguessleeper_get_leaguesleeper_matchup_previewsleeper_roster_storiessleeper_standings_storyverify_claimDynasty and redraft fantasy football trade values, trade grades, and Sleeper league rosters.
Fantasy analysis for your ESPN, Yahoo, and Sleeper leagues. Reads your leagues, never changes them.
Live NFL, MLB, and NBA sports intelligence: injury signals, identity resolution, projections.
nflverse — NFL play-by-play, player and team stats, schedules and injury
Add one secure layer between your agents and this server.
