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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context about the required careerid parameter and the consequence of omitting it (page cannot be addressed), which goes beyond the annotations without contradicting 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?

Two sentences, front-loaded with purpose, and no filler. Every sentence contributes either descriptive content or essential usage instruction.

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 tool with complete schema and safety annotations, the description adequately covers the page content and addressing requirements. It could be more explicit about return formatting, but 'available data' plus the listed items is sufficient for a straightforward retrieval.

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%, with both parameters fully described including the link to search's careerCanonicalUrl. The description reinforces this relationship but does not introduce new parameter semantics, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns one athlete's career page, listing specific content (season history, sports played, available data). The verb 'get' appears in the title and the resource is unambiguous, distinguishing it from sibling tools like school, team, or roster pages.

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 provides explicit instructions to pass the careerCanonicalUrl from maxpreps_search verbatim, establishing both a prerequisite and a clear workflow. It implies the tool is used after a search but does not explicitly name alternative tools or state when not to use it, which keeps it just below a 5.

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

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

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description adds critical behavioral context: the data is 'undecoded', and 'positional payloads — team rosters and schedules — arrive as bare arrays here with no field names'. It also clarifies that this works for 'any public' page, which is useful for setting expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded with the key phrase 'Escape hatch'. It contains only three sentences, each providing distinct value: purpose, usage guidance, and a specific caveat. There is no redundant or filler content.

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 escape-hatch tool with only two well-documented parameters and no output schema, the description covers the essential context: what it does, when to use it, how the raw data behaves, and when to prefer other tools. The openWorldHint and readOnlyHint annotations complement this, making the tool's behavior sufficiently clear for an agent.

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 already provides full descriptions for both parameters (path and keysOnly) with 100% coverage, so the baseline is 3. The description adds general context about the raw output format (undecoded, bare arrays) but does not directly elaborate on how to use the parameters beyond what the schema already states.

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: 'return the raw server-rendered data for any public MaxPreps page, undecoded.' It also distinguishes itself from sibling tools by presenting itself as an escape hatch for cases not covered by dedicated tools and explicitly redirects roster/schedule needs to maxpreps_get_roster / maxpreps_get_schedule.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Use when a dedicated tool does not cover what you need' and lists examples like playoff brackets, conference standings, and article listings. It also clearly states when not to use it (for rosters/schedules), naming the alternative tools.

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?

Beyond the annotations (readOnly, idempotent), the description discloses pagination (25 at a time), season default behavior (empty before sport underway), and the entry fields including `teamPath`. This adds meaningful behavioral context beyond the structured annotations, with no contradictions.

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, each sentence adds substantive detail (scope, entry contents, pagination, season behavior, read-only). No repetitive or wasted language.

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 reasonably explains what responses contain (rank, rating, record, movement, teamPath) and key behaviors like pagination and season default. It could mention empty-result handling, but overall it's complete enough for a simple read-only list.

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% with clear per-parameter descriptions. The description repeats some schema info (season default, 25 per page) and adds output-focused context about `teamPath`, but no novel parameter syntax or semantics. This aligns with the baseline for high schema coverage.

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 it returns a ranked leaderboard of teams for a sport, nationally or within a state, and positions it as the discovery mechanism. However, it does not differentiate from the sibling `maxpreps_get_team_rankings`, which appears to be a near-duplicate name, so it lacks 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?

It offers some guidance ('this is the way to discover teams rather than look one up'), implying use for discovery versus lookup. But it does not explicitly state when to use this vs alternatives like `maxpreps_get_team_rankings` or `maxpreps_list_teams`, nor any exclusions.

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?

The description discloses meaningful behavioral traits beyond annotations: soft-deleted entries are excluded by default, rosters may contain more rows than the page shows, and height/weight are null when unpublished. The read-only nature aligns with the readOnlyHint annotation, and the description adds substantial context about data quality and payload 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?

The description is four sentences, each earning its place. It front-loads the core payload, then adds behavioral caveats and a read-only note. No fluff or 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 no output schema, the description covers return fields and null behavior, and explains the soft-deleted nuance. It does not mention pagination or ordering, but for a roster-sized dataset this is acceptable. The parameter schema covers the rest. Overall, it is well-rounded for the tool's complexity.

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 adds value by explaining the impact of includeDeleted (soft-deleted exclusion default) and reinforcing that 'season' is per-season. It also clarifies that height/weight can be null, which relates to the data returned. This goes beyond the schema descriptions.

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 retrieves players on a team for one season with specific fields (jersey, name, class year, positions, height, weight). This is a specific verb+resource+scope, and it distinguishes the roster tool from siblings like athlete, schedule, and team 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?

The description provides context about default behavior (soft-deleted entries excluded) but does not explicitly state when to use this tool versus alternatives such as maxpreps_get_athlete or maxpreps_get_team. No 'when-not' or alternative tool guidance is given, leaving the agent to infer usage from the tool name and purpose.

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?

The description goes well beyond the annotations by explaining the score orientation (teamScore/opponentScore vs. winner-first resultString), the default hiding of soft-deleted contests, and the inclusion of playoff/championship tournaments. It also notes the legitimate no-results case for a current season. These are valuable behavioral details that annotations alone do not convey.

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 compact paragraph where every sentence adds value: core purpose, score semantics, soft-delete behavior, season-timing caveat, and tournament inclusion. The final 'Read-only' is redundant with the annotation but harmless. It is well-structured and front-loaded with the primary use case.

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?

Despite having no output schema, the description clearly explains what the tool returns (games, scores, tournaments) and reveals important edge cases (soft-deleted contests, season timing). This gives an agent enough context to invoke the tool correctly and interpret results, making it complete for its complexity.

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 already provides 100% coverage with descriptions for all five parameters, so the baseline is 3. The description does not add much parameter-specific semantics, though its clarification of score orientation indirectly helps interpret the 'played' filter (e.g., what counts as a result). Overall, 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 'Every game for a team season, with the result and both scores,' which clearly identifies the tool as returning a schedule with scores. It distinguishes itself from siblings by focusing on schedule-specific details like score orientation and tournament entries, making it unmistakable among the other MaxPreps 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?

The description provides a clear context for when to use this tool (to get a team's schedule and scores) and includes a practical caveat about checking a prior season if the current one has no results pre-opening day. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough to infer the appropriate use case.

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, openWorldHint, and idempotentHint. The description adds 'Read-only' (redundant with annotation) and the input dependency on a search path, plus the specific content returned (nearby schools, articles/videos). This provides useful behavioral context 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 primary purpose and details, and includes a direct usage hint. Every word earns its place with no filler or repetition.

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 appropriately lists the main content groups of the profile. It also specifies the required input origin. It could mention error handling or exact field details, but for a read-only profile tool with simple parameters, it is largely 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?

Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds extra meaning by tying the 'school' parameter to 'maxpreps_search' and mentioning 'nearby schools' for the includeNearby flag, which reinforces how to use them.

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 resource ('School profile') and lists its components (identifiers, location, state athletic association, partner flags, nearby schools, recent articles/videos). This distinguishes it from sibling tools like maxpreps_get_team and maxpreps_get_athlete, which target different entities.

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 instructs users to 'Take the path from maxpreps_search', providing explicit guidance on how to obtain the required input. It does not explicitly exclude alternatives or state when not to use the tool, but the 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, and openWorldHint, covering the safety profile. The description adds context about the output scope (conference-wide vs team-specific) and the inclusion of statistical leaders, but does not disclose other behavioral traits like data volume, pagination, or refresh behavior. With annotations present, this is adequate but not exceptional.

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 tightly written in two sentences. The first sentence delivers the core purpose and differentiator, the second adds the secondary feature (statistical leaders) and the read-only nature. No wasted words, every sentence earns its place.

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 no output schema, the description does a good job explaining what the tool returns (standings with records/placement, plus statistical leaders). It does not mention any additional return details like format or ordering, but for a straightforward lookup tool, this is sufficient. Sibling tools like maxpreps_get_team are referenced, providing helpful context.

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% — both parameters (team, season) are fully described in the schema with types and examples. The description does not add additional meaning or usage details beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly identifies the tool's function: returning the conference standings table with all teams' records and placement. It explicitly distinguishes from maxpreps_get_team by noting the scope difference. The verb 'returns' and resource 'standings table' are specific and 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?

Provides clear context for when to use this tool over maxpreps_get_team ('not just this team's own line'), which is an explicit alternative. However, it does not discuss when to use it versus maxpreps_get_stat_leaders for the statistical leaders portion, leaving a minor gap in guidance for that secondary feature.

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, openWorldHint, and idempotentHint. The description adds meaningful behavioral context: rows are returned undecoded with a warning if MaxPreps changes the row shape, preventing mislabeling, and it clarifies the content of each entry (stat line, school, teamPath). This goes beyond the annotations without contradicting 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?

Three sentences, each with a distinct purpose: purpose/return shape, parameter sourcing guidance, and error-handling behavior. 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?

With no output schema, the description effectively covers the return shape (athletes, stat line, school, teamPath), the scope (state or national, up to 200), the source of `path`, and fault behavior. It provides enough context for an agent to select and use 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 100%, so the baseline is 3. The description reinforces that `path` should come from `maxpreps_list_stat_categories` and gives an example in the schema, but it adds no additional semantics beyond what the schema already provides for either `path` or `limit`.

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 ranked athletes for one statistical category across a state or nationally, with full stat lines and a teamPath. This is a specific verb+resource+scope, and the mention of taking `path` from maxpreps_list_stat_categories distinguishes it from sibling tools that might construct paths or return broader leaderboards.

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 explicitly instructs users to take `path` from `maxpreps_list_stat_categories` rather than constructing it, which is clear usage guidance tied to a sibling tool. It does not explicitly contrast with `maxpreps_get_stat_leaders` or other alternatives, so it lacks a full when-not-to-use statement.

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/openWorld/idempotent hints, so the 'Read-only' line is redundant. But the description adds substantial behavioral detail beyond annotations: it discloses return payload components (qualifying minimums, refresh time) and explains coverage variability and empty-result semantics.

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 exactly two sentences, front-loaded with the primary return value, followed by the important edge-case behavior. Every sentence 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?

With no output schema, the description does an excellent job of explaining what is returned (athlete entries, minimums, refresh time) and how to interpret empty results. The tool is simple (2 params, 1 required), and the description fully covers its use and behavior.

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%: both team and season have descriptive examples in the input schema. The description adds no extra parameter-level guidance beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('get') and resource ('team stat leaders'), then elaborates with the exact contents of each entry: athlete, stat, value, and athlete career URL. The phrase 'for a team season' distinguishes it from the sibling stat leaderboard 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?

The description implies a clear use case (retrieving team-season stat leaders) and provides helpful context that empty results are normal. However, it does not explicitly name alternatives like maxpreps_get_stat_leaderboard or state when to prefer this tool over them, so while context is clear, exclusions are absent.

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, openWorldHint, and idempotentHint. The description adds 'roughly 20 years' of season history and the read-only reassurance, but largely repeats annotation info. It does not add details on errors, data freshness, or other behavioral caveats, matching the baseline for annotation-backed tools.

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 concise sentences: the first lists the data content, the second gives a clear use case. No filler or 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?

Without an output schema, the description enumerates returned data categories (record, standings, rankings, season list) which is adequate for a read-only overview. It does not explain response formatting or error handling, but for a simple 3-parameter tool with rich annotations, it is sufficiently 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?

Input schema covers all three parameters with full descriptions (100% coverage). The description does not add parameter-specific semantics beyond mentioning season in the overview; the schema already explains team path, season pattern, and includeSeasons.

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 identifies a specific resource (team season) and enumerates exact contents: identifiers, win-loss record, points for/against, conference standing, rankings, and season list. It also distinguishes from schedule by noting it confirms a record without summing a schedule.

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 an explicit use case: 'Use it to confirm a record without summing a schedule.' It does not explicitly state when not to use or mention alternative tools for standings/rankings, but the purpose and context are clear enough for an agent to select this tool appropriately.

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, openWorldHint, and idempotentHint. The description adds behavioral context beyond these by explaining the output includes surrounding teams and typical ranking categories, which is useful for an agent predicting the tool's behavior. It does not fully disclose every detail but adds meaningful context.

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, followed by usage guidance and a read-only note. No redundancy or filler; each sentence earns its place.

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 tool with two well-documented parameters and no output schema, the description conveys what the return data represents (rankings and surrounding teams) and typical ranking categories. Combined with annotations and schema, the agent has sufficient context to invoke and interpret results.

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% with descriptive comments for both parameters (team, season). The description adds no new parameter-specific semantics beyond clarifying that 'team' refers to a single team, which is already implied. Baseline 3 is appropriate when the schema fully documents 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?

The description clearly states that the tool returns a single team's rankings across multiple categories (national, state, division, metro) plus adjacent teams. It distinguishes itself from the sibling maxpreps_get_rankings by explicitly saying it's for 'how good is this team' rather than browsing a leaderboard.

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 usage guidance is given: 'Use this for "how good is this team"; use maxpreps_get_rankings to browse a whole leaderboard.' This names the alternative tool and provides clear decision criteria, satisfying the when-and-when-not requirement.

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 declare readOnlyHint=true and openWorldHint=true. Description adds that it reports a failure rather than throwing, and that no credentials are required, which are useful behavioral details 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, each adding specific value: build ID dependency, real-route probing, and error behavior plus credentials. No redundant or filler content.

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-parameter health check, the description covers reachability, build ID, real-route probing, failure behavior, and credentials. It does not specify the success return format, but that is minor given the tool's simplicity.

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 tool has zero parameters, so the schema is empty. The description explains what the health check covers but no parameter semantics are needed; the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies MaxPreps reachability and build ID resolution, and probes a real data route. This distinguishes it from sibling data-retrieval tools as a health check.

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 'a pass means tools will work' implies using this as a pre-check before other tools. However, it does not explicitly mention when not to use or alternatives, but 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=true and idempotentHint=true, and the description adds the important behavioral fact that the returned path is required for subsequent calls because it cannot be inferred. The description also mentions the output includes averages and minimums, but does not discuss pagination or response size; however, for a read-only list operation the added context is valuable 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?

The description is two sentences, front-loaded with the core purpose and enriched with a concrete dependency note and path examples. Every clause adds value; no filler or repetition beyond the single 'Read-only' tag that mirrors the annotation, which is acceptable.

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 listing tool with 3 well-documented parameters and no output schema, the description tells the agent what the response will contain (categories, paths, averages, minimum games) and why the tool is necessary. It does not specify the exact response shape, but given the tool's simplicity and the absence of an output schema, this is sufficient for correct invocation.

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 parameters are already well-documented (sport slug, optional state, optional season). The description adds no new parameter-level semantics—it only mentions path examples for leaderboard categories, not for the input parameters. This meets the baseline but does not exceed it.

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 specifies that this tool lists the available stat leaderboard categories for a sport, including paths, averages, and minimum games played. It explicitly names the follow-up tool maxpreps_get_stat_leaderboard, distinguishing itself from the sibling tool that retrieves actual leaderboard data.

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 provides explicit usage guidance: 'Call this before maxpreps_get_stat_leaderboard' and explains why the leaf path is not derivable from the stat name, giving concrete examples. This tells the agent exactly when to use this tool and establishes a dependency, which is stronger than typical sibling differentiation.

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 declare readOnly, idempotent, and openWorld hints, so the safety profile is already known. The description adds valuable behavioral context: the sport path segment structure varies by sport (e.g., girls golf vs boys golf) and field hockey has no gender segment, plus the dual behavior when a team path is passed instead of a school path. This goes 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?

The description is compact yet packed with essential information. It front-loads the core purpose and uses examples to clarify non-obvious path conventions. No superfluous sentences.

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 three parameters and no output schema, the description explains the return content (team paths with sport, gender, level) and the important input variation (school vs team path). It provides enough context for the agent to use the tool correctly, including the non-obvious gender path segments.

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 covers 100% of parameters (school, sport, level). The description adds semantic depth by explaining that sport path segments are not guessable due to gender defaults varying by sport, providing concrete examples. It also clarifies that the school parameter accepts a school site path or URL, and that passing a team path changes the return to that team's seasons.

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 lists a school's teams with sport, gender, and level, and distinguishes it from sibling tools by explaining that team path segments are not guessable, making it the necessary precursor to other team 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 explicitly instructs 'Call this before any team tool' and explains why (sport path segments are not guessable). It also documents an alternative use case: passing a team path returns that team's seasons, which guides the agent to choose the appropriate path.

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 provide readOnlyHint, openWorldHint, and idempotentHint, and the description redundantly says 'Read-only' (no contradiction). However, it adds valuable behavioral context beyond annotations: 'Search is exact-ish' and the quirk that appending qualifiers usually returns nothing. This gives the agent important expectations about search behavior that structured hints cannot convey.

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 purpose, then a clear statement of the tool's role in the workflow, followed by a succinct search tip. Every sentence adds value; there is no filler, repetition, or unnecessary detail.

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 search tool with two well-documented parameters and no output schema, the description covers the essential behavior: what it finds, what it returns (canonical URLs), how the other tools depend on it, and a critical search caveat. This is complete enough for an agent to use it correctly as the entry point in a larger workflow.

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% (both query and limit have descriptions), so baseline is 3. The description adds extra semantics for the query parameter by explaining the name-matching behavior and advising plain names for better results. This goes slightly beyond the schema's simple example, justifying a 4 rather than 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?

The description opens with a specific verb+resource: 'Find a high school or an athlete by name.' It also distinguishes the tool from siblings by declaring it 'the entry point for every other tool' and explaining the canonical URLs it returns, making its role clear relative to the get_* and list_* 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?

Explicitly states when to use: 'This is the entry point for every other tool'—signaling to use it before any other tool to obtain canonical URLs. It also provides concrete search tips (prefer plain name, avoid qualifiers like 'high school'), which is actionable usage guidance. No need to exclude alternatives when the description frames it as the required first step.

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