투표함 — 전자투표 법령 자료 (Korean e-voting statutes, quorum & consult)

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — the figures include VAT — but '아무것도 바꾸지 않는다' merely restates the readOnly hint. It says nothing about the shape of the returned quote, which matters because 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?

Three short sentences, front-loaded with the calculation and its output scope, with no filler. The final sentence is close to redundant with the annotations, which is the only thing keeping it 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?

For a one-parameter, non-destructive calculator this covers the input side well. Because there is no output schema, the description carries the burden of describing the return value, and '두 갈래 … 요금' only gestures at the two-tier result without saying what a quote contains (per-tier prices, breakdown, totals).

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 'people' is fully documented with an example, so the description cannot add much. It does confirm the parameter means the voting population being priced, and it introduces the two-tier output notion that the schema lacks. 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 (요금) and adds the decisive scope detail that it prices two product tiers from a voter count. An agent can tell it is the pricing tool among law/statute/resolution siblings, though it never names or contrasts those siblings 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: call it when you need a cost estimate for a given number of voters. There is no explicit when-to-use framing, no prerequisites, and no mention of what to do instead when a quote is not what is needed.

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?

Annotations only say this is a non-read-only, non-destructive, non-idempotent call; the description adds the crucial side effect that a staff member will contact the requester, that contact name and phone are mandatory, and that the cost is 300 won per person. The only gap is that it doesn't say what the tool returns or how soon the contact happens.

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?

Front-loaded with the service definition and price, then the contact side effect, then the alternative route. Slightly redundant in that '담당자가 연락한다' and '사람에게 연락이 가는 행동이다' convey the same fact twice, but no sentence is wasted.

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 7-parameter submission tool with no output schema, the description covers the key decisions: cost, human follow-up, required contact data, and the self-service alternative. It omits expected response behavior or turnaround timing, which is a minor gap rather than a blocking one.

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 every parameter already carries examples and constraints. The description only restates that 담당자 이름·연락처 are required and mentions context fields (집회일·안건·명부 상태) that the message parameter's schema already defines, adding no new formatting or validation 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 first sentence names a specific action (applying for a custom voting-box service) with an explicit scope (the operator handles roster cleanup, setup, and tallying) and price (300 won per person). Nothing in the sibling list (law lookup, quote, resolution tools) overlaps, so an agent can identify the right tool immediately.

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 states the audience condition explicitly ('주최자가 원할 때만' – only when the organizer wants a human contacted) and names the alternative path for self-service voting with the concrete URL /w/new.html. That is a clear when-to-use / when-not-to-use boundary with a named alternative.

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.