WIA Code & WIA Pin Code

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the added value here is the output format (PNG), the per-silhouette capacity constraint, and the fallback behavior when capacity is exceeded (the response reports which silhouettes are possible). That overflow-handling behavior is genuinely useful context not present in the structured fields.

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 purpose before the capacity caveat. No padding, though the capacity point is repeated between the body text and the schema.

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 steps in to say the result is a PNG and that an overflow case returns feasibility information rather than failing silently. Combined with annotations that cover read-only/idempotent semantics, an agent has enough to invoke this correctly; only sibling differentiation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the full byte-capacity table for shape, so the baseline is 3. The description's capacity remark ('square is largest') largely duplicates what the schema's shape enum description already states, plus a mild nudge to shorten long URLs that the text parameter description also already carries.

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: turn text or a link into a WIA Code PNG image. That is markedly clearer than a bare restatement of the title. It does not, however, distinguish this base generator from the card/event/wifi variants among its siblings, so an agent must infer which variant applies.

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 gives actionable conditional advice within the tool (use square for long content, any silhouette for short links) and notes that oversized content triggers a feasibility response. It never says when this tool should be chosen over generate_wia_code_card/event/wifi, so tool-level 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.

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 fully covered. The description adds one genuine behavioral fact beyond them — that a scan makes the phone prompt to save the contact — but says nothing about what the tool actually returns (image, URL, payload string) or its size/rate limits.

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 with zero filler; the core action is front-loaded and the scan consequence follows briefly. Nothing needs to be trimmed.

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 5-parameter generator with full schema coverage and annotations covering safety, the description is adequate on purpose. It is thin on the return artifact, however: with no output schema, the agent still cannot tell whether it receives an image, a URL, or a code string, which is a real gap for a generator.

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 enum's shape field is already documented with byte capacities, so the schema carries parameter meaning on its own. The description contributes no additional parameter guidance, which matches the baseline 3 for a fully documented 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 concrete verb+resource: it produces a WIA Code wrapping a contact (business card) as a standard vCard, which implicitly separates it from the event/wifi siblings by payload type. It never names those siblings explicitly, so differentiation relies on the reader inferring from the content label rather than an outright contrast.

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 when-to-use statement, no prerequisites, and no mention of the alternative generators (generate_wia_code, generate_wia_code_event, generate_wia_code_wifi) that an agent must choose between. The only usage-adjacent sentence describes post-scan behavior on a phone, not when to call this tool.

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 closed-world, so the safety profile is covered. The description adds genuine context in the required time format and the scan-to-calendar effect, but says nothing about what the tool returns (a code string? an image?), which is a real gap for a generator with 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 with zero filler: what is produced, what scanning does, and the exact time format. The purpose is front-loaded and nothing is repeated.

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 code generator with full schema coverage and annotations, the description covers purpose, scan behavior and input format adequately. It leaves the return value unspecified and does not address the capacity constraints noted in the enum (e.g. the small star/boomerang limits), which an agent producing content would benefit from knowing.

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 every parameter, including the time format, shape enum and capacity table. The description merely restates the '2026-09-01 19:00' time format that the start/end descriptions already give, adding no syntax or meaning beyond the schema — the baseline 3.

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 verb and resource — generating a WIA Code that wraps a calendar event in standard iCalendar — and the event domain implicitly separates it from the card/wifi siblings. It does not, however, name any sibling tool explicitly, so the agent must infer the routing from content type alone.

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 '일정' (schedule/event) plus the outcome 'scanning adds it to a calendar', which tells the agent this is the right tool when a calendar event is wanted. There is no explicit when-not guidance and the generic generate_wia_code sibling is never mentioned as an 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 this as a read-only, idempotent, non-destructive operation, so the safety bar is met. The description adds genuine behavioral value beyond that: scanning the code connects without entering a password, and open networks should use security=nopass. It omits the output artifact format (image/QR/printable), which is the one behavioral detail an agent might still need.

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 core action, then the user-facing benefit, then the use case, then the edge case. No filler; only slight redundancy with the schema on the nopass rule.

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 is produced, but it never states the return artifact (e.g. an image, QR, or file). For a generation tool with 5 parameters and a rich enum-bearing schema, this is the main missing 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% – ssid, shape capacities, hidden, password and the security enum are all documented in the schema. The description only restates the open-network rule ('개방망이면 security 를 nopass 로'), which the schema already conveys via 'nopass = 개방망'. Baseline 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?

States a specific verb+resource: it turns Wi-Fi connection info into a WIA Code. The Wi-Fi specialization clearly distinguishes it from siblings like generate_wia_code_card or generate_wia_code_event, though those siblings are never named.

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 implied usage context ('카페·사무실·숙소 안내' – cafe/office/accommodation signage) and a conditional tip for open networks. However, it never says when to prefer this over the sibling code generators or what prerequisites exist, so the routing guidance is only inferred.

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, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, non-destructive read. The description adds that it returns explanatory content about silhouettes and capacities, but does not go beyond annotations to disclose return format, side effects, or other behavioral traits. No contradiction with annotations.

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 sentences with zero waste: the first states purpose, the second states usage context and benefit. It is front-loaded and appropriately sized for a simple reference tool.

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 no-parameter, read-only informational tool with rich annotations and no output schema, the description adequately covers what information is returned and when to call it. It could mention that the response is static reference data, but nothing critical is missing for correct invocation.

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 zero parameters, so there is nothing for the description to clarify about inputs. Per the baseline rule for zero-parameter tools, this scores a 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?

The description clearly states the tool provides information about WIA Code, including its differences from QR and its silhouettes/capacities. It distinguishes itself from the generation siblings by positioning itself as a pre-creation reference, though it does not name any sibling 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?

It gives explicit when-to-use guidance: call this before creating a code to check silhouette and capacity, which reduces failures. It does not state when not to use it or contrast with other info tools, but the context is clear.

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 this as a read-only, idempotent, non-destructive, closed-world operation, so safety is covered structurally. The description adds genuinely behavioral context the annotations cannot: v2 vs v1 precision differences and the ±10 m / ±20 m accuracy envelope, telling the agent how much to trust the result.

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 dense sentences, front-loaded with the core transform before the format/precision qualifiers. Nothing is redundant and every clause carries 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?

With no output schema, the description carries return-value burden and does state that lat/lng is produced (cell centre for v2), but it never names the returned fields or mentions error behavior for malformed codes. Adequate for a single-parameter deterministic lookup, with a small remaining 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?

With 100% schema coverage plus an example, the baseline is 3, but the description goes further by specifying that dashes are optional and that a leading country calling code such as '082-' is ignored — parsing rules the schema's bare string does not convey.

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 ('Turn a WIA Pin Code ... into latitude/longitude') and pins down the exact accepted code variants (12-digit v2, 9-digit v1), which cleanly separates it from the generate_* and encode 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?

The description implies its use case (converting a code you already hold into coordinates) but never states when to prefer it over pin_code_encode, pin_code_nearby, or get_wia_code_info, nor any exclusions or prerequisites. Usage is inferable but not guided.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value by disclosing that this is a deterministic pure calculation with no lookup, plus the output shape: a 12-digit v2 code and the 9-digit v1 code being its first 9 digits.

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 tightly written sentences, front-loaded with the transform, then the concrete example and the v1/v2 relationship, closing with the offline behavior. No filler or redundancy.

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 steps in to describe the return values (12-digit v2 plus 9-digit v1 and their relationship), which is the key missing structured information. It is nearly complete; the only residual gap is how coordinates outside any covered region behave, though 'no lookup' suggests a code is always produced.

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% (both lat and lng documented with WGS84 decimal degrees and valid ranges), so the schema does the heavy lifting. The description adds no extra parameter semantics beyond the coordinate pair, making the baseline 3 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?

States a specific verb and resource: latitude/longitude → WIA Pin Code, with a concrete example format (708-702-851-863). The direction of the transform makes it unambiguously distinct from the sibling pin_code_decode, and it notes the secondary 9-digit v1 output.

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 by the tool name and the inverse sibling pin_code_decode; there is no explicit 'use this when you have coordinates and need a code' statement or exclusion guidance. The 'no lookup / pure calculation' note hints at when it is preferable (offline, no DB) but is framed as behavior rather than selection advice.

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, closed-world behavior. The description adds real behavioral context beyond them: results are ordered nearest-first and include distance and direction, and radius is bounded 10–200 m. It omits result-count limits or empty-result behavior, so not 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?

Three short sentences, front-loaded with the core action and ordering, then use case, then input modes and bounds. Every sentence carries information; 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?

No output schema exists, and the description covers the key return characteristics (ordering, distance, direction), which is the essential missing piece. It stops short of noting result-count caps or no-match behavior, leaving a small 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 baseline is 3, but the description adds non-obvious semantics: the caller supplies *either* code *or* lat+lng, which the flat all-optional schema does not express. Radius range is merely repeated from 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 (List) plus resource (WIA Pin Code cells) and adds scope/ordering ('around a point or a code, nearest first, with distance and direction'). This is clearly distinct from siblings like pin_code_decode/encode or generate_wia_code, which do different things.

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 concrete use case ('which codes cover this building/plaza') and states the two accepted input modes plus the radius range, so the agent knows when and how to call it. It does not name alternatives or state when-not to use it, so it falls short of 5.

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