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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower, and the description still adds real behavior: pagination caps (default 10, max 20), that continuation requires contentVersion, that counts/campusStates span the full filtered collection, and that output is English natural-language text with preserved sources. Return shape is partially disclosed but not fully.

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 ordering constraints, then packs filtering, paging and return-value notes into dense sentences with little waste. The final run-on sentence is heavy but every clause contributes new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter read tool with no output schema and near-zero schema documentation, it supplies the semantics needed to call it correctly: status behavior, filter meanings, pagination limits and continuation, and what counts/campusStates represent. Only a few parameters are left unexplained.

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 only 10% schema description coverage the description has to carry the load, and it does for the nontrivial parameters: status open/all semantics, state/postcode/regionalCategory filtering, pageSize default and maximum, and the role of contentVersion in continuation. It leaves school, courseCode and page to inference, which keeps it from a 5.

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

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

Opens with a specific verb+resource ('Read school campuses') and immediately scopes it ('optionally limited to a course belonging to this school'), which is clearer than the bare title. It does not explicitly distinguish itself from sibling get_school or the search_* tools, 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 the semantics of status=open vs status=all and what each filter narrows, which implies usage. However, it never states when to prefer this tool over get_school or another sibling, and gives no exclusions or prerequisites beyond the endpoint being public.

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