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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, and the description usefully narrows the blast radius by saying the video is not edited or republished. However, it says nothing about duplicate submissions creating multiple inbox entries (non-idempotent) or whether a submission can be withdrawn, which is the behavior an agent most needs to know here.

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 short sentences, action first and the scope-limiting caveat second. Nothing redundant and no filler.

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, so return values need no explanation, and the human-review framing covers the lifecycle. Still, with zero schema description coverage the definition should have explained what belongs in the message and what scene_id refers to; that omission leaves the calling contract half-specified.

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 0% for two required parameters, so the description must carry the load and does not. It never says that 'message' is the free-text correction proposal (10-2000 chars) or what 'scene_id' identifies, leaving the agent to infer both from the schema's type constraints alone.

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 and resource ('Submit an annotation correction') plus the destination ('existing human review inbox'), so the agent knows this routes a request to humans rather than mutating data. It separates itself from editing tools via 'Does not edit or republish the video', though it never names a specific sibling tool.

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 inbox framing implies this is the path when a human needs to review a suspected annotation error, and the 'does not edit or republish' clause rules out the wrong expectation. But there is no explicit when-to-use trigger (e.g. 'use when you spot a mislabeled scene') and no alternative tools named for agents who want to change data directly.

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