투표함 — 전자투표 법령 자료 · AI 투표함 (Korean e-voting statutes, quorum & ballot drafting)

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

Annotations already flag destructiveHint=true, but the description adds what destruction means: "되돌릴 수 없다" (irreversible) and the contest risk from early closing. It also states the manageToken auth requirement, which annotations don't cover. The return value and the effect on already-cast votes remain undescribed.

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 the action and the irreversibility warning, then the condition and the auth requirement. No sentence repeats another.

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 destructive, no-output-schema mutation this covers the key agent concerns: irreversibility, when it is permitted, and auth. What happens to the meeting afterward (final state, whether votes are locked) is left implicit.

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 confirm, meetingId and manageToken are already fully documented, including the const true constraint and the 'host instruction received' meaning. The description only repeats "manageToken 필요" and adds no format or usage detail beyond the schema. Baseline 3 is correct.

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 resource: "모든 안건을 지금 마감하고 결과를 확정한다" (close all agenda items now and finalize results). It doesn't distinguish itself from siblings like get_draft_status or judge_resolution, so it can't earn a 5.

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 an explicit gating condition and warns that closing before the announced time risks a contested resolution, which functions as a when-not. It never names an alternative tool for the non-host or post-closing cases, so it falls short of a 5.

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

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

Adds substantial behavior beyond the annotations: draft state is "확인 대기", nothing opens, no charge, confirmUrl must be relayed, admin token goes to the host, and the deadline ordering rule (closesAt before paperClosesAt for bldg). These are exactly the operational facts an agent needs for a non-idempotent, non-destructive write.

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 and every sentence carries operational information. It is a dense run-on paragraph with some restatement of the schema (hash formula, closesAt rule), which costs a point.

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?

With 10 parameters and no output schema, the description supplies the missing return-value cue (confirmUrl), the state semantics, and the host-side follow-up steps. An agent could invoke this correctly from the description alone.

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 baseline is 3, but the description adds cross-field constraints (bldg preset keys via get_resolution_requirement, closesAt must be the day before paperClosesAt, roster hash formula and weight semantics). It partly repeats schema text, limiting it to 4.

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+resource ("집회 초안을 만든다") and contrasts a draft with a live vote, so the agent knows this does not open anything. It doesn't name a specific sibling, but the roster alternative (host uploads Excel via dashboard) implicitly points to upload_roster.

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?

Explains the workflow clearly: create draft → relay confirmUrl to host → host verifies with phone auth/payment → voting opens. It also gives the when-to-skip path for roster (host uploads it). Lacks explicit exclusion against other creation/close siblings, but context is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral information: the response is a three-way classification plus the specific statutory article underpinning it, which matters because no output schema exists. It stops short of stating edge cases or what happens for an unrecognized key.

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?

One sentence, front-loaded with the core question, then the answer categories, then the returned legal basis. No filler and no repetition of schema or annotation content.

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?

With no output schema, the description carries the burden of explaining what comes back, and it does so by naming the three verdict categories and the accompanying statute citation. It is slightly incomplete in not indicating how to obtain a valid key value or how the citation is formatted, but the essential shape of the call and result is clear.

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%: the single 'key' parameter is documented with type and concrete examples (e.g. "coop_bylaw", "stock_ordinary"). The description adds nothing about the key — not where valid keys come from (perhaps list_resolution_types) — so the 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?

The description names the exact question the tool answers (can this agenda item be done by electronic voting) and enumerates the three possible verdicts (permitted directly by law / requires bylaws or articles basis / not possible due to e-signature requirements) plus the legal citation returned. That is a specific verb+resource, far beyond restating the title. It does not explicitly distinguish itself from related siblings such as get_resolution_requirement or judge_resolution, which keeps it at 4.

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?

Usage is only implied: an agent can infer this is the tool to call when it needs to know whether electronic voting is allowed for a given agenda type. There is no statement of when not to use it and no pointer to the neighboring tools that also deal with resolution requirements, so the agent must infer the routing.

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

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

Adds meaningful behavior beyond annotations: ballots are additive, manageToken is required, and the whole batch is rejected if any voter already voted electronically. This is strong operational context even though annotations already declare non-readOnly, non-idempotent behavior.

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?

Six short, front-loaded sentences with no filler. The key requirement, failure mode, and token prerequisite are each stated once and clearly.

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 mutation tool with no output schema, the description covers the essential prerequisites, required evidence, and batch-rejection risk. It could say more about the success response or retry implications, but an agent has enough to call it correctly.

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 the schema already documents meetingId, manageToken, voters, and evidenceImageDataUrl. The description reinforces the required evidence photo and one-voter-equals-hash-plus-choices model, but adds little syntax or format detail beyond the schema.

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 action and resource: entering written resolution ballots (on-site paper votes). It is clear enough to distinguish paper-ballot entry from electronic voting siblings, though it does not explicitly name an alternative tool.

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 implies when to use it (paper/on-site ballots) and gives an important exclusion (do not mix in people who voted electronically), but it does not explicitly name the alternative electronic voting tool or state when-not-to-use conditions beyond that warning.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the manageToken prerequisite, but does not explain return shape, privacy sensitivity, or rate-limit behavior.

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 two short sentences with the dashboard contents front-loaded and the auth prerequisite second. It is compact and easy to scan, though the second sentence mainly restates schema requirements.

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?

With full schema coverage and read-only annotations, the main remaining burden is describing what the dashboard returns. The description lists the three return categories at a useful level, though it does not detail formatting or scope limitations.

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%, and both parameters are fully documented in the input schema. The description only repeats that manageToken is required, so it adds no meaning beyond the schema baseline.

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 identifies the concrete dashboard contents: payment status, per-agenda aggregates, and roster status. It is clear what the tool returns, but it does not distinguish this overview from siblings like get_report or get_draft_status.

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 only usage guidance is that manageToken is required, which is already enforced by the schema. There is no explicit guidance on when to choose get_dashboard over get_report, get_draft_status, or other sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the token changes identity after host confirmation (confirmToken vs manageToken), which is an authorization detail the agent cannot infer. It does not describe the shape of the returned status values, which matters since there is no output 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?

Two short sentences, zero padding: the purpose and the three checked states come first, then the single conditional rule for the token. Nothing is repeated and nothing is buried.

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 two-parameter read tool with full schema coverage and rich annotations, the description covers purpose and the token lifecycle adequately. The main remaining gap is that no output schema exists and the description does not indicate what the status result looks like (booleans, enum states, etc.).

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% and both parameters are documented with a concrete example draftId and a cross-reference to create_draft_meeting's response fields. The description's token sentence largely restates the schema's token description, adding no new syntax or format detail, so the baseline of 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?

The description names a specific verb (본다/check) and resource (draft), and enumerates the three states it inspects: confirmed, paid, voting opened. That is far more precise than a generic 'get status', though it never names a sibling tool or contrasts itself with them (e.g. get_dashboard, create_draft_meeting).

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?

Usage is implied by the stated purpose – call it to poll the lifecycle state of a draft. The second sentence gives a conditional rule for which token to supply, which helps correct invocation, but there is no explicit 'when not to use' or pointer to an alternative tool among the many siblings.

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

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

Annotations already declare readOnly, idempotent and non-destructive, and '아무것도 바꾸지 않는다' merely restates that. The one piece of genuine added context is '부가세 포함 금액' (amounts include VAT), which matters because there is no output schema. No pagination, precision, or rounding behavior is disclosed.

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?

Three short sentences, each carrying a distinct fact (what is computed, what the returned amount includes, that nothing is mutated), with the calculation front-loaded. Nothing redundant.

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 one-parameter, non-destructive calculator with no output schema this covers the essentials, and naming the three tiers hints at the result structure. It could still say whether three separate amounts are returned and how rounding works, so it falls just short of complete.

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 single integer parameter 'people' is already documented with an example. The description only restates that headcount drives the calculation, adding no format or constraint detail 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 resource (three named ballot-box pricing tiers) plus the input that drives it (투표 인원). An agent can tell immediately that this is a read-only pricing calculator, distinct from the meeting/voting-action siblings.

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?

Usage is implied by the phrase '투표 인원으로 ... 요금을 계산한다' — call it when you need a price for a given headcount. There is no explicit when-to-use/when-not or reference to alternatives, but no sibling offers pricing either, so the gap is minor.

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

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

Annotations already declare read-only, idempotent, non-destructive, so the safety bar is low, and the description still adds real behavior: the report is sealed until the meeting closes and a manageToken is required. The one gap is not describing what a sealed pre-close call returns (error vs. redacted payload).

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?

Two compact sentences: contents first, then the sealed precondition and auth requirement. Every clause carries information; minor density cost from packing the content list into parentheses.

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?

With no output schema, the description usefully enumerates the report's fields, partially standing in for a return-value spec, and flags the auth and sealing preconditions. Missing only the sealed-state return behavior and any note on the report's relation to close_meeting.

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 already explains both meetingId and manageToken in detail, including where to find each value. The description only restates that manageToken is needed, adding no semantics beyond the schema, so 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?

Names a specific resource (full results report) and enumerates its contents (per-agenda vote counts, voting rights, judgment, basis, verification values), which distinguishes it from get_dashboard and get_draft_status. It stops short of explicitly contrasting with those siblings, so a 4 rather than a 5.

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 'sealed before closing' note implies the tool is only meaningfully callable after the meeting is finalized, which is useful implicit guidance. However, it never states when to prefer this over get_dashboard or get_draft_status, and does not say affirmatively what happens if called early (error vs. empty result).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral caveats such as invalid-key handling or output format, but it does enumerate the returned information and does not contradict the annotations, making it adequate for a static read-only lookup.

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 a single concise sentence enumerating the returned fields with no obvious waste. It is somewhat unstructured as a bare list and lacks an explicit action verb, but it is appropriately sized and front-loads the core information.

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?

Because there is no output schema, the description's enumeration of returned fields is important and provides a useful picture of the response content. Input semantics are fully covered by the schema and annotations cover safety, so the only notable gap is the lack of explicit when-to-use context.

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%, and the single parameter's schema clearly explains that key is an agenda type key from list_resolution_types with examples. The description itself adds no parameter meaning, so the schema does the heavy lifting and the baseline score of 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?

The description identifies the specific resource: requirements for a single agenda type, and enumerates the exact facts returned (quorum, legal basis, e-voting, notice, identity verification, roster, cautions). It does not use an explicit verb or explicitly distinguish itself from siblings such as judge_resolution, but the resource is clear enough for an agent to recognize it as a lookup tool.

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?

There is no guidance on when to use this tool versus alternatives, nor any exclusions. The only usage clue is in the schema description, which says the key comes from list_resolution_types, but that is parameter sourcing rather than tool-selection guidance.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is fully covered. The description earns credit beyond that by disclosing the payload contents — original text, amendment tags, voting-compliance application notes, related agenda types — which matters because there is no output schema. It does not cover missing-law behavior or result size.

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?

Two compact clauses, front-loaded with the resource and then the key conditional, with no filler. Dense domain jargon (개정 꼬리표, 투표함 적용 내용) makes it terse rather than verbose, which is appropriate for the audience.

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?

With no output schema and heavy annotation coverage, the description carries the return-value burden well by enumerating what each record contains and defining the empty-article case. Missing only edge-case behavior such as an unknown law argument, which is minor for a closed-world read tool.

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 both law (name or slug, with an example and a pointer to list_laws) and article (e.g. 제38조, empty = all) are already fully documented in structured fields. The description's restatement of the empty-article behavior adds only the nuance that the scope is *tracked* articles, a marginal gain over the schema.

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+resource: retrieves the raw text of one statute's articles (조·항·호) together with amendment tags, ballot-box compliance notes, and related agenda types. This is clearly distinct from list_laws, which the schema names as the enumeration source. It stops short of an explicit sibling comparison in the description itself, but the resource is unambiguous.

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 only usage guidance is the conditional 'article 을 비우면 추적 조문 전부' — it explains how to get everything at once, which is useful. There is no statement of when to reach for this versus law_changelog or list_laws, and no prerequisites or exclusions. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the line '아무것도 바꾸지 않는 계산이다' largely repeats that. It does add useful context that the result mirrors the official tally logic, but says nothing about failure behavior, missing/partial inputs, or what the verdict looks like.

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?

Three short sentences, front-loaded with the action and followed by the key domain caveat. Minimal waste; the 'changes nothing' clause is somewhat redundant given annotations but is brief.

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 an 8-parameter tool with no output schema, the description never indicates what comes back (a boolean verdict, per-requirement breakdown, margin figures). The input side is adequately covered via schema plus the 집합건물 rule, but the return side is a real gap.

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, and the description adds a genuine cross-parameter rule not in the schema: for 집합건물, both 구분소유자 수 and 의결권(면적) must be supplied for both requirements to be judged. It still omits guidance on the required `preset` key and the redev_* directAttendanceCount case.

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 resource: it takes vote counts and voting rights and judges pass/fail (가결·부결). The 'same function the ballot box uses at counting' line makes the computation's role concrete, though it does not explicitly distinguish itself from siblings like get_resolution_requirement or list_resolution_types.

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?

Usage is implied (call it when you need the verdict), and it gives one real precondition: for 집합건물 you must supply both owner count and voting-right area. But it never says when to use this versus get_resolution_requirement, nor how to choose the required `preset`.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is handled. The description adds real value by naming the substantive content returned (revision tags, scheduled amendments, ballot reflection), which annotations cannot convey. It stops short of stating scope (all tracked laws vs. a single one, given zero parameters) or ordering/freshness.

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?

It is a single short fragment with no filler, which is good, but the terseness comes at the cost of clarity: it is an unpunctuated noun list rather than a leading statement of what the tool does. Front-loading an action verb would have cost no additional length.

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?

With no output schema and no parameters, the description is the only source of information about the return payload, and it does list the content categories well. However, it leaves open how results are scoped across tracked laws, whether output is ordered by date, and whether future amendments are separated from past ones — meaningful gaps for a changelog tool.

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?

The tool takes no parameters and the schema is trivially complete, so there is nothing for the description to disambiguate. Baseline 4 applies for a zero-parameter tool.

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 text is a noun phrase enumerating data categories (effective dates, promulgation dates, per-article revision tags, ballot reflection, upcoming amendments) for tracked laws, so the resource is identifiable but no verb states the operation. An agent can infer it returns amendment history, but must guess whether it lists, summarizes, or computes it, and there is no explicit contrast with get_statute or list_laws.

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?

There is no guidance on when to call this versus get_statute (which presumably returns statute content) or list_laws (which presumably enumerates laws). No preconditions, no exclusions, and no statement of whose tracked laws are covered.

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

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

Annotations already establish that this is a safe, read-only, idempotent operation, so the description does not need to restate safety. It adds useful context by disclosing the field categories included in the returned list and the data source (국가법령정보센터). It does not mention ordering, pagination, or what an empty result means, which keeps it below a 5.

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 a single compact sentence with the core purpose front-loaded, followed by the relevant field categories and source. Every element earns its place and there is no 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?

With no parameters and rich safety annotations, the main remaining need is to communicate what the list contains, which the description does by naming the field categories. It does not specify the return structure or ordering, but for a simple read-only list this is nearly complete.

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?

The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not introduce unnecessary parameter-like details.

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 states a specific verb-resource pair in Korean: it lists the Korean laws tracked by the voting system. It also names the returned fields (effective date, promulgation date, comparison date, tracked articles, scheduled amendments), making the purpose clear. It does not explicitly distinguish itself from siblings such as get_statute or law_changelog, so it falls short of a 5.

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?

There is no explicit guidance on when to use this tool versus alternatives like get_statute, law_changelog, or search. The phrase '투표함이 추적하는' implies the scope is limited to tracked laws, but the description never says to use this list to discover laws before fetching one with get_statute.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the output is a per-group-type summary of resolution types and quorum, but does not describe return shape, caching, or whether it is static reference data.

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 a single compact sentence with no redundant wording. The key scope, group-type dimension, and output content are all front-loaded.

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 read-only reference-list tool with one optional filter and no output schema, the description gives enough context about what the result contains: resolution types and quorum summaries by group type. It stops short of describing exact return fields or pagination, but the tool's simplicity makes that a minor gap.

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 the enum keys and the optional 'group' parameter are already documented. The description adds the full set of group-type labels, but it does not map them to the enum keys or add filtering syntax beyond the schema.

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 resource: agenda/resolution types and quorum summaries grouped by organizational type, and it enumerates the group categories. However, it does not explicitly contrast this reference-list tool with close siblings such as get_resolution_requirement, and the list/summary action is mostly carried by the title rather than the description.

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?

There is no explicit guidance on when to use this tool versus alternatives. Given the sibling get_resolution_requirement also deals with quorum requirements, the lack of routing guidance leaves the agent to infer the distinction.

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

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

The description goes beyond annotations by disclosing the append semantic ('기록이 하나 더해진다'), which tells the agent that repeat calls accumulate records rather than updating — meaningful context reinforcing idempotentHint=false. It also surfaces the auth requirement (manageToken). It does not say what the response contains (e.g., the new record id).

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?

Three compact sentences with the core action and scope front-loaded, then the side effect, then the precondition. No filler; only '기록이 하나 더해진다' borders on restating the action, but it carries real semantic weight.

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-idempotent mutation with no output schema, the description covers the essential: what is captured, that a record accumulates, and that a manageToken is required. The only gap is the return value (record identifier or confirmation), which matters if the agent must chain calls.

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 six parameters are already documented with examples. The description only restates the captured fields (date/method/recipient count) and adds no format, validation, or edge-case guidance beyond the schema; the optional 'note' and 'recipients' handling is left entirely to the schema.

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 states a specific verb and resource (기록한다 / 소집통지) plus exactly which fields are captured: date, method, and recipient count, with the scope constraint '(모든 안건)'. It is clearly distinct from siblings like create_draft_meeting or close_meeting, though it does not name them explicitly.

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?

Usage is implied rather than stated: it records a notice once one has been sent, and it discloses the prerequisite 'manageToken 필요'. There is no explicit when-not condition or reference to an alternative tool, so an agent must infer the trigger from context.

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

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: no result-set semantics, no ranking or match-quality behavior, no statement about whether it returns statutes only, agenda types only, or a combined mapping. For a search tool the description carries the burden of explaining result semantics, and here it does not.

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?

A single compact sentence with no filler, and the three query forms are listed before the target outputs. It earns its length, though it is arguably too terse given the tool's centrality.

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?

One required parameter, no output schema, and rich annotations — but the description never says what comes back (a statute list? an agenda-type classification? a mapping?) or how to use those results downstream in tools like get_resolution_requirement or judge_resolution. With no output schema to lean on, the description should close that gap and does not.

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% and the single query parameter is already documented with Korean-language examples. The description does add a mild expansion, stating the query may be a free-form question, an agenda name, or a statute name — slightly broader than the schema examples. That is a marginal gain, not a substantive one, so the 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?

The description gives a verb (찾는다) and two target resources (안건 유형, 법령), which is more than a name restatement. However, it never names the corpus being searched, and it does not distinguish this tool from siblings such as get_statute, list_laws, or list_resolution_types that superficially appear to serve the same lookup need. The purpose is inferable but ambiguous at the routing boundary.

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?

It hints at what queries are acceptable (questions, agenda names, statute names) but gives no guidance on when to pick this over get_statute or list_laws. No prerequisites, no exclusions, no follow-up routing. An agent seeing an 18-tool sibling set would still have to guess.

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

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

Annotations already flag destructive=true and idempotent=true, but the description adds material behavior the agent could not infer: the existing roster is replaced wholesale ('이미 있는 명부는 통째로 바뀐다'), the change locks after the first ballot, raw voter data is never transmitted, and manageToken is mandatory. That is a strong complement to the annotations rather than a restatement.

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 what the tool does, then the replacement behavior, the privacy rule, the timing lock, and the auth need. No sentence is 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 three-parameter mutation with no output schema, the description covers destruction, auth, privacy and the immutability window well. It stops short of describing the result (e.g. how many entries were accepted) or what happens to duplicate or invalid hashes, which an agent would need if the call fails.

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 hash, weight, meetingId and manageToken are already fully documented in the schema; baseline 3 applies. The description adds only a cross-reference that the hash rule matches create_draft_meeting, which is a useful consistency hint but no new detail on weight or entries semantics.

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 resource ('선거인 명부(해시)를 ... 올린다') plus the scope '모든 안건에', which no sibling covers. An agent immediately knows this writes a voter roster of hashes across all agenda items rather than a single ballot or notice.

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 the hard precondition '첫 표가 들어온 뒤에는 바꿀 수 없다' and the auth requirement 'manageToken 필요', which tells the agent when the call must happen. It does not name an alternative tool or explain what to do instead once voting has begun, so routing is left implicit.

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