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

Annotations carry almost no signal (readOnlyHint=false, destructiveHint=false), so the description shoulders the burden and delivers richly. It discloses revision resolution (newest WRT_CHASU wins), row-collapsing rules with provider-specific row keys, the computed/computed_error null pattern, and the precise meaning of partial=true across two error shapes. No contradiction with annotations.

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?

Dense but every sentence earns its place: core purpose first, then prerequisites, scope exclusion, resolution edge case, account-link behavior, and finally error/partial handling. No filler or repetition; the operational edge cases are exactly what an agent needs before invoking.

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 composite tool with 10 parameters editions, no output schema, and cross-provider coordination, the description is unusually complete: prerequisites, scope, dedup rules, and failure semantics are all covered. The notable gap is that the actual computed 'insurance deduction material fields' returned are not enumerated, which matters more given there is no output schema.

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. The description adds modest enrichment by tying 고지년월+고지차수 to the resolution semantics and explaining that row keys disambiguate rows from different 고지, but it does not systematically add per-parameter meaning beyond what the schema already states.

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+resource: 'combines NHIS, NPS, and COMWEL employment billing notice Jobs, then returns computed insurance deduction material fields.' This clearly distinguishes it as a composite generation tool from the surrounding session-auth, search, and single-provider sibling tools like nhis_edi__public__notices__list or payroll_pack__premium_summary_v1__generate.

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?

Provides clear context: it requires prior session login for the three providers, explicitly excludes tax fields, and explains that requires_account_link=False means links resolve per leg provider. It does not explicitly name alternatives or state when-not-to-use versus sibling generate tools (e.g., premium_summary), so exclusions are implicit rather than explicit.

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