list_parents

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

No contradiction with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) — the description is consistent with a safe read-only listing. However, the description itself contributes zero behavioral context beyond what annotations already convey; it doesn't mention pagination defaults, ordering, or what set of parents is returned. The HIGH calibration example earned a 3 by adding scope constraints; this one adds nothing.

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?

At two words, the description is under-specification rather than conciseness. It contains no front-loaded distinguishing fact, no exclusion, and no behavioral note — there is nothing here that earns its place beyond restating the tool name.

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?

The surrounding structured context is rich: output schema exists, both parameters are documented, and annotations fully describe the safety profile. For a simple paginated list tool, an agent can likely invoke it correctly. Yet the description itself is the weakest link — with ~60 mostly read-only list_* siblings, the tool is only minimally identifiable, so 3 (minimum viable) rather than higher.

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% — both limit and offset are fully documented in the input schema with defaults and max values. Per the baseline rule for high coverage, the description need not add parameter detail; it also doesn't, so it neither helps nor hurts. Score 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 'List Parents' is a near-verbatim restatement of the tool name 'list_parents' — a tautology that adds no information beyond the name itself. While it does convey a verb and resource, it fails to differentiate this tool from the many list_* siblings like list_students, list_sessions, and list_tutors, and says nothing about scope or content of the 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 provides no guidance on when to use this tool versus alternatives. With get_parent among the siblings, there is no mention of the list-versus-get distinction, and no context such as 'use for bulk operations' or 'use get_parent for a single record.' The agent is left to infer usage entirely from naming convention.

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