check_minutes_grounding

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to restate safety. It adds genuine value beyond annotations by disclosing the heuristic nature — false positives are possible, the check is advisory, and it normalizes date expressions to ISO to avoid false positives. These traits are not derivable from the structured fields and help an agent calibrate trust in the results.

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 inspection-item list plus the advisory note are well-organized with headers. The structure is clear, but the Args section largely duplicates the schema and could be trimmed. Minor redundancy keeps this from a 5.

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?

An output schema (GroundingResponse) covers the return shape, so the description need not detail it. Everything else an agent needs is present: what the tool inspects, that it is advisory with possible false positives, how it fits in the save pipeline, and how to remediate findings. Nothing material is missing for a correct call.

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%, with all three params (note_id, minutes_markdown, max_findings) already documented in the schema. The description repeats the Args with nearly identical information, adding only marginal context such as the default of 30 for max_findings. Since the schema carries the heavy lifting, the baseline of 3 is appropriate — the description adds no substantial new parameter meaning.

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 names a specific verb and resource — cross-checking people, dates, and numbers in minutes against the original note — and enumerates the exact inspection items (person_unsupported, date_unsupported, etc.). It distinguishes itself from validate_minutes_draft by stating that one checks structure while this checks factual grounding, so an agent can select it correctly without opening the schema.

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 places the tool clearly in the workflow: it is advisory, does not block saving, and the save gate is validate_minutes_draft plus user approval. It also gives a recovery path — re-check the original with read_meeting_note and change unsupported claims to '미정'. It lacks an explicit 'use X instead' exclusion for every sibling, but the context is strong enough that when/when-not usage is clear.

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