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 (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 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.

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

The description discloses that the action is IRREVERSIBLE, files an application with the NTS, creates a receipt record (cvaId + rcatNo), and has no cancel action. This goes well beyond the annotations (readOnlyHint=false, destructiveHint=true) by explaining the exact consequence and the absence of undo. 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 compact and front-loaded with the most critical information (prerequisite, irreversibility, two-step confirm flow). Every sentence earns its place; no filler or repetition of schema details.

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, irreversible action with 8 parameters and no output schema, the description covers the prerequisite, the workflow, the irreversibility, and the confirm safety rule. The only minor gap is not describing the preview/response format, but the two-step flow is fully specified and the schema covers parameters. This is complete for safe 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 the schema already documents all 8 parameters. The description adds value by explaining the confirm parameter's two-phase semantics and the account_link_id auto-resolution behavior, but most parameter meaning is already in 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?

The description states a specific verb ('Apply for Business Registration Reissuance') and resource, and the title confirms the Korean equivalent. It clearly distinguishes this from sibling tools like hometax__certificate__apply__business_registration (initial application) and hometax__certificate__apply_auto, making 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 explicitly states the prerequisite (prior hometax__session__login with same account_link_id), the required two-step flow (call without confirm to preview, show to user, retry with confirm=true), and a hard rule ('Never set confirm=true on your own'). This is exemplary 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 flag destructiveHint=true, and the description substantially enriches this by disclosing the concrete consequences: an application is filed with the NTS, a receipt record (cvaId + rcatNo) is created, and no cancel action exists. It also discloses the auth dependency and the confirm safety rule — exactly the context annotations alone cannot convey. 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?

Four dense sentences, each earning its place: prerequisite, action, irreversibility with concrete effects, and the preview/confirm safety rule. Critical warnings are front-loaded ahead of the workflow instructions, though the block could be structurally clearer; it remains efficient with 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 destructive two-phase tool with 13 parameters and no output schema, the description covers the prerequisite, the correct call sequence, irreversibility, and hints at the response shape (cvaId + rcatNo). It would benefit from describing the preview response contents and the follow-up download step, but nothing needed to call it safely 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%, so the baseline of 3 applies; all 13 parameters are documented in the schema. The description adds only flow-level context for confirm and account_link_id (the preview/confirm sequence and the same-ID-as-login requirement), which is helpful but does not add per-parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-object pair — 'Apply for Standard Financial Statement Certificate' — that matches the Korean title and precisely identifies the resource. With many hometax__certificate__apply__* siblings (business_registration, tax_payment_record, vat_standard, etc.), naming the exact certificate type is sufficient 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 states a hard prerequisite ('REQUIRES prior hometax__session__login call with same account_link_id') and a mandatory two-phase workflow: preview first, retry with confirm=true, plus the rule 'Never set confirm=true on your own.' It does not explicitly name alternatives or when-not-to-use conditions relative to sibling apply tools, so it falls short of a full 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?

The description goes beyond the annotations by stating that the action is IRREVERSIBLE, files an application with the NTS, creates a receipt record (cvaId + rcatNo), and has no cancel action. It also warns against setting confirm=true on one's own, which is critical behavioral context not present in 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 description is front-loaded with the most critical requirement (prior login), then states purpose, then irreversibility, then the confirm workflow. Each sentence adds essential operational information without 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?

With 8 parameters and no output schema, the description covers the prerequisites, the irreversible nature, and the confirm workflow, which are the most critical operational details. It does not describe the preview content or the final response structure, but the mention of cvaId and rcatNo gives a partial return hint. This is reasonably complete for a complex application tool.

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

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

The input schema already describes all 8 parameters with 100% coverage. The description adds no parameter-specific meaning beyond the schema, so the 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 that this tool applies for a National Tax Payment Certificate from Hometax, using the specific verb 'apply' and the specific resource. It distinguishes itself from sibling certificate application tools by naming the certificate type explicitly, even though it does not name a sibling.

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 usage conditions: it requires a prior hometax__session__login call with the same account_link_id, and it prescribes a two-step workflow (preview without confirm, then retry with confirm=true). It does not, however, name alternatives or exclusion conditions, so it stops short of full when/when-not 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 description goes well beyond the destructiveHint annotation by explaining the exact consequence: the application is filed irreversibly with the NTS, a receipt record (cvaId + rcatNo) is created, and no cancel action exists. It also discloses the confirmation safeguard and the need for user approval, which is valuable behavioral 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?

Four dense sentences carry the prerequisite, irreversibility warning, confirm workflow, and a firm safety rule without wasted words. Critical information is front-loaded, making the description easy to scan and act on.

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 tool with 12 parameters and no output schema, the description covers the essential context: prerequisite, irreversibility, receipt record creation, and the required preview-confirm sequence. It does not explain what the preview looks like or where cvaId/rcatNo appear in the response, but the workflow is sufficiently complete 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 the schema already documents all 12 parameters. The description reinforces the confirm parameter's workflow semantics but does not add substantial meaning beyond what the parameter descriptions already state. This matches the baseline of 3 for high schema coverage.

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 uses a specific verb and resource: 'Apply for Tax Payment Record Certificate,' which clearly identifies the action and object. It does not explicitly differentiate from sibling certificate-apply tools such as national_tax_payment or business_registration, but the resource name is specific enough to avoid major ambiguity.

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 usage context: it requires a prior hometax__session__login with the same account_link_id and prescribes a two-step preview-then-confirm workflow. It clearly instructs the agent never to set confirm=true independently, which is strong usage guidance, though it does not explicitly contrast this tool with sibling certificate-apply 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 only carry coarse flags (readOnlyHint=false, destructiveHint=true); the description concretizes them by disclosing that the call files an irreversible application with the NTS, creates a receipt record (cvaId + rcatNo), and offers no cancel action. It also reveals the safe preview path before the irreversible step — exactly the behavioral context annotations cannot express. 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?

Four sentences, each substantive: prerequisite, purpose, irreversibility warning, and the two-step confirm discipline. Nothing is wasted and the most critical constraint (prior login) is front-loaded. The heavy ALL-CAPS emphasis is stylistically loud but not redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-stakes irreversible filing tool with 8 parameters, the description delivers the critical behavioral context (login prerequisite, preview-before-confirm, no cancel) while the schema carries parameter documentation at 100%. Mentioning the receipt record (cvaId + rcatNo) partially compensates for the absent output schema. Code-valued parameters lack enumerations, but that is a schema gap, not a description gap.

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

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

Schema description coverage is 100%, so the baseline of 3 applies — all 8 parameters are already documented in the schema. The description's confirm-workflow guidance overlaps with the schema's own confirm parameter description and adds no new meaning for the other parameters (adrOpYn, amtOpYn, cvaDcumGranMthdCd, etc.).

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?

'Apply for VAT Standard Certificate' states a specific verb and resource, and naming the certificate type distinguishes it from sibling apply tools (business_registration, financial_statement, tax_payment_record). However, this differentiation comes primarily from the tool name/title itself; the description largely restates the purpose rather than adding new distinguishing context, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear prerequisite (prior hometax__session__login with the same account_link_id) and a precise invocation sequence (call without confirm for a preview, show the user, then retry with confirm=true), plus an explicit prohibition against autonomous confirmation. It does not name sibling alternatives or state when-not-to-use, but the workflow and precondition provide clear usage context.

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

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

Beyond the annotations (destructiveHint=true), the description discloses that the action is irreversible, files an application with the NTS, and creates a receipt record. It also warns about the no-cancel nature, which is critical for a destructive operation. This adds substantial behavioral 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?

Three concise sentences that front-load the most critical information (login requirement, irreversibility) before the usage flow. No wasted words; every sentence adds essential guidance.

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 9-parameter tool with no output schema, the description covers the prerequisites (login), side effects (irreversible, receipt creation), and the confirm workflow. It also mentions the receipt identifiers (cvaId, rcatNo) for the agent's awareness. Nothing critical 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. The description adds value by linking account_link_id to the login requirement and explaining the confirm parameter's role in the preview/confirm flow. While the schema already documents parameters well, the description reinforces the critical confirm semantics and the template selection context.

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's purpose: applying for a certificate with an explicitly chosen template. It distinguishes this from generic auto-apply and specific certificate types (like business registration) by emphasizing template selection, making it easy for an agent to know when to use this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly requires a prior login with the same account_link_id, and provides a precise two-step workflow: call without confirm to get a preview, then retry with confirm=true after user approval. It also gives a clear prohibition ('Never set confirm=true on your own'), which is actionable guidance for safe usage.

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/non-destructive; the description adds useful context by specifying that the result is a base64-encoded PDF and that a prior login with the matching account_link_id is required. 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?

Three short sentences with the precondition front-loaded before the action. Every sentence carries distinct information: prerequisite, action+output format, and parameter source. 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 tool with no output schema, the description compensates by stating the output is a base64-encoded PDF, and it covers the only hard prerequisites (prior login and parameter provenance). Between the schema's parameter descriptions and this overview, an agent has enough to call the tool 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?

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds acquisition context (where cva_id/rcat_no come from, optional rpt_pkg_pth lookup) but does not redefine the parameters' meanings; the schema remains the primary source.

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 action ('Download an issued certificate as PDF'), identifies the output encoding (base64), and clearly separates this download tool from the sibling apply/list tools by referencing 'issued certificate' and the application-result source. The verb+resource+format specificity is enough for an agent to know what it does.

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 ('REQUIRES prior hometax__session__login call with same account_link_id') and tells the agent exactly where to obtain cva_id/rcat_no: from hometax__certificate__apply_auto or apply_with_template. It does not explicitly discuss when not to use it or mention the certificate-list alternative, so it falls short of a full 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?

Beyond the readOnlyHint annotation, the description adds critical behavioral detail: the default 3-day window, the misleading empty-result behavior, the one-calendar-month limit, and the institution returning an empty list instead of an error for long periods. This is exactly the kind of non-obvious runtime behavior 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?

The description is dense but every sentence earns its place. It front-loads the mandatory prerequisite, then states purpose, read-only nature, date defaults, and edge-case behavior in a structured, scannable way.

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 list operation with no output schema, the description covers prerequisites, defaults, pagination-relevant date constraints, failure semantics, and the key returned identifiers. An agent has what it needs to call this tool correctly and interpret empty results.

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. The description adds value beyond the schema by explaining that both dates must be sent together, that omitting them means a 3-day window, and that periods longer than one month are refused and should be split into monthly calls.

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: 'List certificate applications already filed at Hometax with their receipt ids (cvaId, rcatNo).' It clearly distinguishes this read/list operation from sibling apply/download tools by emphasizing 'already filed.'

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, giving a clear precondition. It also provides concrete guidance on date usage: 'Send both dates or neither' and how to handle empty results by widening the period. It does not explicitly name alternatives, but the conditions 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?

Annotations already cover readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: the tool requires a prior login and guarantees that its returned slugs are the only accepted values for cert_template. It does not describe failure behavior or output format, but the safety profile is already covered.

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, no filler. The prerequisite is front-loaded, the action is stated directly, and the final sentence adds a high-value constraint about slug validity. 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 listing tool with one optional parameter, this is complete: it states the precondition, the purpose, and the meaning of the return values. The lack of an output schema is mitigated because the description already tells the agent that the result is the set of cert_template-accepted slugs.

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 optional account_link_id parameter is already fully documented in the schema. The description does not need to add parameter detail and does not meaningfully expand on it beyond tying it to the login prerequisite.

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 uses a specific verb ('List') and resource ('certificate templates that can be applied for'), and adds a critical scoping detail: the returned slugs are exactly the values accepted by cert_template, and nothing else. This clearly distinguishes the tool from sibling apply/list/download certificate 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?

It gives an explicit prerequisite: a prior hometax__session__login call with the same account_link_id. It also implicitly routes the agent to use these slugs with cert_template, but it does not explicitly name the alternative tool or state when not to use this one.

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 known. The description adds a behavioral requirement (prior login with same account_link_id) and specifies the purpose, which helps the agent understand the operational context. It does not describe the return format or any other behavioral nuances, but given the annotation coverage, this is adequate.

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 no fluff. The critical prerequisite is front-loaded, followed by a concise statement of the tool's purpose. Every word earns its place, making it highly efficient and easy to parse.

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 operation with one optional parameter and no output schema, the description covers the essential context: the prerequisite and the purpose. It does not explain what the returned business info contains, but the tool name and purpose give a reasonable expectation. The lack of sibling differentiation is a minor gap, but overall the description is sufficient for an agent to invoke 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%, and the parameter description in the schema is thorough (explains optionality, auto-resolution, multiple certificates, and cross-institution uniqueness). The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate when the schema carries the full burden.

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 verb 'Get' and the resource 'business info' with a purpose ('for e-tax invoice purposes'). It is specific enough to indicate what the tool does, though it does not explicitly differentiate it from the sibling 'hometax__etax__client_info__get', which could be a similar lookup. The resource and purpose are unambiguous, but sibling differentiation is missing.

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 a clear prerequisite (prior hometax__session__login with the same account_link_id), which is valuable guidance for when the tool can be used. However, it does not mention when to choose this tool over alternatives, nor any exclusions. The usage context is implied rather than explicitly contrasted with similar tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the critical login prerequisite, which is behavioral context not present in annotations. It does not describe any other behaviors, but for a read-only getter this is adequate. 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 no redundancy. The prerequisite is front-loaded and the purpose is stated directly. Every word 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 tool with complete schema and safety annotations, the description covers the essential context: the login requirement and the purpose. It does not describe the return format, but with no output schema and a self-explanatory name, this is a minor gap. It is complete enough for an agent to call 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?

The schema has 100% coverage and the account_link_id parameter is already well-documented in the schema description, including when to provide it and how it resolves. The tool description adds no additional parameter meaning, so a baseline of 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool gets client/counterparty info for e-tax invoicing, which is a specific verb and resource. It does not explicitly name a sibling alternative like hometax__etax__business_info__get, but the name and context make the distinction clear. It is clear but lacks explicit sibling differentiation, so a 4 is appropriate.

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 states the prerequisite: 'REQUIRES prior hometax__session__login call with same account_link_id.' This is a clear condition for use. It does not mention when not to use or name alternatives, but for a simple lookup tool the prerequisite guidance is sufficient.

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 readOnlyHint=false and destructiveHint=true, but the description goes well beyond them by spelling out real-world consequences: buyer notification, automatic entry into VAT filing, irreversibility, and correction only via a 수정세금계산서. It also discloses the preview/confirm safety behavior and explicitly forbids setting confirm=true autonomously.

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?

Every sentence earns its place: prerequisite, core action, legal consequence, two-step confirmation workflow, and a blunt safety rule. The key constraints are front-loaded with REQUIRES and IRREVERSIBLE, and the whole description is compact for a destructive 12-parameter 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 complex destructive tool with no output schema, the description still gives an agent everything needed to execute safely and correctly: when to call, what the first call returns (a preview), what to do with it, and how to confirm. The explicit preview/approval contract compensates for the lack of a documented return 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?

With 100% schema description coverage, the schema carries most of the parameter load, but the description adds important cross-parameter meaning: confirm is tied to the preview-then-approve workflow, and account_link_id must match a prior login session. These relationships are not inferable from the individual parameter descriptions alone.

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 precise action — issue an e-tax invoice to 국세청 — and adds a key behavioral distinction from the modify/search siblings by noting an issued invoice can only be corrected via a 수정세금계산서. The resource and target are explicit, so an agent can immediately tell this apart from invoice search or modify 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?

It gives an explicit prerequisite (prior hometax__session__login with the same account_link_id) and a precise two-step protocol: call without confirm first to get a preview, show the user, then retry with confirm=true only after approval. It stops short of explicitly naming sibling modify/search tools and stating when not to use this tool, but the required 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 destructiveHint=true bottles, but the description adds crucial behavioral context: the operation is IRREVERSIBLE, requires a preview-confirm flow, and the reason code is recorded at the National Tax Service and cannot be undone. It also warns about late-issuance penalties for reason 04. These go well beyond the annotation flags.

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 sentences, front-loaded with the prerequisite, then purpose, then workflow, then a critical user-communication instruction. Every sentence earns its place; no redundant detail.

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 and irreversible operation with no output schema, the description covers all essential contexts: login prerequisite, preview-confirm safety flow, irreversibility, and the mandate to ask the user for the reason. It is sufficiently complete for an agent to execute 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?

Schema coverage is 100% and the schema already documents confirm's preview-approval requirement)Skip instruction, old_aprv_no's format/source, and reason codes' details. The description adds only marginal parameter meaning beyond the schema: it emphasizes the need to pass etxiv_mdf_rsn_cd (already in schema) and reinforces the confirm workflow. 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 verb ('Issue a correcting e-tax invoice'), the resource (an existing invoice via old_aprv_no), and the context (modification). It distinguishes itself from the ordinary hometax__etax__invoice__issue by saying 'against an existing one' and the title matches.

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 prerequisite (login with same account_link_id), a step-by-step workflow (preview first, show to user, then retry with confirm=true), and an explicit instruction to ask the user for the correction reason. It does not explicitly contrast with sibling tools like invoice__issue, but the purpose and required parameters make the distinction 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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context beyond the annotations: the session prerequisite and the dependency on a prior search_list call. This is useful operational information that the structured metadata does not convey.

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 no filler. It front-loads the critical prerequisite, then states the action and parameter source. Every clause 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 read-only detail lookup with 100% parameter coverage and clear annotations, the description is largely complete: it covers the login prerequisite, the required identifier, and how to obtain that identifier. The only minor gap is the absence of explicit return-field details, but the phrase 'detailed information' plus the absence of an output schema makes this acceptable.

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 both parameters, including the etan format and how to obtain it. The description repeats the etan sourcing but does not add new semantic meaning beyond what the schema already provides. A baseline of 3 is appropriate here.

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: 'Get detailed information for a specific e-tax invoice by its 승인번호 (etan).' It also references the sibling search_list tool as the source of the etan, which distinguishes this detail-retrieval tool from list/search/statistics 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 establishes usage context: it requires a prior hometax__session__login call with the same account_link_id, and it explicitly tells the agent to obtain etan from hometax__etax__invoice__search_list results. It does not explicitly state when-not-to-use or compare against search_statistics/search_summary, but the context is unambiguous.

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 valuable behavioral context beyond those annotations: the mandatory prior login, the exact NTS rejection message '6개월이상은 조회할 수 없습니다.', and the resulting 6-month window constraint. It does not describe pagination or rate limits, but the added context is substantial and there is no contradiction.

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: the prerequisite, action, parameter guidance, and server-side constraint are stated in a handful of purposeful sentences with no filler. The important NTS range-limit warning is placed at the end without bloating the text.

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 list-search tool with no output schema, the description covers the core operation, login prerequisite, date formats, direction codes, and the critical 6-month range restriction. The main gap is explicit guidance on how this tool relates to sibling invoice search tools, which is already penalized under usage_guidelines.

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 description mostly restates what the schema already says: date formats for from_date/to_date and the '01'/'02' enum meaning for prh_sls_cl_cd. It adds emphasis but no genuinely new parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search e-tax invoices by date range', and the title '전자세금계산서 목록 조회' reinforces list retrieval. However, it does not explicitly distinguish itself from sibling tools such as search_detail, search_summary, or search_statistics, so it misses 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 clear usage context: it requires a prior hometax__session__login with the same account_link_id, documents date formats, and explains the prh_sls_cl_cd direction values. It also warns about the 6-month query limit and advises splitting longer periods, but it never names alternatives or says when to prefer a sibling search 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=true and destructiveHint=false, so the safety profile is covered. The description adds a non-obvious dependency on an existing session and reinforces the YYYYMM date constraint. However, it does not disclose what the returned statistics contain or how pagination behaves, which matters for a tool 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?

The description is two short sentences with no filler. The critical prerequisite is front-loaded, followed by the core action and the most important parameter-format example. 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 adequately covers invocation requirements: session dependency, date-range format, and the tool's core purpose. However, without an output schema, the substance of the returned 'monthly statistics' is left undefined, and the relationship to sibling search_summary/search_list tools is not clarified. It is sufficient for a straightforward call but not fully self-contained.

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 description adds value by giving a concrete date-range example and tying account_link_id to the preceding login call, which is not obvious from the schema alone. The remaining parameters are already well-documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete action and resource: 'Search e-tax invoice monthly statistics.' This clearly distinguishes it from invoice issue/modify tools. However, it does not explicitly contrast it with sibling search_list or search_summary tools, so it stops short of full 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 provides a clear prerequisite: a prior hometax__session__login call with the same account_link_id. It also gives explicit date-format guidance for the required parameters. It does not name alternative tools or say when not to use this one, but the usage 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond those annotations: the hard session prerequisite and the conditional dependency between date_type and the other parameters. It does not contradict the annotations in any way.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph front-loaded with the critical precondition ('REQUIRES...') before the purpose. The numbered date modes are easy to scan. It is slightly packed — the parameter requirements are crammed into parentheticals — but no sentence is wasted and the essential info is immediate.

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 tool with no output schema, the description covers the three key agent-facing needs: the login prerequisite, how to pick a date mode, and the search_type semantics. It handles the conditional-parameter complexity well. Minor gaps: enum defaults (date_type='01', search_type='01') are only implied, and return values are unspecified, but the schema carries most of the remaining burden.

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 individually documents all 10 parameters, setting a baseline of 3. The description earns its keep by explaining the cross-parameter combinatorics that the flat schema cannot express — that date_type='01' REQUIRES start_date+end_date, '02' REQUIRES year+month, and '03' REQUIRES year+quarter, plus the issued/received mapping of search_type. This relational meaning is above baseline value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Search e-tax invoice summary (totals)') and the title '전자세금계산서 합계 조회' reinforces the aggregation purpose. It is clearly a read-only summary search. However, it does not explicitly distinguish itself from the near-sibling hometax__etax__invoice__search_statistics, which sounds functionally similar, so an agent could hesitate between the two.

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 is rich in usage context: it mandates a prior login ('REQUIRES prior hometax__session__login call with same account_link_id') and precisely prescribes the three mutually exclusive date modes with their required parameter combinations. It does not, however, state when NOT to use this tool or name alternative tools (e.g., search_list vs search_summary), so the exclusion dimension is absent.

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 indicate readOnlyHint=false and destructiveHint=false, so the description adds useful context by naming the authentication method (NPKI certificate) and noting that it returns a session credential. However, it does not disclose side effects such as creating a server-side session or invalidating prior sessions.

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 no filler. The critical 'call first' instruction is front-loaded, and the authentication method and return value are stated efficiently.

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 zero required parameters and no output schema, the description is sufficiently complete: it explains when to call it, how authentication works, and what is returned. It could add session lifetime or propagation details, but these are not essential for the agent to invoke the tool 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?

The single optional parameter account_link_id is fully documented in the schema with 100% coverage, including guidance about when to provide it explicitly. The description adds no parameter-level detail, so the schema carries the burden as expected.

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 uses a specific verb and resource: 'Login to Hometax via NPKI certificate' and explicitly says to call it FIRST before any other provider tool. This clearly distinguishes it from sibling tools like hometax__session__user_info and other provider login 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 gives clear usage context: 'Call this FIRST before any other tool for this provider.' It does not explicitly state when not to use it or mention alternatives for already-active sessions, but the ordering directive is strong and actionable.

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, covering the safety profile. The description adds no extra behavioral context beyond the basic purpose, such as what happens if no session exists or what fields are returned. With annotations covering the safety aspects, a 3 is appropriate as the description contributes minimal additional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that clearly states the action and target. There is no unnecessary text, and the core purpose is front-loaded. It is optimally brief for the information conveyed.

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 retrieval tool with one optional parameter and full schema coverage, the description is largely sufficient. However, it could mention the implicit requirement of an active session or clarify that it returns the current user's details, which would improve completeness. Given the annotations cover safety, this minor gap keeps it at a 4 rather than a 5.

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 description coverage is 100% for the single optional parameter, so the schema already documents its meaning and usage. The tool description does not add any further explanation about the parameter's role or multi-institution distinctions. Following the baseline for high coverage, this is a 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?

The description states a specific verb ('Retrieve') and a clear resource ('logged-in user info from Hometax'). This distinguishes it from sibling tools like hometax__session__login (which performs login) and other Hometax data retrieval tools. The purpose is unambiguous and instantly understandable.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as an active session, nor does it explain when the optional account_link_id would be needed. The context is implied by the name and description, but explicit usage conditions are absent.

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 value by disclosing the session-login dependency with the same account_link_id, which is behavioral context beyond the annotations. It does not cover output shape or scope, but for a simple read tool with annotations present this is acceptable.

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 no filler; the critical precondition is front-loaded before the purpose statement. Slightly more could be added (e.g., sibling differentiation), but the structure is efficient and the most important operational fact leads.

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 single-optional-parameter read-only tool with complete schema coverage and annotations, the description covers the key prerequisite. The main gaps are the lack of differentiation from the close sibling search_status and no hint about what 'detailed' information is returned, leaving an agent to guess which variant to choose.

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

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

Schema description coverage is 100%; the schema fully documents account_link_id as an optional UUID v4 with auto-resolution behavior. The description adds only the 'same account_link_id' linkage to the login call, a minor semantic tie-in. Baseline 3 is appropriate since 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?

The description states a specific verb and resource — 'Search detailed business registration information' — matching the tool name and Korean title (사업자등록 정보 조회). It is clear about the domain, but it does not distinguish itself from the near-sibling hometax__tax__business_registration__search_status; 'detailed' is only an implicit differentiator.

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 precondition: 'REQUIRES prior hometax__session__login call with same account_link_id,' which is useful operational guidance. However, it provides no when-to-use versus alternatives or exclusions — notably nothing clarifying when to pick this over search_status or the public opendata__nts__status lookups.

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 known. The description adds crucial behavioral context beyond the annotations by mandating a prior login and requiring the same account_link_id, which is material for correct invocation. It relies on the schema for format details, which is acceptable.

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, each carrying essential information: the prerequisite warning and the core purpose. The most critical constraint (login requirement) is front-loaded, and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters, no output schema, and annotations covering safety, the description provides the essential context: a mandatory prerequisite and the search-by-number semantics. It does not describe the response payload, but for a read-only status lookup the core agent needs is present.

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

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

Schema description coverage is 100% and both parameters are already well documented, including the optional account_link_id behavior and automatic hyphen stripping for txpr_dscm_no. The description's mention of 'same account_link_id' reinforces the schema but does not add new semantic information, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Search business registration status') and a precise resource ('business registration number'), which cleanly identifies what the tool does. The Korean title reinforces the same concept确, and the scope is unambiguous even though the description doesn't explicitly distinguish from the sibling hometax__tax__business_registration__search_info.

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 hometax__session__login call with the same account_link_id, giving a concrete precondition and tying the account_link_id parameter to the session. It does not mention when to prefer this over the similarly named search_info sibling, but the login prerequisite and the search-by-number instruction clearly frame the intended context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by requiring a prior hometax session login and tying it to account_link_id. It does not mention return format or pagination behavior, but the auth requirement is meaningful 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?

Two sentences with no filler. The prerequisite is front-loaded, and the second sentence efficiently maps the core parameters. Every word 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 required prerequisites and core parameters are covered, and the schema handles the rest of the parameter details. However, with no output schema and no description of what the search returns or how pagination behaves, the description is slightly incomplete for an agent trying to use the result correctly.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including formats and defaults. The description's mention of 'bsno', 'stl_yr', and 'qrt_from/qrt_to' reinforces which parameters matter, but adds no meaning beyond what the schema already provides.

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: 'Search credit card sales data' with business number, year, and quarter parameters. It is clearly distinguishable from most siblings by the 'credit card' scope, though it does not explicitly name an alternative or contrast with similar hometax search 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 explicitly states a required precondition: prior hometax__session__login with the same account_link_id. This is strong usage guidance for an authenticated data-lookup tool, but it does not explicitly say when to prefer this tool over alternatives or when not to use it.

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, and the description adds valuable behavioral context by requiring a prior login with a matching account_link_id. It does not describe failure modes, but it does not contradict the annotations either.

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. The critical prerequisite is front-loaded before the action statement, and 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 read-only status lookup with one optional parameter, the description plus schema and annotations are nearly sufficient for correct invocation. It does not describe the exact shape or possible values of the returned status, but this is unlikely to prevent an agent from calling the tool 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?

The input schema already documents account_link_id fully, including optionality and auto-resolution. The description adds one non-obvious semantic detail: the account_link_id must be the same as the one used in the prior login, which is useful beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific action ('Check electronic notice reception status') and resource, so an agent knows what the tool does. It is not a tautology and is clearly scoped to electronic notices, though it does not explicitly differentiate itself from related siblings like hometax__tax__notice__search_history.

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 an explicit prerequisite: a prior hometax__session__login call with the same account_link_id. This is clear invocation context, but it does not address when to choose this tool over alternatives or when not to use it.

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 safety is covered. The description adds the dependency on a prior login and the account_link_id matching requirement, which is valuable behavioral context beyond annotations. It does not disclose pagination behavior or return format, but that is a minor gap given the annotation coverage.

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, efficient sentence that front-loads the critical login requirement before stating the purpose. There is no filler or redundant phrasing; every part 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 read-only search tool with two self-documented parameters and no output schema, the description covers the essential purpose and the critical prerequisite. It does not detail what fields are returned, but the tool name and title convey the subject matter sufficiently, and the schema handles parameter semantics.

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 provides 100% coverage of both parameters, including page_num's default and account_link_id's optional/resolution behavior. The description adds no parameter-specific information, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb-resource pair: 'Search assigned tax agent information.' The Korean title '나의세무대리인 조회' corroborates the purpose. While it doesn't explicitly differentiate from sibling search tools like hometax__tax__payment_statement__search, the specific resource 'assigned tax agent' is distinct enough.

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, actionable precondition: 'REQUIRES prior hometax__session__login call with same account_link_id.' This is strong contextual guidance for when the tool can be used. However, it does not mention alternatives or exclusions relative to other search tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds the login prerequisite and the 10-year date restriction, which are behavioral requirements not covered by annotations. It does not contradict annotations and adds meaningful context, though it does not describe pagination behavior (which is already handled by schema defaults).

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, front-loaded with the critical prerequisite. Every sentence earns its place with no filler. It is appropriately sized for the tool's simplicity.

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 search tool with no output schema, the description covers purpose, prerequisite, date format, and a time restriction. It does not explain what a 'tax notice' includes, but given the simplicity and that annotations cover safety, it is largely complete. A minor gap is not explicitly stating that page_num/page_size defaults apply, but those are in the 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 coverage is 100%, so all parameters have descriptions. The description adds the date range limit (last 10 years) and clarifies that account_link_id must match the prior login, which is beyond the schema. This is useful additional semantics that help the agent use the parameters correctly.

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 clear verb and resource: 'Search tax notice history.' This is specific and distinguishes it from many other search tools in the sibling list (e.g., overdue__search_history, payment_due__search_or_pay). However, it does not explicitly differentiate itself from these similar tools, so it is clear but not fully distinctive.

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 an explicit prerequisite (prior hometax__session__login with same account_link_id), a date format instruction (YYYYMMDD), and a constraint (start dates within last 10 years). This is strong usage guidance, but it does not explicitly state when to prefer this over alternative search tools, so it is clear but lacks 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?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses several behaviors: the login prerequisite, the NTIS default period when no dates are given, and the default page size of 3 rows per page. These are value-adding and not present in the annotations. 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 three sentences with no fluff. It front-loads the critical login requirement, then covers period and pagination. Every sentence earns its place and the structure is 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?

Given 7 parameters and no output schema, the description covers the key prerequisites (login), period behavior, and pagination. It does not describe the return format or detail all optional filters, but the schema handles those. It is sufficient for an agent to call correctly, though a bit more on output could improve completeness.

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 each parameter has a description, so baseline is 3. The description adds semantic context for strt_dt/end_dt (narrowing period, default behavior) and page_size (default 3 rows), enriching the schema. However, it does not explain all parameters' practical implications, so a 4 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 'Search overdue tax history (체납 내역)' with a specific verb and resource. It clearly identifies the tool as a search for overdue tax history, distinguishing it from sibling search tools like hometax__tax__notice__search_history and hometax__tax__refund__search_detail.

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 clear usage context: it explicitly requires a prior login call with the same account_link_id, and explains the behavior of date filtering. However, it does not explicitly mention when to use this tool versus alternatives, so it misses the 'when-not' guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by explaining the historical name and reinforcing the read-only nature, plus the login dependency, which annotations don't cover. This is beyond 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?

Two sentences, front-loaded with the critical login requirement, and the read-only clarification. No wasted words.

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 purpose, preconditions, and the read-only behavior. It doesn't describe return format or pagination details, but with no output schema and self-explanatory params, that's acceptable for a search tool. Could be slightly more explicit about response structure, but overall adequate.

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%, with each parameter clearly described (e.g., inqr_cl_cd explains '01' behavior). The tool description adds no additional parameter meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches tax amounts due by payment deadline, and explicitly clarifies that despite the 'or_pay' in its name, it never executes payments. This distinguishes it from any payment-related tools and leaves no ambiguity about its function.

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 specifies a required precondition: prior hometax__session__login with the same account_link_id. It also explicitly states the tool is read-only and never pays, which serves as a when-not-to-use warning. It doesn't name specific alternative tools, but the context is clear enough.

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

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

Annotations already establish read-only, non-destructive behavior. The description adds the auth dependency and same-account-link requirement, which is useful, but it says nothing about pagination, result shape, or NTS-side behavior/limits; with annotations covering safety, a 3 is appropriate.

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?

Short and front-loaded with the most important prerequisite, with no filler. The parameter notes are terse but somewhat redundant with the schema; overall it is efficient, though slightly fragmentary.

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?

Together with a fully-described schema and read-only annotations, the description provides enough to call the tool safely: login prerequisite, required parameters, and formats. Missing output/pagination semantics and the sibling distinction are notable gaps, but they are not blocking for a basic search 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 schema documents all six parameters with 100% coverage, including the full enum mapping for mate_knd_cd. The description just restates the document-type and YYYYMM formats, adding no meaning beyond the schema, 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?

Identifies a concrete operation: search tax payment statement, aligned with the title '납부 내역 조회'. However, it does not contrast with the sibling search_submit_history tool, so the agent cannot distinguish this search variant from related siblings based on the description 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?

Clearly states the critical precondition: a prior hometax__session__login call with the same account_link_id. It gives no when-to-use/when-not-to-use guidance or alternatives, so selection among the many hometax search tools 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=true and destructiveHint=false, covering the safety profile. The description adds the login prerequisite, which is useful behavioral context, but does not disclose other behaviors such as pagination limits, response format, or how optional parameters interact.

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, front-loaded with the critical prerequisite. It is efficient and avoids redundancy with 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 search tool with 9 parameters and no output schema, the description is minimal. It does not explain the distinction between submission date (sbms_ym) and taxation date (txtn_ym), nor does it clarify when to use the many optional filters. The login requirement is useful but not sufficient for full operational clarity.

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 documents all parameters. The description explicitly mentions sbms_ym_strt and sbms_ym_end with YYYYMM format, but this is already in the schema. It does not add deeper meaning about optional parameters like txtn_ym_* or mate_knd_cd.

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 searches tax declaration and payment submission history, which is a specific verb+resource. However, it does not explicitly differentiate from the sibling tool hometax__tax__payment_statement__search, which may have a similar purpose.

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 a prerequisite (prior login with same account_link_id) but does not mention when to use this tool versus alternatives like hometax__tax__payment_statement__search or other search tools. There is no guidance on conditions that would favor 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=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context: the requirement of a prior login with the same account_link_id and the NTS's 5-year data limit. These are behavioral constraints beyond the annotations, making the description informative.

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 very concise—two sentences with no filler. The prerequisite is front-loaded, and the key usage constraint (date format) is stated. It is efficient but slightly sparse given the tool's complexity, though it does not waste words.

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 9 parameters, no output schema, and a complex domain, the description is inadequate. It does not mention what the response contains, pagination behavior, or how optional parameters affect results. It also fails to distinguish this tool from sibling refund-related tools, leaving the agent without enough context to use it correctly beyond the basics.

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 9 parameters are individually documented. The description only reiterates the date format for strt_dt/end_dt, which the schema already states. It adds no extra meaning for optional parameters like txaa_id, page_num, or account_link_id. Since coverage is high, the 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 clear verb+resource: 'Search tax refund details.' It is specific enough to differentiate from other search tools (e.g., search_history, search_summary) by focusing on refunds, though it does not explicitly name alternatives. The title '환급금 상세 조회' further clarifies the resource, so purpose is adequately conveyed.

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 only mentions a prerequisite (prior login with same account_link_id) and a date format (YYYYMMDD). It provides no guidance on when to choose this tool over sibling tools like hometax__tax__unclaimed_refund__search or other search_detail tools. There is no when-not-to-use or alternative 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details beyond annotations: the mandatory login prerequisite, the refusal of pre-2015 dates, and the one-year window requiring split calls. This is useful context not inferable from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the critical login requirement comes first, followed by the action, then the date constraints. Every sentence carries useful information and there is no filler or repetition of schema 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 read-only search tool with annotations covering the safety profile, the description covers everything needed to call it correctly: prerequisite session, parameter formats, date restrictions, and how to handle long ranges. Pagination defaults are already in the schema, so no additional return-format explanation is essential.

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. The description adds meaning to rtn_dt_srt/rtn_dt_end by giving the YYYYMMDD format, the earliest accepted date, and the maximum allowed window. It also reinforces the account_link_id semantics by tying it to the prerequisite login, going slightly beyond the schema text.

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: 'Search VAT return history.' This clearly distinguishes it from sibling history-search tools like overdue, notice, or payment-statement searches. The Korean title reinforces the same meaning, leaving no ambiguity about which domain the tool covers.

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 operational guidance: it requires a prior hometax__session__login with the same account_link_id, specifies the date parameters to use, and warns about the 2015-02-23 cutoff and one-year maximum window. It does not explicitly contrast the tool with alternatives, but the usage context is otherwise 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 cover the read-only, non-destructive nature of the tool. The description adds useful behavioral context beyond annotations by requiring a prior session login and tying that login to the same account_link_id. It does not detail pagination or return shape, but the safety profile is already disclosed by 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 two tight sentences with the most important precondition front-loaded. There is no filler, no restatement of the schema, and every phrase 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 list tool with three optional, self-documenting parameters, the description provides the essential context: what it searches, the required prior login, and the account_link_id binding. No output schema exists, but the operation name and description make the expected list result sufficiently clear.

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

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

Schema description coverage is 100%, so the schema already documents all parameters well. The description's mention of 'same account_link_id' reinforces the schema's guidance but does not add substantial new meaning. page_num and page_size are fully covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search') and a specific resource ('list of trade partners (buyers/sellers) from tax records'), which clearly differentiates this tool from sibling search/list tools. It is immediately clear what the tool does and what domain it operates in.

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 states a critical prerequisite: a prior hometax__session__login call with the same account_link_id. This gives the agent a clear when-to-call condition. However, it does not name alternative tools or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false)Skip. The description adds valuable behavioral context beyond those: a login prerequisite, the need for explicit parameters despite an existing session TIN, and the 5-year lookback scope. This is meaningful contextual information for the agent.

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 the critical prerequisite front-loaded first. Every word adds value—no filler or redundant statements. It is concise and well-structured.

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 read-only annotation arranged, no output schema, and the tool's straightforward purpose, the description covers all necessary call context: the login prerequisite, required parameters, and the search scope. An agent has enough information to invoke the tool correctly without needing additional detail.

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 already provides full descriptions for all 4 parameters (100% coverage), setting a baseline of 3. The description adds extra semantic value by clarifying why txpr_dscm_no and txpr_nm are required (국세청 requirement) and that the session TIN cannot substitute for them—information not present in the schema itself.

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 unclaimed tax refunds') and the resource (최근 5년간 미수령 국세환급금). It is unambiguous about the tool's function but does not explicitly differentiate it from sibling tools like hometax__tax__refund__search_detail.

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 usage context: it requires a prior hometax__session__login call with the same account_link_id, and states that both txpr_dscm_no and txpr_nm are mandatory per 국세청, with the session TIN not substituting. This gives clear guidance on when and how to use the tool, though it does not mention 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the login prerequisite and the scope ('balance and daily summary'), which are behavioral details not in the annotations. There is no contradiction. It does not mention error behavior or output format, but for a read-only tool with annotations, this is acceptable.

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, front-loaded with the critical prerequisite, and contains zero fluff. Every word adds value: the login requirement, the same-link condition, and the exact output scope. It is exemplary in structure.

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 operation with annotations covering safety and no output schema, the description is nearly complete: it tells what it does, when to use it, and the key prerequisite. The missing piece is guidance on the optional parameters, but those are largely auto-resolved or system-driven, so the gap is minor. Overall it is sufficiently complete for an agent to call it correctly 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 description coverage is only 25%, meaning most parameters lack descriptions. The tool description does not explain any parameter beyond the implicit 'account_link_id' mentioned in the prerequisite. It does not compensate for the low coverage, leaving the agent to rely on the schema alone, which is insufficient for optional parameters like bank_account_credential_ids and bank_account_selection_mode.

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 ('Read'), a concrete resource ('balance and daily summary for one registered IBK bank account'), and is clearly distinguished from sibling tools like transaction-history or login tools. It names the exact institution (IBK) and the operation scope, leaving no ambiguity about what this tool returns.

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 states a required prerequisite: a prior ibk_fast_account__session__login call with the same account_link_id. This tells the agent when it can be used and the condition (same link ID). It does not name alternatives, but the context of sibling tools makes it clear that this is the only quick-summary tool for IBK, so the usage context is adequately conveyed.

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 indicate the call is neither read-only nor destructive. The description adds the key behavioral trait that a session is created and must precede all other IBK fast-account calls, but it stops short of explaining session state, expiry, or side effects. This adds value without being rich behavioral 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?

Two short, direct sentences with no filler. The most important operational instruction ('Call this FIRST') is front-loaded, and every phrase 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 tool with one optional, fully documented parameter and no output schema, the description provides enough context: it names the session, the provider, and the required call order. The only minor gap is the undefined phrase 'parent account link,' but the schema's account_link_id description covers that concept.

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 already fully documents account_link_id, including optionality, server-side auto-resolution, the multi-certificate caveat, and per-institution ID separation. The description's 'parent account link' phrase merely echoes the schema, adding 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 uses a specific verb ('Create') and names the exact resource: an IBK fast-account session. The provider qualifier 'IBK' and the parent-account-link source distinguish it from sibling session-login tools like kb_fast_account__session__login and hometax__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?

'Call this FIRST before any other tool for this provider' is an explicit when-to-use directive: it is the required bootstrap for all IBK fast-account tools. It does not enumerate exclusions or alternatives, but provider scoping and ordering 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?

Annotations already indicate the operation is neither read-only nor destructive. The description adds auth-related context by requiring a prior login with the same account_link_id, but it does not disclose side effects such as whether repeated init calls reset state or how the initialized inquiry 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?

Two sentences with no filler. The prerequisite is front-loaded in uppercase, and the core action is stated clearly and directly.

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 login prerequisite is helpful, but the description does not explain where this init step fits in the approvals flow or what an agent should call next (e.g., approvals page/result/search). With no output schema, the lack of follow-up guidance leaves a noticeable gap for an agent executing the full sequence.

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 date formats and account_link_id behavior are already documented. The description adds a meaningful constraint: account_link_id must match the one used in the preceding login call, which goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Initialize KB Biz Card approvals inquiry for a date range.' This distinguishes it from the approvals page/result/search siblings, though 'initialize' itself is not elaborated beyond being a setup action.

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 the prerequisite of a prior kb_biz_card__session__login call with the same account_link_id. However, it does not explicitly say when to use this tool versus the sibling approvals search/page/result tools, leaving the sequential relationship to be inferred from the name 'init'.

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, and the description adds a behavioral precondition (prior login with the same account_link_id) plus scoping to a single page from an existing search context. It does not describe runtime errors or invalid-context behavior, but that is a minor gap given the annotations cover safety.

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 no wasted words. The critical login prerequisite is front-loaded in the first sentence, and the second sentence delivers the operation and its data source. Perfectly concise.

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 paginated fetch within a defined workflow, the description conveys the essential requirements (login, prior search context, single page). The lack of an output schema means the return structure is not described, but this is a minor gap for a page-fetch operation whose shape is likely defined by the search context and sibling result tool.

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

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

Schema description coverage is 100%, so the baseline is 3; the tool description adds value by tying account_link_id to the same one used in the prior login and by reinforcing that search_context must come from a prior init/search call. This is meaningful semantic context beyond the schema's generic field descriptions.

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 uses a specific verb ('Fetch') and names the exact resource ('one KB Biz Card approvals page'), and the qualifier 'from a prior search context' clearly separates it from the search/init/result siblings in the same domain. The Korean title reinforces the approvals-domain scope, making this a unambiguous page-fetch tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a hard prerequisite ('REQUIRES prior kb_biz_card__session__login call with same account_link_id') and implies the tool is a follow-up to a search. However, it never names alternative tools (e.g., kb_biz_card__approvals__search) or says when not to use this one, so the guidance is clear but not fully comparative.

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 the safe-read trait (readOnlyHint=true, destructiveHint=false). The description adds a valuable behavioral constraint not present in annotations: the requirement of a prior login with the same account_link_id. This is meaningful context, though it doesn't disclose pagination behavior or result volume.

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 no filler. The critical prerequisite is front-loaded before the action, and every word 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 action and prerequisite are stated clearly, but the description omits the surrounding flow: how this step relates to approvals__init, approvals__search, and approvals__page, and what 'result rows' implies about the output. With no output schema and a closely related sibling family, an agent is left without enough context to sequence calls reliably. The presence of the core precondition keeps it from being lower.

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 has 100% coverage with descriptions for all six parameters, so the schema carries the semantic burden. The description makes only a passing reference to account_link_id in the context of the login prerequisite, which adds a slight usage link but no new parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Collect KB Biz Card approvals result rows.' This is clear and distinct from generic tooling. It doesn't explicitly contrast with sibling tools like approvals__search or approvals__page, but the combination of name and action conveys the result-collection role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage guidance is the prerequisite that kb_biz_card__session__login must have been called with the same account_link_id. There is no explanation of when to use this tool versus the approvals__init, approvals__search, or approvals__page siblings, nor any alternative or exclusion conditions. An agent must infer the intended call sequence.

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, covering the safety profile. The description adds the login prerequisite with matching account_link_id, which is valuable operational context. But it doesn't disclose pagination behavior, rate limits, or whether the search returns all pages by default vs. requiring explicit page/max_pages handling — leaving a gap for a search 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?

Two sentences with zero waste. The critical prerequisite is front-loaded before the purpose statement, and the purpose itself is a single concise clause. Every word 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 search tool with 7 parameters and no output schema, the description is minimally adequate. It doesn't explain the relationship to the kb_biz_card__approvals__init/page/result siblings (whether this search is a prerequisite to those or an alternative), nor does it clarify pagination semantics or the return format. The date range is implied by the required date_from/date_to but the filtering semantics are left to the 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 all 7 parameters are documented in the schema. The description's mention of account_link_id in the prerequisite context reinforces the schema's note about auto-resolution but adds no new parameter semantics 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 states a specific verb and resource: 'Search KB Biz Card approvals rows.' This distinguishes it from the payments and purchases siblings, and from the init/page/result approvals siblings which represent a different workflow stage. However, it doesn't explicitly name any sibling to differentiate itself, so the agent must infer the distinction from the resource noun.

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 the critical prerequisite: 'REQUIRES prior kb_biz_card__session__login call with same account_link_id.' This is genuinely useful guidance for an agent. However, it doesn't explain when to choose this tool over kb_biz_card__approvals__init/page/result or over payments__search/purchases__search, leaving the when-not-to-use cases unaddressed.

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 the login dependency, which is valuable behavioral context. It does not describe the response format or side effects, but with the annotation covering read-only behavior, this is sufficient.

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, front-loaded with the critical login requirement, and contains zero filler. Every word 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 prerequisite and the core action. Given no output schema, it might benefit from clarifying what is returned (e.g., a list of card identifiers), but for a simple select tool with full schema coverage, the missing details are minor and inferable.

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 each parameter already has a thorough description. The tool description adds no additional meaning to the parameters (e.g., how they influence the selection). Baseline of 3 is appropriate because 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?

The description states a specific verb ('Select') and a clear resource ('KB Biz Card cards available to the current session'), and implicitly distinguishes it from sibling tools like kb_biz_card__common__departments__select by naming a different resource. The 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 clearly states a prerequisite ('REQUIRES prior kb_biz_card__session__login call with same account_link_id') but gives no explicit guidance on when to use this tool versus alternatives or when not to use it. The context is clear, but there are no exclusions or comparison with sibling select tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the tool depends on an established session and only exposes departments available to that session. This clarifies why login is required without contradicting 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 description is a single focused sentence that front-loads the critical login requirement before stating the tool's purpose. Every word earns its place; there is no redundant or filler 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 simple read-only filtered selection tool, the precondition and parameters are adequately documented. However, there is no output schema and the description does not describe the return shape or how the selected departments should be used downstream, leaving some ambiguity for the agent.

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

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

Schema description coverage is 100%, and both parameters are already well described in the input schema. The description reinforces that account_link_id must match the prior login, but it does not add new semantic meaning for either parameter beyond what the schema provides.

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: 'Select KB Biz Card departments available to the current session.' The login prerequisite adds useful scope, and the resource name distinguishes it from sibling tools like cards__select. However, it does not explicitly differentiate from alternatives or state the return format.

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 the required precondition: a prior kb_biz_card__session__login call with the same account_link_id. This gives the agent clear context for when the tool can be invoked. It does not mention when not to use it or alternative tools, but the context is sufficient for a simple session-scoped read.

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