Korea Invoices (POPBiLL 전자세금계산서 issue, query & NTS transmit)

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

The description extensively discloses behavioral traits beyond annotations: VAT computation details, auto-generation of mgt_key with format rules, transmission timing (next day unless forced), required/optional headers with source instructions, and return values. Annotations only provide flags; the description adds rich operational context.

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 dense and informative, with each sentence adding value. It is not front-loaded, as it begins with the action and then delves into details, but given the complexity of the tool, it is appropriately sized. Slight improvements could be made with bullet points for readability.

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?

The description covers the entire workflow: issue, VAT computation, auto-key, transmission, required headers, optional parameters, and return values. It explains behavior with no output schema. Given the tool's complexity and high parameter count, the description is remarkably complete and actionable.

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, baseline is 3. The description adds significant meaning beyond the schema: it explains that supplyCost and tax are computed server-side, mgt_key auto-generation rule, write_date default to KST today, and that items are line items with per-unit pricing. This additional context greatly aids correct invocation.

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 issues a Korean electronic tax invoice in one step and registers it via POPBiLL. The verb 'issue' and resource 'invoice' are specific, and the mention of 'registIssue = 즉시발행' and automatic NTS transmission distinguishes the tool's behavior from siblings like send_to_nts, though not 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?

The description explains the overall workflow and mentions send_to_nts for forced transmission, providing some context for when to use alternatives. However, it does not explicitly state when to use this tool versus query_invoice or give clear when-not conditions. The guidance is implied but not directive.

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 indicate read-only, idempotent, non-destructive behavior. The description adds significant context: it explains the GET request nature, state code meanings, NTS transmission process, credential headers (required, per-request, never stored), and optional headers. 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?

The description is front-loaded with the core purpose and API endpoint. It contains multiple sentences covering state codes, headers, and options. While informative, it could be slightly more concise, but each sentence adds necessary detail for correct usage.

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?

Given the absence of an output schema, the description compensates well by detailing return state codes and timestamps. It also covers credential setup and optional headers. However, it lacks information on error handling or what happens when the invoice is not found.

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 baseline is 3. The tool description adds some nuance (e.g., 'default' for SELL, '수탁' for TRUSTEE) but does not significantly expand beyond the schema descriptions. Thus, a 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 clearly states the tool queries a Korean electronic tax invoice by its document management number (mgt_key) via a GET endpoint. The verb 'Look up' and resource 'single 전자세금계산서' make the purpose unambiguous, and it distinguishes itself from create_invoice and send_to_nts by focusing on retrieval.

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?

No explicit guidance on when to use this tool versus siblings. It mentions send_to_nts in the state code explanation but does not provide direct usage context or exclusions. The agent must infer usage from the tool's read-only nature.

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?

Discloses behavioral traits beyond annotations: force immediate transmission, no change to invoice content, returns acceptance status, polling needed for stateCode 320. Details required and optional headers for authentication and mode. OpenWorldHint=true is reasonable given side effects; description does not contradict 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?

Well-structured: action first, usage rationale, limitations, return info, then headers. Every sentence adds value. Efficient despite length due to complexity. No fluff.

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?

Complete coverage for a transmission tool: action, usage, what it doesn't do, return value, polling follow-up, authentication setup (headers), mode selection (test/prod), and optional owner-policy headers. Given no output schema, description adequately explains expected outcome.

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%, providing baseline 3. Description adds meaning by explaining mgt_key as '문서관리번호' of the issued invoice and mgt_key_type as 'Whose document box: SELL (default) | BUY | TRUSTEE.' Also describes optional headers not in 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 action: 'FORCE immediate 국세청 (NTS) transmission of an already-issued 전자세금계산서'. It specifies the HTTP endpoint and distinguishes from sibling tools create_invoice and query_invoice by explaining what it does not do (issue or change invoice).

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?

Explicit guidance: 'call this only when you need it sent to the tax authority right now instead of waiting for the next-day batch.' Also clarifies when not to use: 'It does NOT issue the invoice' and references query_invoice for polling completion. Provides alternative (wait for next-day batch) and preconditions (invoice already issued).

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