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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It adds useful behavioral context beyond the annotations: the work24 SSOT vs XDATA, the auth prerequisite, and the 501 failure mode for unsupported programmes. No contradiction with annotations exists.

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 is dense and information-rich with no filler. The most important prerequisite is front-loaded, followed by the core purpose, read-only semantics, SSOT note, and coverage caveat. Every sentence earns its place.

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?

The description covers purpose, required auth context, supported programme scope, processing states, and failure behavior, while the schema fully documents all five parameters. However, there is no output schema and the description does not explain the exact response shape or clarify the 'measured list' phrase in the 501 case, so a small completeness gap remains.

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 100%, so the baseline is 3 and the schema already explains every parameter including programme_key, date defaults, account_link_id behavior, and business_management_no. The description adds contextual constraints like the auth prerequisite and programme coverage, but it does not add new parameter-level meaning beyond what is already in the schema.

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 states a specific verb and resource: 'List past work24 subsidy applications for this programme with their processing state'. It also names the programme scope and states read-only behavior, clearly distinguishing this from mutation siblings like submit, modify, withdraw, and delete.

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 gives a clear usage prerequisite: a prior work24__auth__npki_session__login call with the same account_link_id. It also provides a vital exclusion: only programmes measured on the '참여 사업관리(기존 신청자)' screen are supported, with other programmes returning 501. It does not explicitly name alternative tools, but the coverage boundary and auth context are strong.

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