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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new context: the exact fields returned, that human-readable class names can be resolved to ids here, and a cost signal ('Cheap') that affects tool selection.

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 short sentences with zero padding. The resource and its returned fields come first, then the id-resolution utility, then the cost note — well front-loaded for an agent deciding whether to call it.

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?

An output schema exists and the single input parameter is fully documented in the schema, so the description needn't explain returns or the archived flag. For a simple read-only list tool, everything an agent needs to invoke it correctly is present.

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?

Only one parameter, and schema description coverage is 100% — the schema fully explains that includeArchived lists archived rather than active classes. The description never mentions archived filtering at all, so it adds nothing beyond the schema; baseline 3 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?

States a specific verb ('Lists') and resource ('classes') scoped to 'the signed-in teacher's', and enumerates the returned fields (subject, student count, class id). It does not, however, distinguish itself from siblings like list_subjects or get_class, which an agent scanning 70 tools would benefit from.

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 note that class names such as 'period 3' can be resolved to ids suggests this is the lookup step before an operation, and 'Cheap' hints it should be preferred for bulk lookups. No explicit when-to-use, when-not-to-use, or named alternative (e.g., get_class for a single class) is given.

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