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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real behavioral context: the submission happens in the person's name, edits persist to the answer book (a side effect beyond the submission itself), and explicit human consent is required. It does not state whether the submission is revertible or what the caller gets back.

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 tight sentences, front-loaded with the Send-button framing and the core action before the edits mechanics and the consent caveat. The UI analogy costs a few words but earns its place by making the trigger condition concrete.

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 destructive, non-idempotent mutation with no output schema, the description covers the trigger condition, the consent requirement, and the persistence of edits. Only the post-call outcome and reversibility are left unaddressed, which is a minor gap given the annotation profile.

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 only 50% (application_id is undocumented), so the description has to carry weight, and it does: edits is defined as a label-to-new-answer map whose keys must match labels exactly as get_application_review renders them, plus the persistent effect on the answer book. application_id is left implicit but is unambiguous by name.

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 (submits an application waiting for review) and anchors it to a concrete UI element (the review screen's Send button). An agent can distinguish it from write-adjacent siblings like update_application_details or apply_to_live_job without opening any schema.

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?

Gives a clear precondition (get_application_review must report editable) and a hard constraint (only with the person's approval of the answers). It points at get_application_review as a gate rather than spelling out when-not-to-use versus the update/apply siblings, so it stops just short of full alternative routing.

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