flag_narrative_risks

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavioral context: results are always `warning`, the tool never blocks saving, it intentionally avoids judging narrative appropriateness, and it excludes table values. This explains the tool's limitations and design rationale clearly.

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 well-structured and front-loaded: the purpose is stated first, followed by an illustrative example, explicit behavioral boundaries, and usage examples. Every section earns its place, and the bold key point makes the tool's non-blocking behavior immediately visible.

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?

Given the annotations, output schema, and sibling tools, the description is fully sufficient. It explains what the tool does, when to use it, when not to use it, what it returns, and why it behaves conservatively. No important operational detail 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%, so the baseline is 3. The description adds extra meaning by clarifying that the '보고서' parameter refers to the narrative text, not tables, and by illustrating the kind of mismatch it detects. It does not deeply elaborate the week or directory parameters, but the schema already documents those adequately.

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 clearly states the tool's specific function: flag candidates where values are correct but the narrative conflicts with the data (L4). It explicitly distinguishes this from L1/L2/L3 checks and gives a concrete example, so an agent can identify the exact resource and behavior.

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 provides both a use case ('지연된 과제를 괜찮다고 써 놓은 데가 있나요?') and a non-use case with a named alternative ('숫자 대조 → verify_claims'). It also clarifies that this tool only flags, does not judge, and does not look at tables, which prevents misuse.

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