kcsc_audit

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

With no annotations provided, the description carries the full burden and delivers exceptionally. It discloses the critical limitation that KCSC original formulas are images the tool cannot read, that formulas/coefficients are model-recalled from memory ('모델이 기억으로 채운 것'), and that correctness cannot be distinguished from output alone. It also explicitly separates verified vs. unverified content. This is exemplary epistemic transparency for interpreting results correctly.

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 longer than average but densely functional—every section earns its place: purpose, parameter usage, workflow trigger, image/formula caveat, and the verifies/cannot-verify boundary. Headers and bold formatting aid scanning, and the critical workflow instruction is front-loaded with the ★ marker. Only mild tightening of the caveat section would improve it.

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 tool with substantial epistemic nuance (image formulas, model-recalled content, correctness boundaries), the description is thorough: it lists what is verified, what cannot be verified, and explains the critical limitation that motivates the tool's existence. An output schema exists, so return-value documentation is covered elsewhere. Nothing essential for correct invocation or interpretation 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 description coverage is 0%, so the description must compensate—and it fully does. It explains 'text' as putting the entire answer text as-is ('전체를 그대로 넣는다') from which citations are extracted, and 'code' as specifying a single standard when it isn't written in the text ('기준이 하나뿐인데 글에 안 적혀 있으면'). Both parameters gain practical usage meaning beyond their bare types/defaults.

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 opens with a precise verb+resource statement: '계산·검토 답변의 인용을 기계로 검증한다' (machine-verifies citations in calculation/review answers) and enumerates concrete verification targets (standard, clause, formula number, table/figure number existence). The '확인하는 것/확인하지 못하는 것' (what it verifies / what it can't verify) sections clearly demarcate its scope from the sibling searching/reading tools, so an agent can distinguish it without opening schemas.

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 ★-marked instruction gives explicit when-to-use guidance tied to a workflow: '구조계산 답변을 냈으면 이 검증을 함께 돌리고 결과를 밝히세요' (if you produced a structural calculation answer, run this verification and disclose results). The '확인하지 못하는 것' list also implicitly indicates when NOT to rely on it. However, it never names sibling alternatives for exclusion, which is the one gap.

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