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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds valuable context: empty players lists are normal for most teams, not an error. It also notes that past seasons often work and that team ids differ per school year, which is useful behavioral information 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 and front-loaded. The first sentence states the core purpose, the second provides the key behavioral caveat about empty player lists, and the third states requirements and read-only nature. Every sentence earns its place with 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 read-only tool with no output schema, the description covers the essential context: what it returns, the normal empty-list case, required inputs, and the read-only nature. It could mention what the response structure looks like, but since there's no output schema and the tool is simple, the description is reasonably complete. The reference to mpaz_list_teams for resolving team ids adds 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds some context about the year parameter (defaults to current, past seasons often work) and teamId (differs per school year), but these details are also present in the schema descriptions. The description doesn't add significant meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: retrieving coaching staff and players for one team. It explicitly names the resource (team roster and coaches) and the required inputs (sport slug and team id). It also distinguishes itself from siblings by noting that most teams publish coaches but not players, which is a unique behavioral detail.

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 when to use this tool: to get a team's roster and coaches. It mentions the need for sport slug and team id, and references sibling tools (mpaz_list_teams) for resolving team ids. However, it doesn't explicitly state when NOT to use it or name alternative tools for other purposes, so it falls slightly short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral context beyond those: it explicitly mentions the limited window of 10 observed events and the oldest-first ordering. 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?

Two sentences with every sentence contributing meaningful information. The core purpose is front-loaded, the key limitation is clearly emphasized, and the sibling tool reference is concise. 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?

For a one-optional-parameter read-only tool with rich annotations, the description is largely complete: it defines the scope, ordering, window limitation, and provides a clear alternative for full-season data. It does not enumerate the event fields in the return, but the absence of an output schema is partially mitigated by the clear 'upcoming events' framing.

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 already documents the single optional 'year' parameter with an example and default behavior, reaching 100% coverage. The description does not add new parameter-level meaning, but it also does not need to because the schema carries the full 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 clearly states the tool returns 'Upcoming events across every team, oldest first', identifying the resource (all-school schedule) and the operation (get a window of upcoming events). It distinguishes itself from mpaz_get_team_schedule by explicitly noting this is not a full-season view.

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 routes the agent to mpaz_get_team_schedule when a team's full season is needed, and clarifies this tool returns only a window of 10 observed upcoming events. The read-only note also signals safe usage conditions.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the bar for additional disclosure is higher. The description adds valuable behavioral context beyond those annotations: it explains that a half-entered game yields null scores and `result: null`, emphasizing that a missing score is unknown, never zero. This prevents a common misinterpretation and is essential for correct data handling.

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 well-ordered: it opens with the core purpose, then explains field semantics and null behavior, then routes to the alternative tool, and finally confirms read-only status. Every sentence contributes distinct value with no repetition 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?

There is no output schema, so the description takes on the burden of explaining the return shape. It names the key fields and the null-condition behavior, which is the most critical nuance. However, it does not explicitly state whether the response is an array or describe ordering or pagination. These are minor gaps given the field-level detail already provided.

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

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

Schema description coverage is 100%, so all three parameters are already fully documented with format, defaults, and provenance. The description reinforces the concept of 'this school's point of view' but does not add new parameter-level details. Baseline 3 is appropriate since the schema carries the semantic weight.

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 completed games with results for a single team, listing the specific fields returned (`homeScore`/`awayScore`, `teamScore`/`opponentScore`/`result`). It distinguishes itself from siblings by noting it covers results rather than upcoming fixtures, so an agent can select it accurately.

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 explicitly says to prefer `mpaz_get_team_schedule` for upcoming fixtures, drawing a clear line between results and schedule use cases. The phrase 'Completed games with results' also establishes when this tool is appropriate. This is direct, actionable routing guidance.

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 indicate read-only and idempotent behavior. The description adds useful behavioral details beyond that: results are ordered oldest first, the schedule is complete, and identifier resolution is required. No contradiction with 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 tight, front-loaded sentences state the core behavior and the critical prerequisite without any filler. Every phrase 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?

For a simple read-only schedule tool, the description plus schema covers scope, ordering, required parameters, and resolution prerequisites. A brief note about the returned fields would make it fully complete in the absence of an output schema, but the current definition is sufficient for correct selection and 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 the schema already explains all three parameters well. The description reinforces that both sportSlug and teamId are required, but adds no syntax or formatting details beyond what the schema provides.

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 this tool returns a single team's complete season, oldest first, and explicitly names the required identifiers (sport slug and team id). This distinguishes it from the sibling schedule, roster, and news 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 gives an explicit prerequisite: both sport slug and team id must be resolved first using mpaz_list_teams or mpaz_resolve_team. It does not explicitly contrast with mpaz_get_schedule, but the usage context is clear enough for an agent to proceed.

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, and the description adds meaningful behavioral context by specifying what is verified (RSC payload parseability) and what is reported (site and school id). No contradiction exists.

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 three short sentences with no filler. It front-loads the primary purpose, then states the reported information, and ends with the safety-relevant 'Read-only' note.

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, parameterless healthcheck with read-only annotations, the description is largely complete: it states what is checked and what is reported. The absence of an output schema is partially mitigated by the mention of reported fields, though the exact representation of the reachability result is left implied.

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?

There are zero parameters, so the input schema carries no burden. The description appropriately avoids inventing parameter details, and the baseline for a zero-parameter tool is met.

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 ('Verify'), the resource (the athletics site), and the success criterion (reachable and serving a parseable RSC payload). It also notes what the tool reports, distinguishing it from sibling data-retrieval 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 gives a clear context for use: checking whether the site is reachable and confirming the configured site/school id. It does not explicitly mention alternatives or when-not-to-use, but the sibling tools are all data operations, so the healthcheck purpose is unambiguous.

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 annotation, the description discloses that results are recent, sourced from the homepage, and ordered newest first. This adds useful behavioral context without contradicting any 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?

A single, front-loaded sentence conveys the resource, source, recency, ordering, and read-only nature with 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 zero-parameter, read-only list operation with strong annotations, the description is complete enough for an agent to select and invoke it correctly. The lack of output schema is mitigated by the simple resource type and clear scoping.

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 baseline of 4 applies. No parameter-level explanation is needed, and the description does not attempt to fabricate parameter guidance.

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 states a specific action ('List'), a clear resource ('news posts'), and the source ('athletics site homepage') with ordering ('newest first'). It is clearly distinguishable from sibling tools like list_videos and list_photo_galleries.

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: use this tool when you need recent news posts from the athletics homepage, ordered newest first. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by noting that gallery images sit on a public CDN and can be fetched directly without auth, which is behavioral context 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 brief, front-loaded with the resource, and includes useful auth/CDN context in the second sentence. The trailing 'Read-only' is redundant with the readOnlyHint annotation, so not every element adds new information, but overall it is compact.

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, read-only listing tool with strong annotations, the description covers resource scope and the non-obvious public-CDN/no-auth behavior. It does not describe the shape of returned gallery entries, but the lack of an output schema makes that omission less critical.

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 no parameter documentation is needed. The baseline of 4 applies, and the description appropriately says nothing about 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 identifies the resource ('photo galleries published on the site') and the read-only framing makes the listing action clear. It does not use an explicit verb like 'lists' or 'returns', but the resource is distinct enough from sibling tools such as list_videos and list_news.

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 when photo gallery metadata is needed, but gives no explicit when-to-use guidance or reference to alternatives. The CDN/auth note is useful context but does not route the agent away from or toward any sibling tool.

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 readOnly/openWorld/idempotent hints, it discloses that team ids are year-specific and fail across seasons, that past-year data may fall back to sport pages and only cover in-season sports, and that an empty result carries a coverage note and should not be read as 'no teams.' This is rich, non-obvious 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?

Four sentences each carry unique information: core action, downstream dependency, id-year scoping warning, and past-year/coverage caveats. Read-only is stated at the end; nothing is redundant or padded.

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 lacking an output schema, the description tells the agent the key facts needed to call and interpret results: teams are school- and year-scoped, ids feed other tools, past years may be partial, and a coverage note accompanies fallback results. This is complete for the tool's low 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 schema already describes the `year` parameter well (format, default, coverage caveat), so the baseline is 3. The tool description adds a meaningful semantic: year scoping determines the validity of team ids downstream, reinforcing why choosing the right year matters.

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 (list), resource (this school's athletic teams for a school year), and a key purpose (providing team ids used by schedule, roster, and scores tools). The description makes clear it is the team-listing entry point and does not get confused with the single-team or schedule/score 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?

Explains that the tool exists to feed team ids to schedule/roster/scores tools, which is clear guidance for when to call it. It also warns about year-scoped id validity and past-year coverage limits, but it does not explicitly name alternative tools for related lookups such as resolve_team.

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 non-obvious data quirks: videoLengthSeconds is always 0 and title contains the team name, not a video title, and explicitly says this is expected rather than missing data. This adds real value beyond the readOnlyHint annotation.

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

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

The description is short and front-loaded with the core purpose, then quickly explains the two important output quirks and confirms read-only behavior. Every sentence adds necessary information 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 input parameters and no output schema, the description covers the most likely sources of agent confusion by flagging the unusual field semantics. It does not enumerate the full item shape, but the key surprises are handled sufficiently for a simple list operation.

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 baseline of 4 applies. The description adds nothing about parameters, but none are needed since the input schema is empty.

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 title and description both state a specific verb and resource: list games that have broadcast links. The description further clarifies that these are NFHS Network links rather than hosted clips, distinguishing the resource from a generic video listing.

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 clearly implies this tool is for retrieving games with broadcast links, and the read-only note gives agent confidence about side effects. There are no sibling tools covering the same broadcast-link function, so explicit alternative routing is not needed.

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 include readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds the behavioral detail that it returns every candidate on ambiguous queries, which is valuable beyond the annotations. The 'Read-only' statement is redundant with readOnlyHint but not contradictory.

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, front-loaded with the purpose, and no filler. It efficiently conveys the tool's role and key behavior.

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 there is no output schema, the description covers when to use the tool, what happens on ambiguous queries, and hints at coverage limitations via the year parameter note. It doesn't detail the output structure, but for a simple resolution tool this is sufficient.

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

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

Schema coverage is 100% with both query and year described. The description provides examples of loose names ('varsity football', etc.) which aid understanding but do not add substantive parameter semantics beyond what the schema already states. Thus baseline 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Find a team id from a loose name'. It also distinguishes itself from sibling tools by naming mpaz_get_team_schedule, mpaz_get_roster, and mpaz_get_scores, telling the agent this tool is the resolver for those.

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 says to use this tool before the schedule/roster/scores tools 'rather than guessing an id', providing clear when-to-use guidance. It also notes that it returns every candidate when the query is ambiguous, which helps the agent know what to expect and when to refine.

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