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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral value beyond that by disclosing what is deliberately trimmed — site chrome, partner/commerce blocks, team photo and internal settings — which tells the agent the payload is sanitized rather than raw. It stops short of mentioning payload size, rate limits or upstream dependency 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?

Front-loaded with the action, then a single dense enumeration, then one exclusion sentence. The long contents list is informative rather than padding, though the comma-spliced enumeration is dense and could be bulleted or trimmed slightly without losing meaning.

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 an output schema present and full schema coverage, the description is complete enough to invoke correctly and even redundantly spells out the return contents. The remaining gap is relational: it does not say when this superset call should replace the narrower maxpreps_team_* calls, which matters given the crowded sibling set.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are required with their own descriptions pointing at provenance (maxpreps-school-search, maxpreps-team) and the 'exact team and level' constraint. The prose adds nothing about the parameters, so the baseline 3 applies — the schema does the work here.

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

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

States a specific verb and resource ('Get MaxPreps team page context') and then enumerates precisely what is included: team identity, sport-season list, sport vocabulary aliases, state record, ranking summaries, standings, market areas, affiliations, availability flags. The parenthetical 'same shape as maxpreps-team' positions it relative to the narrower sibling, so an agent can tell this is the aggregated one-team-season payload rather than the plain team lookup.

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?

Usage is only implied: the broad payload and the exclusion list hint that this is the one-shot context fetch versus narrower siblings like maxpreps_team_rankings or maxpreps_team_schedule. There is no explicit when-to-use or when-not statement, and no guidance on when the narrower siblings are preferable despite heavy overlap with their data.

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