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

Annotations already declare destructive=true, idempotent=true, openWorld=true, readOnly=false, giving the agent a strong safety profile. The description adds valuable context beyond these: it is owner-bound, requires explicit approval of a specific preview, and rejects stale session scores. However, it does not explain what happens on partial failure, rate limits, or whether rejection is atomic, which for a destructive, open-world write operation would raise this to a 5.

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, front-loaded with the action and its key precondition. Every phrase carries weight ('exactly the grades', 'owner-bound', 'explicit teacher approval', 'rejects session scores changed'). It is slightly terse and could be made more scannable with a bullet, but it is efficiently structured.

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 1 parameter, full schema coverage, an output schema, and rich annotations, the description carries a light burden and meets it well: it clarifies the confirmation semantics, the staleness guard, and the approval requirement. The only mild gaps are the absence of a named prerequisite tool and any detail on the failure mode, but the output schema likely covers return values.

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% and already documents the previewId with its length bounds and the 'from the matching prepare_ tool' provenance. The description's phrase 'owner-bound previewId' adds a semantic nuance about ownership that the schema does not state, but otherwise the parameter meaning is fully carried by the schema, so the baseline 3 is correct.

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 uses a specific verb ('Exports') and resource ('the grades in the owner-bound previewId') and adds a critical condition ('subject to explicit teacher approval of that preview'), clearly distinguishing this confirmation tool from the related read-only prepare tool. It stops short of naming the sibling 'prepare_push_grades_to_google_classroom' directly, but the 'previewId' parameter and the confirmation semantics make the distinction sufficiently clear for selection.

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 the workflow: use this after a preview has been prepared and the teacher has approved it. However, it never explicitly states when to use this versus alternatives, nor does it name the required prerequisite tool by name. The condition 'after the teacher said yes' is present in the parameter schema description, not in the tool description itself, so usage guidance is only implied.

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