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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the percentage counts only mandatory published lessons, last-access information, cohort completion share, and the privacy rule that names only appear on stage 3. These details tell the agent what kind of data to expect and how it is computed beyond what any structured annotation provides.

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 packs several distinct facts into three compact sentences without redundancy. It leads with the central output (per-student percentage), then adds recency data, cohort-wide completion, and the anonymization rule. Every sentence carries a distinct piece of useful information; nothing is wasted.

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 a single parameter and no output schema, the description communicates what data will be returned: student name or placeholder, percentage, last visit, days since, and completion share. It does not document the exact response format or JSON shape, but with no output schema, giving the natural-language semantics of each field is reasonable and sufficient for an agent to call the tool and interpret the result.

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 is only one parameter, cohort_id, and the schema title says 'Cohort Id' while the description implies it identifies the cohort. With schema description coverage at 0%, the description partially compensates by making clear the output is for the cohort's students, but it does not spell out where to find cohort_id or that it must be an existing cohort. Baseline for one clearly-implied parameter is acceptable.

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 names a specific verb and resource with precise scope: per-student progress in a cohort. It details exactly what is computed (course percentage, last activity, days since, completion share), how the percentage is calculated (mandatory published lessons), and the name anonymity rule by stage. Even without pushing the title, it does not merely restate 'cohort progress'—the resource is well delimited and distinct from siblings such as stuck_students or get_school_summary.

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 does not explicitly say when to use this tool versus alternatives and gives no exclusions or alternative names. However, its level of detail clearly implies that it is the cohort-level progress view: to inspect completion and activity across a cohort's students, use this tool. It does not instruct the agent when not to use it (e.g., for a single student or for school-wide stats), so the guidance remains implicit.

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