XBOSS

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

The annotations already indicate the operation is neither read-only nor destructive, and the description adds useful context that the login uses NPKI AnySign and must precede other provider calls. It does not disclose behaviors like session timeout, repeat-login behavior, or failure outcomes, but the core side effect of establishing a login is clear.

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 ordering instruction front-loaded before the purpose. It contains no filler and does not redundantly repeat parameter details from 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?

For a simple login tool with fully documented parameters, the description provides the essential ordering context and the certificate mechanism. It could note whether to check session status afterward or what the response indicates, but the schema and straightforward operation make it sufficiently 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 description coverage is 100%, so the baseline applies: auth_provider, account_link_id, and business_registration_no are fully documented in the schema. The description's mention of 'NPKI AnySign' aligns with the auth_provider default but adds no new parameter-level 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 description states 'Login to COMWEL via NPKI AnySign certificate,' naming a specific action, resource, and authentication method. It also scopes the tool to 'this provider,' which clearly distinguishes it from sibling logins like hometax__session__login or work24__auth__npki_session__login.

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 explicitly says 'Call this FIRST before any other tool for this provider,' giving strong ordering guidance. However, it does not mention when not to use it or point to the sibling comwel__auth__session__status as a way to verify an existing session, so it lacks full exclusion/alternative 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the word 'Check' aligns with that. However, the description adds no behavioral context beyond the annotations—it does not explain what statuses are returned, whether the session is refreshed, or what happens when no session exists.

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 front-loaded sentence with no wasted words. It is adequately concise for a simple status tool, though its brevity begins to approach under-specification.

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 tool is simple, read-only, and the only optional parameter is fully documented in the schema. However, with no output schema and no description of the returned session status or its role in the login flow, the agent is left without complete context for interpreting the result.

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 account_link_id schema description already covers optionality, API-key auto-resolution, multi-certificate scenarios, and institution-specific IDs. The free-text description contributes no additional parameter semantics, 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 states a specific action, 'Check', against a specific resource, 'COMWEL session status'. The COMWEL prefix plus 'session status' clearly distinguishes it from sibling login tools and data-retrieval tools in the same provider family.

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 the sibling session/login tools. It does not say 'call after login', 'call before COMWEL info queries', or name any alternative, so the agent must infer usage from the tool name and sibling list.

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 and destructiveHint=false, so the description only adds the login prerequisite and the implicit dependency on a previously selected worker. It does not describe response format, error behavior, or what happens when required parameters are omitted – useful but limited beyond the structured 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 the critical login prerequisite front-loaded and no filler. Every clause adds information, and the purpose is stated clearly and economically.

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 definition covers purpose and authentication dependency but, with 8 parameters and no output schema, it does not describe what the returned detail contains, how flags like refund_reflection_yn affect the call, or what the response shape is. This leaves an agent partially in the dark for a tool with this many parameters.

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 carries full parameter documentation. The description adds value by relating worker_record_no, worker_resident_no, and labor_provider_yn to 'a selected worker' and by reinforcing that account_link_id must match the prior login, which helps an agent correctly source parameters from earlier steps.

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: 'Fetch COMWEL individual billed-premium detail for a selected worker.' That clearly distinguishes it from worker_select (via 'selected worker') and from premium_billing_notice (via 'billed-premium detail'), though it does not explicitly name the sibling tools.

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 clearly states a precondition: 'REQUIRES prior comwel__auth__npki_session__login call with same account_link_id.' This is valuable, but it does not explain when to use this detail tool over sibling tools like premium_billing_notice or how it depends on worker_select beyond the phrase 'selected worker.'

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?

With readOnlyHint=false and destructiveHint=false, the description adds some signal by framing the operation as 'search and select', suggesting a stateful selection rather than a pure read. However, it does not disclose what the selection does to session state or what the tool returns, leaving important behavioral context unstated.

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 no filler, and the most important prerequisite is front-loaded in an explicit 'REQUIRES' statement. Every sentence earns its place.

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 invocation prerequisite and the tool's purpose, but with no output schema, the agent is left uninformed about what a successful search/select returns and whether the selection persists for the subsequent detail inquiry. This is a meaningful gap for a stateful selection step.

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 schema already describes all parameters with 100% coverage, so the description does not need to repeat them. It adds one valuable cross-call semantic: the account_link_id must match the login call, which is not stated in the schema's parameter description.

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 ('Search and select a worker') and the resource/context ('for COMWEL individual billed-premium inquiry'). It does not explicitly contrast this tool with the sibling 'detail' tool, so it stops short of full sibling differentiation.

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 gives a clear, essential precondition: a prior comwel__auth__npki_session__login call with the same account_link_id. It also implies placement in the workflow ('for ... inquiry'), though it does not explicitly describe when not to use this tool or name 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing a hard dependency on a prior npki login session bound to the same account_link_id — a behavioral requirement an agent must know before calling. That context compensates for the absence of return-format or pagination details.

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 filler, and the most critical piece of information — the mandatory login prerequisite — is front-loaded in caps. Every word earns its place with no 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?

For a 6-parameter tool with nested objects and no output schema, the description is minimal but the rich schema carries the load. It properly flags the auth dependency. Still, it leaves the relationship to premium_billing_notice__search implicit and says nothing about return shape or error-prone cases like mixed insurance types, so it is merely adequate rather than 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 description coverage is 100% and the schema itself is richly documented (detail_keys passed from detail_candidates, detail_context passed as-is, insurance_type needed only when types mix, account_link_id auto-resolution rules). The description contributes zero parameter information, so it scores at the documented-schema baseline of 3 — the schema earns the credit, not the description.

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: 'Fetch COMWEL premium billing notice detail.' This is clear and unambiguous about the tool's core function. However, it does not differentiate from sibling tools like comwel__info__individual_billed_premium__detail or explicitly position itself as the detail counterpart to premium_billing_notice__search, so it stops 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?

The description leads with a concrete precondition: 'REQUIRES prior comwel__auth__npki_session__login call with same account_link_id.' This is a real, actionable usage context. Yet it gives no guidance on when to choose this over the near-named sibling individual_billed_premium__detail, and the intended search-then-detail flow is only implied via the schema's detail_candidates references, not stated in the description.

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 mark the operation read-only and non-destructive; the description adds an auth dependency by requiring a prior NPKI session login with a matching account_link_id. It does not describe return format, pagination, or error behavior, so its behavioral disclosure remains useful but limited.

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 the critical prerequisite front-loaded in uppercase and the operation stated plainly. There is no filler or repetition.

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 search with fully documented parameters and a known prerequisite, the description is nearly complete. The only minor gap is not explicitly noting that this returns a list-level result and that the detail siblings target individual notices, but an agent can invoke the tool correctly from the existing information.

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 input schema describes all four parameters, including the optionality and auto-resolution behavior of account_link_id, at 100% coverage. The description adds no parameter-level details, so the schema carries the full burden and 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 concrete action and resource: 'Search COMWEL premium billing notices,' which clearly identifies this as a list/search operation. It does not explicitly distinguish itself from the sibling premium_billing_notice__detail or individual_billed_premium__detail tools, so it stops 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?

The opening sentence gives an explicit precondition: a prior comwel__auth__npki_session__login with the same account_link_id. That tells the agent when in the workflow it may be invoked, but it does not discuss when to prefer this search over the sibling detail tools or any exclusions.

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 and destructiveHint=false; the description reinforces this and adds the useful clarification that it does not save or submit to the institution, plus the session prerequisite. It stops short of describing return shape or pagination, but adds real context beyond the 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 auth prerequisite is front-loaded in caps, followed by purpose and safety in three tight sentences. Slightly dense Korean phrasing but no wasted 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?

For a two-parameter read-only lookup with no output schema, the description covers prerequisite, purpose, what the codes are used for, and the fact that nothing is persisted or submitted. Only the exact return structure is unstated, which is minor here.

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 parameters are already documented, including the B112/D114/A101 examples. The description only restates those examples and adds the domain purpose of the codes, which is marginal added value over the schema; 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 and resource: retrieves common codes (code value and name) by classification id, for the reason/occupation fields of qualification acquisition/loss reports. No sibling in the list performs common-code lookup, so the agent can identify this 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?

Gives the prerequisite explicitly (prior fourinsure__session__login with the same account_link_id) and states the intended context of use (filling reason/occupation fields). It does not name an alternative tool, but no close sibling exists, 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 and destructiveHint=false, so the safety profile is covered, but the description adds valuable context: the auth requirement, the explicit non-submission/non-storage guarantee, and the fields returned despite 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 tightly scoped sentences with the prerequisite front-loaded and no filler. The read-only sentence mildly overlaps the annotation but still earns its place as an explicit guarantee for a lookup tied to a save workflow.

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 compensates by naming the returned fields, and it covers the auth prerequisite and side-effect profile. Complete enough to invoke correctly, missing only a pointer to the alternative sibling tools for the broader workflow.

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 all three parameters including the account_link_id auto-resolve behavior. The description only restates that lookup uses name and RRN, adding no 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 verb (조회/lookup) with the resource (가입자/subscriber) and the exact lookup keys and return payload (rrkey, 대표자 여부, per-insurance 자격취득일·상실일). It is easily distinguished from siblings like los_member_lookup and acqs_save.

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 clearly frames usage ('자격취득 신고서를 쓰기 전에') and states the hard prerequisite of a prior session login with the same account_link_id. It stops short of naming the alternative tool (e.g., acqs_precheck or acqs_save) for a different step.

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 and destructiveHint=false, so the safety profile is covered. The description usefully adds that it only checks and neither saves nor submits to the institution, plus the login precondition — meaningful context beyond the 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?

Three tight sentences with the prerequisite front-loaded before the purpose, and no redundant filler. Slightly repetitive bilingual phrasing but appropriately sized.

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 pre-check with annotations covering safety and 100% schema coverage, the description supplies the two things that matter most: the auth prerequisite and the no-side-effect guarantee. Nothing needed to invoke it correctly 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 coverage is 100%, so both parameters are already documented in detail. The description ties up_cvrc_no to its role (the parent receipt number under which existing entries are counted) and echoes account_link_id, but adds no syntax or format beyond the schema — 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+resource: a pre-check that counts already-written cases under a parent receipt number before a qualification-acquisition report is filed. Clear and specific, but it never distinguishes itself by name from the parallel sibling acqs_save or from los_exist_check, so an agent must infer the routing.

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?

Explicitly states the precondition (prior fourinsure__session__login with the same account_link_id) and the temporal context of use (before writing the report). However, it names no alternative tool and gives no explicit when-not condition.

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?

Beyond the destructiveHint=true annotation it discloses that this is a real write persisted at the institution, that it is irreversible through this API, and that the final submission is performed manually by the user in the institution UI. That is exactly the side-effect context an agent needs.

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?

Dense but front-loaded and mostly waste-free, leading with the auth prerequisite and the irreversibility warning. Some parameter-sourcing detail could be trimmed, but each sentence carries actionable 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?

For a destructive write with no output schema, it covers prerequisites, both call modes, side effects, and the fact that a receipt number is returned, leaving nothing an agent needs to invoke it safely.

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 the baseline is 3, but the description adds meaning not in the schema: where rrkey comes from, where the health-insurance acquisition code and occupation code are obtained, and the preview/save semantics of confirm.

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: saves the 자격취득 신고서 as a draft to the 정보연계센터 and returns a receipt number. It also distinguishes it from the sibling acqs_precheck/acqs_member_lookup by clarifying that it does not transmit the report to the institution.

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?

Explicitly requires a prior fourinsure__session__login with the same account_link_id, instructs to call once without confirm to preview and then with confirm=true after user consent, and routes parameter sourcing to siblings: rrkey from acqs_member_lookup, codes from com_cd.list.

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/destructiveHint=false, and the description reinforces this ('확인만 하며 기관에 저장하거나 제출하지 않습니다'). Crucially it adds the auth prerequisite (prior session login with matching account_link_id) that annotations cannot express, which is genuine added 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?

Front-loads the hard prerequisite, then purpose, then the parameter hint and no-write behavior in a compact sequence. Slightly dense with mixed-language phrasing but no wasted sentences.

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?

Covers prerequisite, purpose, parameter source, and side-effect profile for an 8-parameter read-only check. What the check returns (e.g., boolean vs. detail) is not described, but with no output schema that gap is minor.

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 all eight parameters including rrkey provenance and flag values. The description's note that rrkey comes from the loss-member lookup largely repeats the schema, so 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 (check for an existing loss declaration) and resource (loss declaration for one of the four insurances), and situates it in the workflow ('before writing the declaration'). An agent can distinguish it from los_save and acqs_precheck without opening a schema.

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 prerequisite ('REQUIRES prior fourinsure__session__login call with same account_link_id') and clear temporal context (call before writing the loss declaration). It does not name a sibling alternative or a when-not condition, so it stops 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?

Annotations already cover readOnlyHint/destructiveHint, but the description adds genuine context: the prior session__login requirement with matching account_link_id, and the explicit no-persistence/no-submit guarantee. It also previews the returned fields, going beyond the 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?

Front-loads the hard prerequisite, then the purpose and return contents, with no filler. Bilingual mixing is slightly less scannable but each sentence carries 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?

No output schema, but the description compensates by summarizing return values (rrkey, acquisition/loss dates per insurance, existing-report status) and the auth precondition. Complete enough for an agent 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 documents all 7 parameters; the description only reiterates that name and RRN are the lookup keys and adds no syntax or format detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (lookup a qualification-loss member by name and RRN) and clarifies it is read-only versus the save/submit flow. It does not name its closest siblings (acqs_member_lookup, los_exist_check), so it is clear but lacks explicit sibling differentiation.

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 explicit workflow context ('자격상실 신고서를 쓰기 전에') and the prerequisite login call, and excludes the write path ('저장하거나 제출하지 않습니다'). No alternatives are named by name, so no exclusions/alternative routing beyond the read/write split.

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?

Goes well past the readOnlyHint=false / destructiveHint=true annotations by explaining that this is a real persistent write at the institution, that it cannot be undone via the API, and that no transmission to the institution occurs until the user acts manually. The confirm-gating behavior is fully 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?

Dense but every sentence carries load-bearing information (prerequisite, effect, irreversibility, non-transmission, confirm workflow, parameter provenance). Slight structural penalty because it leads with the prerequisite gate rather than the purpose statement, delaying what the tool actually does.

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 still tells the agent the return value (a receipt number), the auth prerequisite, the irreversibility, and the required two-step consent flow. Nothing an agent needs to call this write correctly 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 coverage is 100%, so the schema carries the field definitions and the baseline is 3. The description adds real meaning beyond the schema: it explains that rrkey must come from the qualification-loss member lookup result and elaborates the confirm=true gating contract beyond the terse schema note.

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 (qualification-loss report saved as a draft) and names the outcome (receipt number). It clearly distinguishes itself from the read-only siblings los_member_lookup and los_exist_check, and from acqs_save by the '자격상실' scope.

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?

Explicitly states the prerequisite (prior fourinsure__session__login with the same account_link_id), the two-step call pattern (call without confirm=true to preview and get user consent, then call again with confirm=true), and the exclusion that final submission happens manually in the center's UI rather than through 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 (readOnlyHint=false, destructiveHint=false) provide limited safety info. The description adds that the tool returns an API_KEY and must be called first, which is useful behavioral context. However, it does not disclose session lifetime, side effects of creating a session, or how the API_KEY should be used subsequently.

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 sentences with zero filler. The critical sequencing instruction is front-loaded ('Call this FIRST'), followed by the action and return value. Highly efficient.

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 simple login tool, the description covers the essential purpose and ordering, but it does not explain what the API_KEY is used for, how it integrates with other tools, or the session's validity period. Since there is no output schema, the description should carry more explanatory weight.

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 parameters are fully documented in the schema. The description adds no parameter-level semantics beyond what the schema already provides, so a baseline 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 states a specific action (login) on a specific resource (FourInsure 4대보험 EDI) and names its return value (API_KEY). It also distinguishes this tool from sibling login tools for other providers by explicitly naming FourInsure and saying 'for this provider'.

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 clearly states when to use this tool: 'Call this FIRST before any other tool for this provider.' This gives a clear sequencing context. It does not explicitly mention alternatives for other providers, but that is implied by 'for this provider' and the sibling names.

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 cover the safety profile (readOnlyHint/destructiveHint). The description adds substantial behavior the annotations cannot: inclusive dates in property timezone, the five data_availability states with the critical clarification that no_rows and access_error do not mean zero, a retry rule, and a prompt-injection warning for externally-authored strings. This is exactly the value-add expected beyond structured 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?

Front-loaded with purpose then behavior; every sentence carries weight. The data_availability enumeration is long but each state is genuinely load-bearing, and the injection warning is compact and placed last where it belongs.

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 takes on the burden of explaining return semantics and does so thoroughly: timezone is returned with the result, and the data_availability states disambiguate the most likely agent misinterpretation (reading empty/error as zero). Nothing essential for a correct call 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%, and the descriptions are already rich (metric name-to-response mapping, date formats, property_id formats, account_link_id auto-resolution). The prose adds no additional parameter semantics beyond that, 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?

States a specific verb+resource+scope: 'Run a GA4 report for one property over a date range.' An agent immediately knows this fetches GA4 reporting data. It does not explicitly distinguish itself from siblings like google__search_console__performance or google__analytics__measurement__audit, so it falls short of a clean 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 explicit recovery guidance ('On no_rows, widen the date range and call again') and notes read-only status, which is useful conditional context. However it never states when to choose this tool over the sibling reporting tools (e.g. search_console__performance, measurement__audit), leaving selection to inference.

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 carry readOnlyHint/destructiveHint, and the description adds substantial behavior beyond them: no indexing request is triggered, results reflect the indexed version not a live fetch, times are UTC, a 2,000 inspections per site per day quota, the full data_availability state vocabulary (including that no_rows and access_error do not mean zero), and an injection warning about externally-authored strings.

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 operative information (safety, fidelity caveats, timezone, quota, result states, injection handling). It is on the dense side, with the data_availability enumeration and injection note making it longer than average, but none of it is filler given the absence of an output 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 supplies what the result contains, how to read data_availability, the timezone, and the quota constraint an agent needs. Combined with 100% schema coverage and read-only annotations, nothing material 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?

Schema description coverage is 100%, so all three parameters (including the site_url vs relative property distinction and the inspection_url containment rule) are fully documented in the schema. The description adds no parameter-level syntax or format detail, 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?

First sentence states a specific verb and resource (read the Google index status of one page in a Search Console site) and then enumerates exactly what is reported: indexed state, blocking causes (robots.txt, noindex, fetch errors), last crawl time, canonical URLs. Scope is narrowed to a single page, which cleanly separates it from site-wide siblings like google__search_console__performance.

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 clear context for use (inspect one page's index state) and explicit when-not statements: it never requests indexing and reports the index version rather than a live test. It stops short of routing the agent to a named alternative for other jobs (e.g. queries/impressions via google__search_console__performance), so no sibling is named.

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?

Goes well beyond the readOnlyHint/destructiveHint annotations: discloses Pacific Time and inclusive dates, that Google returns only top rows so results are always a subset, the meaning of all five data_availability states, that no_rows/access_error do not mean zero, and a prompt-injection warning about result strings. This is exactly the behavioral context structured fields cannot carry.

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-loads the purpose in the first sentence and every subsequent sentence carries distinct information (timezone, subset semantics, state meanings, safety warning). The inline enumeration of five data_availability values is dense and could be tightened, keeping it short of 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?

With no output schema, the description fully carries the return-value burden, explaining the data_availability states, subset nature of results, and timezone of dates. Nothing an agent needs to interpret or correctly retry a call 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: date inclusivity in Pacific Time and the relationship between data_state and the returned data_availability values. It does not explain row_limit/start_row paging behavior beyond what the schema already says.

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 (Read) and resource (Search Console performance) scoped to one site, and enumerates the exact metrics returned (impressions, clicks, queries). The scope and metric list make it unmistakable against the only nearby sibling, google__search_console__index_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?

Provides operational guidance for the error state ('On no_rows, widen the date range and call again') but never states when to prefer this tool over alternatives or any exclusions. Usage is implied through the described result semantics rather than an explicit when/when-not rule.

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 and destructiveHint=false, so the safety profile is covered. The description goes well beyond annotations by explaining the meaning of totalCount (record count, never fewer than rows), the collectionMeta flag (complete vs collectedCount), and explicitly instructing pagination when complete is false. This is rich behavioral disclosure well beyond 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 a single paragraph but dense and front-loaded with the most critical requirement (login) and scope (single day). It uses compact sentences and avoids fluff, though the count explanations could be tightened. Still, every sentence adds value, so it earns a four rather than a five.

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 compensates by explaining the return fields (totalCount, collectionMeta, collectedCount) and pagination logic. It covers login, date scope, and parameter nuances. An agent has everything needed to call this correctly and interpret results. Highly 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 description coverage is 100%, so the baseline is 3. However, the description adds practical context for parameters: trs_dt defaults to today, account_link_id should be explicit only with multiple certificates, and the pagination instruction ties page_num to the collectionMeta.complete flag. This goes beyond the schema's field-level descriptions and 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 opening sentence states a specific verb and resource: 'Search cash receipt issuance records for a single day (당일 발급 조회)'. This clearly distinguishes it from sibling tools like purchase search and sales search, and the same-day scope is explicit. Purpose 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 description explicitly requires a prior hometax__session__login call with the same account_link_id, and states that the endpoint is same-day only, so other dates are not supported. It does not name alternatives explicitly, but the same-day restriction and login prerequisite are clear and actionable usage 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 mark this as read-only and non-destructive, and the description adds substantial behavioral detail beyond that: the mandatory prior login, the 3-month range rejection with the exact server error message, and the nuanced pagination semantics involving totalCount, pageInfoVO.totalCount, collectionMeta.complete, and collectionMeta.collectedCount. This gives the agent actionable knowledge about how the API behaves.

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 but every sentence earns its place: prerequisite, core purpose, required parameters, date-limit rule with error message, and pagination/count interpretation. It is front-loaded with the most critical prerequisite and contains 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?

For a paginated read-only search tool with 7 parameters and no output schema, this description covers the non-obvious operational details an agent cannot infer: the 3-month cap, the exact rejection message, the distinction between totalCount and row count, and how collectionMeta indicates whether more pages exist. page_num, page_size, fetch_all_pages, and max_pages are already documented in the schema, so they do not need repeating.

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, but the description adds value beyond the schema: it emphasizes that from_date/to_date are required, specifies the accepted date formats, and ties account_link_id to the session login. It also explains the meaning of count-related response fields, even though those are output semantics rather than parameter 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?

The description clearly states the action and resource: 'Search cash receipt purchase history.' This is specific and unambiguous, and the title reinforces it. However, it does not explicitly differentiate this from the sibling cash-receipt tools (sales history, daily issue), relying on the resource name and tool name instead.

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 gives strong usage context: it requires a prior hometax session login with the same account_link_id, requires both dates, and instructs the agent to split periods longer than 3 months. It does not explicitly compare against alternative cash-receipt tools, but the prerequisites and operational constraints are 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?

The description goes well beyond the annotations by explaining the count semantics: totalCount equals pageInfoVO.totalCount and is never less than the number of rows in the response. It also introduces collectionMeta's complete and collectedCount fields and instructs the caller to ask for the next page when complete is false. This is exactly the behavioral context an agent needs given 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?

The description is four sentences and wastes no words; the prerequisite is front-loaded before the action. The counts/collectionMeta explanation is dense but necessary, and there is no redundant or promotional language.

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 search tool with no output schema, the description covers the login prerequisite, required dates, and the all-important pagination/collectionMeta behavior. It does not list the response record fields, but that is a minor omission given the tool's role as a history search and the absence of an output schema.

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. The description only re-states the date format and requiredness, adding no new parameter-level semantics. The valuable detail it adds is about response pagination, which is not parameter 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 description states a specific action and resource: 'Search cash receipt sales history.' The name and Korean title ('현금영수증 매출 내역 조회') reinforce that this is the sales-history variant, distinguishing it semantically from purchase history and summary tools. However, the description itself does not explicitly compare to sibling tools, so an agent must rely on the naming convention.

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 explicitly requires a prior hometax__session__login call with the same account_link_id, which is the first sentence and immediately orients the agent. It also explains the mandatory from_date/to_date and tells the agent to request the next page when complete is false. It does not, however, state when to prefer this tool over hometax__cash_receipt__sales__search_summary or the daily-issue search.

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 mark this as read-only and non-destructive. The description adds a valuable behavioral/operational constraint: the login session dependency and account_link_id matching requirement. This goes beyond the annotations by telling the agent what must be true before calling the tool.

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 tightly written sentences with no filler. The required login prerequisite is front-loaded, followed by the core purpose and parameter usage. Every sentence earns its place.

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 simple read-only summary tool with 100% schema coverage and only one required parameter, the description is sufficient. It covers the critical login prerequisite and parameter usage; because there is no output schema, a bit more detail about the expected result (e.g., total amount fields) could have been added, but this is minor.

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 schema already documents all parameters and their types. The description adds helpful usage semantics by pointing to cmtt_yr as the target year and qrt as the optional quarterly filter for 1-4, reinforcing how the parameters work together.

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?

Description clearly states a specific verb and resource: 'Search cash receipt sales annual summary.' The use of 'annual summary' and optional 'quarterly breakdown' differentiates it from sibling tools like hometax__cash_receipt__sales__search_history, which would handle detailed transaction search.

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?

Explicitly states the required prerequisite: a prior hometax__session__login call with the same account_link_id. It also tells the agent to use cmtt_yr for the target year and qrt for quarterly breakdown, giving clear context for invocation, though it does not explicitly describe when to prefer this tool over related history-search 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 only declare destructiveHint=true and readOnlyHint=false; the description adds that the action is irreversible, files a real application with the NTS, creates a receipt record (cvaId + rcatNo), and has no cancel action. It also instructs the agent to never set confirm=true autonomously, which is critical behavioral context. This is exactly the kind of side-effect disclosure annotations alone do not provide.

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 compact and front-loaded: prerequisite, action, irreversibility, then confirm workflow. The all-caps warnings draw attention to critical constraints without becoming noise. 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 10-parameter irreversible external action, the description covers the dependency, the irreversibility, the receipt outcome, and the exact confirm flow. It does not describe the preview response shape or how to route to sibling download/apply tools, but the schema covers parameter semantics. It is sufficient for correct invocation in most cases.

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 input schema already documents every parameter, including confirm's two-phase semantics, cert_template enums and defaults, optional account_link_id, and use_company_tin default. The description itself adds no additional parameter-level details beyond what the schema already provides. 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?

The description clearly states the action ('Apply for a certificate using the logged-in taxpayer's own details') and the resource, making it more than a tautology. It does not explicitly distinguish this generic auto tool from sibling tools like hometax__certificate__apply__business_registration or hometax__certificate__apply_with_template, so agents must infer the difference from the name. Clear, but missing explicit sibling differentiation.

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 gives explicit execution guidance: a prior hometax__session__login with the same account_link_id is required, and the preview-then-confirm=true retry workflow is spelled out. It does not, however, state when to choose this tool over the sibling certificate apply tools, so the 'when not to use' side is missing. This is clear context without explicit alternatives.

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 destructiveHint=true, but the description goes beyond by explaining the specific consequences: it files an application with the NTS, creates a receipt record (cvaId + rcatNo), and is irreversible with no cancel. It also discloses the preview/confirm behavior. This adds valuable behavioral context that annotations do not convey, and it does not contradict the destructive hint.

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 compact and well-ordered: it front-loads the prerequisite, states the purpose, then delivers the critical warning and step-by-step usage. Every sentence earns its place with no redundancy or 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 complex action with 8 parameters and no output schema, the description covers the essential behavioral context: prerequisite login, irreversibility, and the confirm workflow. It doesn't mention alternatives like reissue or auto-apply, but the name and the clear application flow are sufficient for an agent to proceed correctly. Slight gap in not differentiating from sibling certificate apply tools, but not critical.

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 all parameters are documented in the schema itself. The description does not add new meaning for most parameters; it repeats the confirm guidance already in the schema ('Omit it on the first call...'). Since the schema already provides comprehensive parameter descriptions, a baseline 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 clearly states the action ('Apply for Business Registration Certificate') with a specific resource, and the name itself distinguishes it from the reissue sibling. It doesn't explicitly contrast with siblings like apply_auto or reissue, but the verb 'Apply' and the certificate type make the purpose 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 description provides explicit prerequisites (prior login with same account_link_id) and a clear two-step workflow: call without confirm to preview, show to user, then retry with confirm=true. It also issues a strong directive ('Never set confirm=true on your own') and notes the lack of a cancel action, which fully guides an agent on when and how to invoke it.

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