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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds substantial behavior beyond that: response opinion domain (적정/부적정/의견거절, explicitly NO '한정'), that a review's 의견거절 means a scope-limited conclusion non-statement, that reports is an ARRAY yielding up to 2 entries, that present=false is usually out-of-scope not missing data, and a warning never to conflate review vs audit 의견거절. Rich behavioral context on top of good 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?

Purpose is front-loaded in the first sentence, and the [Purpose]/[Usage]/[Response]/[Rules] section headers make a dense document scannable. Every section earns its place for a complex domain. It is long and somewhat dense — the deep reference to management_operation_report.steps and the applicable=false note could be trimmed — but it is organized efficiently rather than padded.

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?

There is no output schema, and the domain is complex (연결 vs 별도, review vs audit, 의견거절 vs 한정, present=false, applicable=false). The description carries the full burden of response semantics and does so completely: opinion domain, array behavior, empty-CFS-is-normal, and the review/audit conflation warning. Nothing an agent needs to invoke and interpret the tool correctly is missing.

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% and the schema itself is extremely thorough (year's fiscal-year conversion rules and floor, fs_div's CFS/OFS fallback semantics). The description adds marginal value via usage examples (corp/year mapping, fs_div='CFS' for 연결 기준만) but does not substantially expand parameter meaning beyond the schema, which already does the heavy lifting. Baseline 3 is appropriate.

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?

Opening sentence states a specific verb+resource: it queries the 'auditor's' ICFR audit/review reports (구분·의견·중요한 취약점 여부). It explicitly differentiates from siblings, routing 취약점 lists to search_audit_findings, 자금부정통제/운영실태 reports to get_attachments, structured facts to get_audit_profile, and full text to get_audit_report. An agent can tell exactly what this tool is and is not.

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 explicit when/when-not guidance: 'not here → get_attachments', 'Structured facts: get_audit_profile', 'full text: get_audit_report'. Two concrete usage examples map natural-language queries to parameters (corp='카카오페이', year=2024; '연결 기준만' → fs_div='CFS'). The Rules section adds interpretation guardrails (present=false semantics, review/audit distinction) that dictate correct use.

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