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

Annotations already declare the mutation profile (readOnly=false, idempotent=false, destructive=false), so the description is not obliged to repeat safety. It adds genuinely useful context beyond the annotations: a human staff member will contact the submitter, name and phone are mandatory, and there is a 300원/인 cost — all decision-relevant facts an agent cannot infer from the schema.

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?

Four short sentences, front-loaded with purpose and price, then the human-contact caution. Minor redundancy between '담당자가 연락한다' and '사람에게 연락이 가는 행동이다', but overall tight and free of filler.

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 non-destructive, non-idempotent write tool with full schema coverage and no output schema, the description covers purpose, cost, required contact data, and the fact that submission triggers human outreach. It stops short of saying what the caller gets back (confirmation, ticket reference) or how long a response takes, which would be the last useful piece.

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 all seven parameters are already documented with examples in the schema. The description only restates that 담당자 이름 and 연락처 are required, adding no format, validation, or selection guidance beyond the schema. Baseline 3 applies.

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?

States a specific verb (신청한다) and a specific resource (운영자가 대신 개설·집계하는 맞춤 투표함) and adds the distinguishing detail that no sibling tool offers (a paid, operator-run ballot service). An agent can tell immediately that this is not a meeting/voting operation like create_draft_meeting or electronic_voting_basis.

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 a clear selection condition: only when the organizer wants a human follow-up ('주최자가 원할 때만') and only when operator-run setup is desired. It does not explicitly name alternatives among the siblings, but no sibling is a near-substitute for a consultation request, so the guidance is effectively complete.

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