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

Annotations already declare destructiveHint=true, and the description is consistent with that while adding real value: the server refuses the call and nothing is sent without confirm, consent must come from the user, and each call burns one token. It stops short of saying what state changes or whether an already-processed application can be re-modified.

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 hard prerequisite is front-loaded in the first sentence and the rest is dense with actionable constraints. There is minor redundancy between 'confirm=true sent only after the user agrees' and 'without confirm the call is refused and nothing is sent', and the trailing Korean token note sits outside the otherwise English flow.

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 mutation with a user-consent gate it covers the auth prerequisite, consent, confirmation, refusal behavior and cost. The remaining gap is substantive but narrow: nothing explains which parts of the application the programme_key/receipt_no pair actually lets you change or what happens to the submission status afterward.

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%, so all six parameters are already documented in the input schema. The description restates the confirm and admin_info_sharing_consent semantics (which the schema already covers) but adds the ordering nuance that confirm is sent only after the user agrees. Baseline 3 applies since the schema does the heavy lifting.

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+resource ('Modify an already-submitted work24 subsidy application') and scopes it to records already submitted, which is the key discriminator against the sibling submit/init tools. It does not, however, say what aspect of the application is modified or how it differs from withdraw/delete beyond being on 'the same screen as submit'.

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 concrete preconditions: a prior work24__auth__npki_session__login with the same account_link_id, a user-chosen admin_info_sharing_consent, and confirm only after user agreement. It does not explicitly exclude sibling alternatives (submit, withdraw, delete, target_save), so an agent still has to infer the routing rule from the name.

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