XBOSS

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

Annotations only cover the safety profile (readOnlyHint/destructiveHint), and the description adds a great deal beyond them: per-call token cost (4), the failure semantics of a null computed with computed_error, the meaning of partial and the two envelope shapes, 15-minute download links with 7-day file retention, and the anonymous recovery_receipt contract (scope, non-repairability, non-transferability). This is materially more than the annotations convey and does not contradict them.

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

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

It is correctly front-loaded with the pipeline, but the receipt/link passage is a dense run-on that repeats itself ('partial is true whenever the result is incomplete' restates the preceding sentence) and mixes languages ('호출마다 토큰 4소진'). The content is largely justified, but the packaging makes it harder to parse than it needs to be.

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

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

With no output schema, the description carries the return-value burden and does describe the envelope (computed, computed_error, partial, artifacts[] with download_url, pack_run_id). It still does not say what fields the brief actually contains, so an agent knows the shape but not the payload.

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 explains every one of the 8 parameters (bizno, p_nm, start_dt, sDate/eDate, output_formats, idempotency_key). The description adds only indirect context (which upstream legs the parameters feed, and that output_formats PDF lives in artifacts[]); 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?

States a specific verb+resource ('Composite company-info brief v1') and enumerates exactly what it composes: the REDUCE-5 opendata legs (nts.status, nts.validate, g2b.sanction, kiscon.sanction, env.waste_sanction) plus a computed brief. That lets an agent distinguish it from the individual sibling opendata leg tools and from xdata__job__result without opening any schema.

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

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

Explicitly removes the usual prerequisites ('No account_link_id and no certificate are needed: every step runs on our platform key') and routes the agent to xdata__job__result when a download link expires, naming the pack_run_id to pass. It stops short of stating when an agent should call the individual opendata legs instead of the pack, and gives no exclusion conditions.

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

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

Annotations only say readOnly=false and destructive=false, so the description carries real weight and delivers: a documented failure mode (multiple management numbers ⇒ login fails, no parameter can disambiguate) and an explicit per-call cost ("호출마다 토큰 1소진"). The idempotency paragraph adds recovery semantics but is partly verbose and the phrase "anonymous taste calls" is opaque jargon that doesn't land clearly.

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 most important instruction (call first, certificate login, uniqueness precondition) is front-loaded and the token cost is a single short clause. The idempotency section runs long with restatement ("Without it, calling again remains a new request") and ends on an unlabeled Korean fragment.

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 4-parameter login with annotations and no output schema, the description covers ordering, preconditions, cost, and retry semantics. It stops short of saying what a successful login yields (session lifetime/expiry) or that session state is inspected via the sibling status tool, which an agent must infer.

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 nonetheless adds meaning beyond the schema by tying business_registration_no to a uniqueness constraint against COMWEL management numbers. It also distinguishes request_idempotency_key from a provider-specific idempotency_key, a distinction the schema does not make.

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

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

Names a specific verb (Login) and resource (COMWEL via NPKI AnySign certificate) and states the ordering constraint up front. An agent can tell it apart from comwel__auth__session__status, the only other comwel auth sibling, without opening either schema.

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

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

"Call this FIRST before any other tool for this provider" gives explicit sequencing, and the clause about business_registration_no mapping to exactly one management number states a hard precondition under which the call fails. It does not route the agent to comwel__auth__session__status for the already-logged-in case, so the when-not side is only partial.

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 one genuinely useful behavioral fact – '호출마다 토큰 1소진' (one token consumed per call) – which is cost/rate information not in the annotations, but it otherwise repeats idempotency boilerplate rather than describing what status is returned.

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 purpose is front-loaded in one clean sentence, which is good. However, the bulk of the text is idempotency-key boilerplate that reads as template text and is disproportionate for a read-only two-parameter status check, diluting the signal an agent needs.

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 full schema coverage, zero required params, and no output schema, the definition covers inputs adequately. But because no output schema exists, the description should hint at what the status result contains (authenticated or not, session expiry, account identity) – it says nothing about return values, leaving a gap for a status-query tool.

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

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

Schema coverage is 100%, so a baseline of 3 would be acceptable, but the description genuinely elaborates the semantics of request_idempotency_key (generate before first request, reuse only for lost-response recovery, new key for new execution) beyond the schema's one-line pointer. It also warns that provider-specific idempotency_key is a separate field, adding useful disambiguation.

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 'Check COMWEL session status' states a specific verb and resource clearly, so an agent knows exactly what the tool does. It does not explicitly differentiate from the sibling login tool (comwel__auth__npki_session__login), which keeps it from 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 spends nearly all of its text on idempotency key mechanics, which is parameter guidance rather than when-to-use guidance. It never says when to call this status check versus the login tool, nor any prerequisite (e.g., 'call before authenticated requests to verify login').

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?

Adds real context beyond the readOnly annotation: xlsx artifacts with a download_url valid 15 minutes, 7-day file retention, a recovery path via xdata__job__result with private recovery_receipt, and a per-call token cost of 1. The idempotency and receipt guidance is partly generic family boilerplate (and the 'anonymous taste calls' wording is confusing for an auth-required tool), but the artifact and retention behavior is genuinely useful.

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 text is long and dominated by protocol boilerplate about receipts, signing up, and key reuse that is at best tangential to a single-worker premium lookup. The actual purpose arrives after a capitalized prerequisite line, and the receipt/lane guidance muddies focus.

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 10 params fully documented, no output schema, and readOnly annotations, the description covers the essentials: auth prerequisite, file generation via artifacts[], and how to recover expired links. A short note on what the premium detail payload contains would have closed the remaining gap.

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

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

Schema description coverage is 100%, so all 10 parameters including worker_resident_no, labor_provider_yn and request_idempotency_key are self-documented. The description only echoes output_formats/artifacts and the idempotency key usage, adding little that the schema does not already supply; baseline 3 applies.

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

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

States a specific verb and resource: 'Fetch COMWEL individual billed-premium detail for a selected worker.' The 'selected worker' phrasing implicitly separates it from the sibling worker_select step, but the prerequisite sentence leads and the core purpose is buried mid-text rather than front-loaded.

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

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

Gives a clear prerequisite ('REQUIRES prior comwel__auth__npki_session__login call with same account_link_id') and implies the worker_* params come from worker_select. However, it never names alternatives or a when-not condition, and no sibling tool such as premium_billing_notice__detail is contrasted despite overlapping domain.

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, yet the description still adds genuinely useful behavior: the auth/session dependency, per-call token consumption ('호출마다 토큰 1소진'), and full idempotency semantics including that an omitted key makes every retry a new request. It stops short of saying what the selection produces or whether it persists state.

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?

Roughly two-thirds of the text is generic, reusable idempotency boilerplate that applies to every tool in this family, including an aside about 'anonymous taste calls' and a note about provider-specific idempotency_key fields that no parameter here exposes. The one sentence of actual tool-specific purpose is crowded between boilerplate blocks.

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 readOnly tool with full schema coverage and no output schema, the auth and cost context is adequate. What is missing is the outcome of the call — whether it returns a candidate list to choose from or commits a selection used by the detail tool — which matters for a tool literally named select.

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 insurance_year, worker_name, birth_ymd, account_link_id and business_management_no; the description adds no format detail beyond that. The only parameter the description elaborates on is request_idempotency_key, and even there the schema already carries the pattern, bounds and a pointer back to 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 sentence 'Search and select a worker for COMWEL individual billed-premium inquiry' gives a specific verb plus resource and scopes it to a lookup step, which distinguishes it from the sibling comwel__info__individual_billed_premium__detail. The purpose is however buried after a prerequisite sentence and before a long generic idempotency block, so it is clear once found but not front-and-center.

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

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

It states a hard prerequisite ('REQUIRES prior comwel__auth__npki_session__login call with same account_link_id') and explains when to reuse vs. regenerate the idempotency key. What it never says is when to pick this tool over the sibling detail tool, or whether worker_select is a mandatory precondition for the detail call — the agent must infer the ordering.

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

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

Goes well beyond annotations: discloses file generation behavior (xlsx only when requested, 15-minute download_url, 7-day retention), anonymous result recovery_receipt semantics, idempotency key usage, and per-call token cost. Annotations already mark it read-only, but the description adds rich operational context without contradicting them.

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

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

Front-loads the key requirement, but the description is long and somewhat unstructured, mixing file behavior, recovery instructions, and idempotency in a single block. Some sentences could be consolidated without losing meaning.

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

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

Covers auth prerequisites, artifact generation, expired-link recovery, anonymous receipt handling, and idempotency semantics thoroughly. However, with no output schema, it does not describe the actual billing notice data returned, leaving a gap for the agent to understand the response payload.

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 meaningful usage details for request_idempotency_key (generation, reuse, anonymous unavailability) and output_formats (artifact behavior) that go 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?

States a specific verb and resource: 'Fetch COMWEL premium billing notice detail.' The schema references a prior search result, but the description does not explicitly name the sibling search tool or distinguish this detail tool from other detail tools like comwel__info__individual_billed_premium__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?

Explicitly states the prerequisite login call and gives recovery guidance via xdata__job__result for expired links and anonymous results. However, it never says when to use this tool versus the search tool or other detail alternatives, leaving some inference required.

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, so the baseline is lower, but the description adds substantial operational context: token cost, file retention (7 days) and download URL expiry (15 minutes), idempotency key behavior, and anonymous recovery receipt rules. This is rich beyond the annotations, though some boilerplate is tangential to the core search behavior.

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 core purpose is stated early, but the description runs long and includes extensive boilerplate about recovery receipts, idempotency keys, and file retention. Several sentences are operational policy rather than tool-specific selection guidance, making it less front-loaded and harder to scan.

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 no output schema, the description covers preconditions, file output handling, and recovery paths well. It stops short of describing what the main data payload contains (notice fields, pagination), so it is not fully complete for a search tool.

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

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

Schema coverage is 100%, so the schema already documents most parameters. The description still adds meaningful semantics for `request_idempotency_key` (generate before first request, reuse only for recovery, new key for new execution) that goes beyond the schema's brief pointer, justifying a score above the baseline 3.

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

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

The description states a specific verb and resource: 'Search COMWEL premium billing notices.' It is clear what the tool does. However, it does not differentiate from the sibling `comwel__info__premium_billing_notice__detail`, so an agent must infer that this is the list-level search rather than the detail lookup.

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 prerequisite ('REQUIRES prior comwel__auth__npki_session__login') and explains post-call handling (expired links, recovery receipts, idempotency). But it never explicitly states when to use this search versus the detail sibling or other notice-related tools, leaving alternative selection implied.

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

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

Annotations only cover safety (readOnly/destructive), but the description goes well beyond: file retention of 7 days, 15-minute download links, the xdata__job__result refresh path, anonymous recovery_receipt semantics, idempotency-key recovery behavior, and the per-call token cost. This is exactly the value-add context annotations cannot express.

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?

Core purpose, prerequisite, and read-only status are front-loaded well. However, substantial boilerplate about anonymous receipts and idempotency is verbose and partly tangential to this login-gated query, diluting the sections that matter most.

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 does the work of explaining artifacts[], download_url lifetime, and the job-result refresh path. It does not describe the actual fine-list data fields, but for the file/return mechanism it is largely 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 coverage is 100%, so the schema already documents every parameter precisely, including the three-month range limit and all_period exclusivity. The description largely restates these constraints rather than adding new parameter-level meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('Lists administrative fines already paid'), which implicitly distinguishes it from the unpaid sibling. It does not explicitly name efine__unpaid_penalty__query or efine__paid_violation__query, so an agent must still reason about which penalty/violation sibling applies.

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

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

Strong guidance: requires prior efine__session__login with matching account_link_id, explains the all_period vs date-range fork, and explicitly excludes paying, printing, and per-row detail. It stops short of naming the alternative tools to route to for those excluded actions.

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 reinforces this ('Read-only') while adding real operational context: the result carries a row count and a has-next-page flag, xlsx files land in artifacts[] with a 15-minute download_url and 7-day retention, and each call consumes one token. Much of the receipt/taste-call prose reads like boilerplate that is not specific to this query, which keeps it from a 5.

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

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

The actual purpose does not appear until the third sentence, behind prerequisite and safety chatter, and the bulk of the text is generic cross-cutting policy (recovery receipts, anonymous taste calls, retention) that belongs in shared documentation rather than this one tool. Nothing is front-loaded for an agent scanning for 'what does this do'.

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 paginated list with a fully described 5-parameter schema and no output schema, everything an agent needs is present: prerequisites, pagination signal, artifact generation behavior, expiry handling, and idempotency recovery. No material gap remains for calling 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 coverage is 100%, so the baseline is 3; the description still earns credit by explaining that output_formats produces the artifact only 'when requested' and by detailing idempotency-key lifecycle semantics (generate before first request, reuse only to recover a lost response, one key per execution, unavailable to anonymous 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 ('Lists criminal fines already paid') and immediately scopes what is out of bounds ('Paying, printing and per-row detail are not offered'), which separates it from efine__unpaid_violation__query and efine__paid_penalty__query. It does not name those siblings explicitly, so the differentiation is inferential rather than stated.

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 a hard prerequisite ('REQUIRES prior efine__session__login call with same account_link_id') and names xdata__job__result as the fallback when a download link expires. What it lacks is an explicit pointer to the unpaid/detail siblings an agent should use instead when that is the real intent.

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

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

Annotations already declare readOnlyHint=true/destructiveHint=false, and the description stays consistent while adding real context: artifact download_url valid 15 minutes, files retained 7 days, idempotency key reuse semantics, and '호출마다 토큰 1소진' cost per call. Much of the receipt/anonymous-result prose is generic boilerplate irrelevant to an authenticated read-only listing, which keeps it below 5.

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

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

Roughly 250 words for a simple paginated read, with long stretches of copy-pasted boilerplate about anonymous recovery receipts and 'taste calls' that cannot apply to a login-gated listing. The purpose is front-loaded, but several paragraphs do not earn their place in this tool's definition.

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

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

Covers prerequisite, result shape (row count, has-next-page), file output and retention, and idempotency, which is reasonable given no output schema. It omits the sibling differentiation and the meaning of vehicle_number filtering, and the generic receipt prose adds noise rather than 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%, so the baseline is 3; the description goes beyond it for two parameters by explaining that output_formats xlsx files land in artifacts[] with a 15-minute download_url and by spelling out when to generate, reuse, or rotate request_idempotency_key. page_size/page_index behavior is left entirely to the schema.

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

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

States a concrete verb and resource: 'Lists recent enforcement records the institution holds, with the row count and whether another page follows.' It also rules out paying and filing objections, so the scope is bounded. However, it never distinguishes itself from the four closely named siblings (paid_penalty, paid_violation, unpaid_penalty, unpaid_violation), leaving the agent to infer that this is the generic 'recent' list.

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

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

Gives a hard prerequisite — 'REQUIRES prior efine__session__login call with same account_link_id' — and excludes payment/objection actions. But it never says when to choose this over the paid/unpaid penalty and violation queries, which is the main routing decision an agent faces here.

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 readOnlyHint=false and destructiveHint=false, so the description carries real weight here: it discloses that a server-side session is created and persisted for later query tools, that re-authentication is required after expiry, and that each call costs a token ('호출마다 토큰 1소진'). The idempotency paragraph adds recovery semantics, though parts ('anonymous taste calls', 'provider-specific idempotency_key') are boilerplate that do not map to anything on this 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?

The first two sentences are front-loaded and waste-free, but the trailing idempotency block is long relative to this tool and includes irrelevant or ambiguous clauses ('not available to anonymous taste calls', 'Keep any provider-specific idempotency_key unchanged' — no such field exists here). That padding dilutes an otherwise tight login definition.

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 covers what an agent needs to call it: ordering, credential fields (documented in schema), session reuse, expiry handling, and cost. It stops short of describing failure behavior (bad certificate, wrong business registration number) or how a caller learns the login succeeded, which would complete the picture.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by fully explaining request_idempotency_key, which the schema explicitly defers to the tool description ('see the tool description'). It clarifies when to reuse versus regenerate the key, which is meaning the schema cannot convey on its own.

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

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

The description gives a specific verb and resource ('Signs in with the corporate certificate') and names the scope ('stores the session the efine query tools reuse'), which separates it from the efine query siblings that depend on it as well as from the other providers' session logins. An agent can tell exactly what state this tool creates without opening the schema.

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

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

It states explicit ordering ('Call this FIRST before any other tool for this provider') and an explicit re-entry condition ('call it again if a tool reports the session expired'). Both the when and the when-again are spelled out with no inference required.

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?

Consistent with readOnlyHint=true/destructiveHint=false and goes well beyond them: token cost per call, file retention (15-minute download links, 7-day storage), recovery via xdata__job__result with job_id, and detailed anonymous recovery_receipt semantics. This is rich behavioral context an agent cannot get from annotations alone.

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

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

Front-loads the critical prerequisite and read-only nature, which is good. But it then sprawls into generic platform boilerplate (recovery receipts, idempotency key mechanics, anonymous access rules) that dilutes the tool-specific content, and the trailing Korean token-cost line is orphaned without 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?

With no output schema, the description helpfully explains the artifacts[] return shape, download_url lifetime, and file retention, plus recovery paths for expired and anonymous results. That covers the output/return story well, leaving only minor gaps such as result payload fields.

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 every parameter is already documented in the schema. The description reinforces the all_period/date_basis interaction but adds little semantic detail beyond what the schema fields already provide, 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?

States a specific verb and resource: 'Lists unpaid administrative fines,' and adds scope details ('Paying is not offered'). It does not explicitly differentiate from the very similar siblings efine__paid_penalty__query, efine__unpaid_violation__query, or efine__paid_violation__query, which is the main clarity gap.

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?

Strong on prerequisites and modes: requires a prior efine__session__login with the same account_link_id, explains the all_period-vs-range choice and how date_basis interprets the range, and states paying is not offered. However, it never names an alternative sibling tool or says when unpaid violation/paid penalty queries should be chosen instead.

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

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

Annotations already declare readOnlyHint=true/destructiveHint=false and the description is consistent ('Read-only'), yet it adds a lot beyond them: download_url lifetime of 15 minutes, 7-day file retention, artifact placement in artifacts[], idempotency-key recovery semantics, and a per-call token cost. The anonymous recovery_receipt passage is extensive and somewhat at odds with the stated login requirement, which muddies the behavioral picture slightly.

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

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

Front-loads the login prerequisite and read-only nature well, but the body is a dense run-on that mixes file retention, anonymous recovery receipts, idempotency-key policy, and token cost in one block. Several sentences are framework boilerplate that a caller of a logged-in query tool must filter out, and the anonymous-receipt discussion sits awkwardly beside the login requirement.

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

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

No output schema exists, and the description compensates by describing the return shape (row count, page-follow flag, artifacts with download_url), retention windows, and the recovery path for expired links. Prerequisites and cost are also covered, so an agent has what it needs to call this correctly, even if the anonymous path is confusing.

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 genuinely adds meaning beyond the schema: it explains that output_formats produces a file in artifacts[] (not just data), and it gives operational semantics for request_idempotency_key (generate before first request, reuse only to recover a lost response, never reuse for a new execution). page_size behavior is only restated, not extended.

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

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

States a specific verb and resource — 'Lists unpaid criminal fines' — plus the return shape (row count, whether another page follows) and an explicit scope exclusion ('Paying, per-row detail and picking another corporation are not offered'). It does not however name the near-identical siblings efine__unpaid_penalty__query or efine__paid_violation__query, so an agent must infer the fine-vs-penalty distinction from the name 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?

Gives a hard prerequisite up front ('REQUIRES prior efine__session__login call with same account_link_id') and states what the tool will not do, which is real when-not guidance. It also routes to xdata__job__result for expired artifact links. Missing an explicit 'use X instead' for the sibling paid/penalty query 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real context on top: per-call token consumption ("호출마다 토큰 1소진"), the fact that repeated calls without an idempotency key are treated as new requests, and a warning not to confuse this key with a provider-specific `idempotency_key`. It does not clarify whether initialization creates any server-side state, which is the main ambiguity for an `init` tool marked read-only.

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 prerequisite is helpfully front-loaded, but the idempotency passage is verbose and partly redundant ("Reuse it ... only to recover that request after a lost response" largely restates "Without it, calling again remains a new request"). A Korean sentence about token consumption sits untranslated at the tail, slightly undercutting scanability.

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 zero-required-parameter init tool with full schema coverage and no output schema, the essentials are present. What is missing is what initialization yields and what the agent should do next, which matters because this is one step in a declaration lifecycle and there is no output schema to reveal the returned handle.

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 would be 3, but the description genuinely carries meaning the schema defers on: `request_idempotency_key`'s schema text is literally "see the tool description," and the description explains its recovery-only semantics and reuse rules. The anonymous-call exclusion for that key is also only stated 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?

States a specific verb and resource: "Initialize business establishment declaration," which is unambiguous about what the call does. It does not, however, position itself against the many other `__init` siblings in the namespace (e.g. `workplace__withdrawal__init`, `payroll__amount_change__init`) or explain that it is the first step of a multi-step declaration flow.

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

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

Gives one hard prerequisite ("REQUIRES prior fourinsure__session__login call with same account_link_id"), which is genuinely useful gating. But it never says when to choose this tool versus an alternative, nor what the expected follow-up call is after initialization, so the agent must infer the flow from the `init` suffix.

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 readOnlyHint=false and destructiveHint=false; the description adds substantial context beyond that — the login prerequisite, idempotency lifecycle, the note that the provider-specific idempotency_key is a different field, and the cost signal ('호출마다 토큰 1소진'). The 'anonymous taste calls' phrase is a garbled artifact that slightly muddies an otherwise rich disclosure.

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 prerequisite is front-loaded, which is good, but the idempotency-key rules sprawl across four sentences with repetition ('Without it, calling again remains a new request') and a confusing 'anonymous taste calls' clause. It could be tightened without losing meaning.

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

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

Covers auth requirement, idempotency, and per-call cost, which are the key risks. For an init tool it never explains what the initialization produces (a session/handle) or how it hands off to fourinsure__b1__certificate__apply__submit, which is a meaningful gap given no output schema exists to clarify the return.

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

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

Schema coverage is 100%, so both parameters are already well documented. The schema explicitly defers the request_idempotency_key meaning to the description, and the description does explain its lifecycle, but it adds behavioral life-cycle context rather than format/semantic detail beyond the schema — so the baseline 3 holds.

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

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

States a specific verb and resource ('Initialize 4대보험 certificate application'), which is clear and distinguishes it from the submit sibling by its initialization phase. However, it never explicitly names the submit/follow-up tool or states that a template is being prepared for a later step.

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 prerequisite ('REQUIRES prior fourinsure__session__login call with same account_link_id') and gives precise conditions for the idempotency key (generate before first request, reuse only to recover a lost response, new key for new execution). It lacks guidance on when to prefer this tool over the __submit sibling, keeping it below 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?

Adds substantial context beyond the annotations: the filing is irreversible with no cancel action, a receipt number is assigned, and each call consumes a token. That matches and enriches destructiveHint=true rather than merely restating it.

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

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

Front-loaded with the hard prerequisite, then intent, then irreversibility, then the confirm protocol. Dense and largely waste-free, though the confirm instruction partly overlaps what the schema already says for the confirm property.

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

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

Covers the session dependency, the irreversible outcome, the return artifact (receipt number), and the consent flow — the critical knowledge for a 9-parameter destructive tool with no output schema. The only omission is disambiguating the redundant dry_run and confirm_submit flags.

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

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

Schema coverage is 100%, so baseline is 3; the description nonetheless adds the semantics of the confirm gate (first call previews, second files) which is the crux of the tool. It does not address dry_run/confirm_submit interplay or the optional phone/sort fields, leaving a small gap.

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

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

States a specific verb and resource ('Submit a 4대보험 certificate application'), which is clearly distinct from the sibling fourinsure__b1__certificate__apply__init that prepares the selection. It does not spell out the certificate variants, but the selection key handling implies them.

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

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

Explicit prerequisites (prior fourinsure__session__login with same account_link_id), an exact two-step workflow (preview call → show user → retry with confirm=true), and a hard prohibition against self-approving. Nothing about when to use it is left to inference.

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

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

Annotations only declare readOnlyHint/destructiveHint, and the description goes beyond them with the auth prerequisite, idempotency semantics, the warning that omitting the key makes every call a new request, and a per-call cost note ('호출마다 토큰 1소진'). It does not describe what the detail payload contains, which matters since 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 auth requirement and purpose are correctly front-loaded, but roughly half the text is generic idempotency boilerplate for one optional parameter on a read-only lookup, which outweighs the two sentences that describe this specific tool. The trailing token-cost note is useful but appended as an afterthought.

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 no output schema and four well-documented parameters, the description covers prerequisites and key handling adequately. However, it omits what the detail result contains and how it differs from history__list or history__detail_init, leaving the agent to guess the workflow position of this call.

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 cvrc_no, group_cvrc_no, and account_link_id are already fully documented in the schema (including the source of cvrc_no from certificate.history.list). The description adds real semantics for request_idempotency_key that the schema explicitly defers to it, but that is a single optional parameter, so it lands at the baseline-plus level rather than above it.

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

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

States a specific verb and resource ('Get certificate application history detail'), which maps cleanly onto the tool's domain. It does not distinguish itself from the closely named siblings history__list, history__detail_init, or history__pdf_download, so an agent still has to infer the boundary from the names.

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

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

Gives an explicit precondition ('REQUIRES prior fourinsure__session__login call with same account_link_id') and clear when-to-reuse guidance for the idempotency key ('reuse it with the same arguments only to recover that request after a lost response; use a new key for a new execution'). It never says when not to use this tool versus history__list or whether history__detail_init must run first.

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 declare readOnlyHint=false and destructiveHint=false, and the description is consistent with a non-destructive mutation ("Initialize"). It adds context beyond annotations: the token cost per call, the session/auth prerequisite, and explicit idempotency-recovery semantics. It stops short of saying what server-side state the init creates or whether re-initializing overwrites a prior init.

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 must-know prerequisite is correctly front-loaded, but five of roughly seven sentences concern a single optional parameter, while the core meaning of "initialize" gets no sentence at all. The trailing Korean token-cost note is buried at the end and switches language mid-definition.

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

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

With no output schema and no annotations explaining what is persisted, the description should say what the init produces and how it relates to the follow-up `history__detail` call. The auth and idempotency story is thorough, but the actual init-followed-by-detail flow is left for the agent to infer.

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 four parameters and cvrc_no's provenance (`certificate.history.list`). The description's added value is confined to `request_idempotency_key` — clarifying it is per-execution, reusable only for lost-response recovery, and distinct from any provider-specific idempotency_key. That is useful but covers only one of four params.

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 verb+resource ("Initialize certificate application history detail"), but "initialize" is a vague action word that does not tell an agent what state is created or returned. Critically, the near-identical sibling `fourinsure__b1__certificate__history__detail` is never mentioned, so an agent cannot tell the two apart from 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?

Gives one hard precondition (prior `fourinsure__session__login` with the same account_link_id) and detailed rules on when to reuse vs. regenerate the idempotency key, which is real usage guidance. However, it offers no guidance on choosing this tool over `history__detail` or `history__list_init`, and no statement of when this init step is required.

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

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

Annotations already declare readOnly/non-destructive, yet the description adds genuinely new behavior: per-call token cost ('호출마다 토큰 1소진'), idempotency-key lifecycle semantics, and the caveat that a provider-specific idempotency_key is a different field. What is missing is any statement about the result shape or listing limits, but the added context is substantial.

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 precondition is correctly front-loaded and the token-cost note is a good closing signal. But the middle is a dense idempotency paragraph with partially redundant sentences ('Without it, calling again remains a new request') that could be compressed to half its length.

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

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

There is no output schema, so the description could carry return-value expectations (what a history entry contains, ordering, whether all entries or a page is returned), and it does not. The idempotency and precondition coverage is good, but the result side of a list tool is left entirely unspecified.

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 both parameters. The description still adds real meaning for request_idempotency_key — when to reuse it, when to generate a new one, and that anonymous calls cannot use it — going beyond the terse schema line that defers to 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?

States a specific verb and resource ('List certificate application history'), which is clear in itself and separable from the detail/pdf siblings. However it never distinguishes itself from the adjacent list_init, detail_init, or history__detail tools, so an agent must still infer which one to call.

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

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

Gives one real precondition ('REQUIRES prior fourinsure__session__login call with same account_link_id'), which is useful. But no when-to-use vs. the _init/history__detail variants, no guidance on paging or repeated listing, and no when-not-to-use case.

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 readOnly/non-destructive annotations it adds real behavioral context: a login prerequisite tied to a specific account_link_id, an explicit token cost ('호출마다 토큰 1소진'), and the retry semantics ('Without it, calling again remains a new request'). Those details matter for a call-budgeted init step and are not derivable from 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 login prerequisite is correctly front-loaded, but the idempotency paragraph runs long relative to one sentence of actual purpose, and the line about the key being 'not available to anonymous taste calls' is confusing phrasing that costs a sentence without adding usable information.

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

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

With no output schema, the description should say what initialization yields (a handle, a session state, an empty list shell) and how it hands off to __list — neither is covered. It is complete on the idempotency and auth dimensions but leaves the tool's actual effect and output shape to inference.

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 already 100%, so the baseline would be 3, but the description goes further on request_idempotency_key — when to generate it, when to reuse it, when to mint a new one, and that provider-specific idempotency_key is a different field that must not be touched. That is meaning the schema explicitly defers to the description for.

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 sentence 'Initialize certificate application history list' names a verb and a resource and is distinguishable from the __list sibling by the init suffix, but 'initialize' is never explained — what state it creates and whether __list must follow are left implicit. An agent can guess it is a setup call, but not confirm it from the text.

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 one concrete prerequisite ('REQUIRES prior fourinsure__session__login call with same account_link_id'), which is genuinely useful. However it never says when to use this instead of fourinsure__b1__certificate__history__list or that init must precede it, so the sequencing guidance an agent actually needs is implied rather than stated.

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?

Adds useful context beyond annotations: 15-minute download links, 7-day retention, token cost, and receipt semantics. However, annotations declare destructiveHint=true and readOnlyHint=false, and the description never explains any destructive behavior; a download reads as non-destructive, and the crucial detail that dry_run defaults to true (so no PDF is returned unless override) is absent.

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 prerequisite and purpose are front-loaded, but the body sprawls into lengthy anonymous-recovery_receipt exposition (publishing, loss, signing in) that is largely tangential to invoking this specific download tool. Several sentences could be trimmed without loss to the agent's decision.

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 usefully explains the returned artifacts[], download_url lifetime and retention. But for a destructiveHint tool with a default-preview dry_run schema, the omission of the preview-vs-download mechanics is a meaningful completeness gap for correct invocation.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description adds no parameter-level meaning (e.g., dry_run/confirm_download pairing or download_all_available) beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Download certificate PDF'), clearly distinct from the sibling history__detail and history__list tools. It does not, however, clarify that the default behavior is a preview rather than an actual download, which slightly blurs the 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?

Explicitly states the prerequisite ('REQUIRES prior fourinsure__session__login call with same account_link_id') and names the alternative path ('If a link has expired, call xdata__job__result...'). It omits when to use the dry_run default vs the real download, leaving a usage gap.

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 readOnlyHint=true and destructiveHint=false, and the description adds genuine behavioral facts beyond that: download_url valid 15 minutes, files retained 7 days, per-call token consumption (호출마다 토큰 1소진), and that expired links are recovered via xdata__job__result. Much of the anonymous-receipt/idempotency text is boilerplate not specific to this read-only endpoint, which keeps it from a 5.

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

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

The definition is heavily bloated: roughly a dozen sentences, most about anonymous recovery receipts, receipt publishing warnings, and idempotency key discipline that are boilerplate and only marginally applicable to a read-only list call. The actual purpose is buried in the second sentence behind a login prerequisite, so it is not front-loaded.

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

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

It covers the login prerequisite, file/artifact behavior, and cost per call, which is enough for a 10-parameter read-only list with no output schema. It omits the list_init dependency for valid filter codes and says nothing specific about pagination beyond what the schema already documents.

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 only adds meaning for output_formats (a file appears in artifacts[] with a download_url), while the other nine parameters are left entirely to the already-complete 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 core purpose is stated with a clear verb and resource ('List civil receipt history'), but it arrives only after a precondition sentence, and it never distinguishes this tool from the sibling list_init tool even though the schema repeatedly points to list_init as the source of filter option values.

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

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

It states the login precondition with account_link_id and explains when to request files via output_formats ('omit it for data only'). However, it gives no guidance on when to call civil_receipt__history__list_init first versus this list tool, which is the most likely agent confusion given the sibling exists.

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 value beyond them: a mandatory auth dependency, the requirement to generate/save an idempotency key before the first request, recovery semantics (reuse only for lost-response recovery, new key for new execution), and the cost signal "호출마다 토큰 1소진." These are genuine behavioral facts the annotations do not carry.

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

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

The auth prerequisite is correctly front-loaded, but the idempotency paragraph is disproportionately long for a two-optional-parameter init call, and phrases like "anonymous taste calls" and "provider-specific idempotency_key ... is a different field" add noise relative to how much an agent needs. Structure is serviceable but bloated.

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 two optional parameters, full schema coverage, and readOnly annotations, the description covers auth and cost but omits the two things most needed for an init tool: what state it establishes and what the agent should call next. No output schema exists, so the description is the only place that could have explained the init result, and it does not.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema defers to it for: the schema's request_idempotency_key description literally says "see the tool description," and the description explains the key's lifecycle and that it is unavailable to anonymous calls. account_link_id is left entirely to the schema, which keeps it from a 5.

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 civil receipt history list"), but never explains what "initialize" actually does — whether it opens a session, loads filter options, or resets state — and it never mentions the sibling fourinsure__b1__civil_receipt__history__list that presumably performs the actual fetch. An agent can tell it is a setup call for civil receipt history but not what it produces.

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?

"REQUIRES prior fourinsure__session__login call with same account_link_id" is a clear prerequisite, and the idempotency-key paragraph gives real when-to-use guidance for that parameter. However, there is no guidance on when to call this init versus the sibling list tool, or what to do after calling it, so the sequencing guidance is implied rather than stated.

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 reinforces this ('조회만 하며 기관에 저장하거나 제출하지 않습니다'). It adds non-obvious operational context the annotations do not cover: one token is consumed per call and there is an idempotency-key recovery protocol. However, the idempotency paragraph is generic boilerplate that reads oddly for a pure read-only list call, which slightly muddies rather than sharpens the behavioral picture.

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 prerequisite is correctly front-loaded, but the multi-sentence idempotency-key block is disproportionate boilerplate for a read-only lookup and dilutes an otherwise tight Korean purpose statement. The final token-cost note is short and 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 lookup with no output schema and full parameter coverage, the description supplies what matters: prerequisites, what is returned (code value plus name), that nothing is persisted, and the call cost. Only the shape of the returned list is left implicit, which is acceptable here.

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

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

Schema description coverage is 100%, so the schema already defines all three parameters including the classification-id examples and the account_link_id auto-resolution rule. The description adds only marginal framing (that codes are grouped by classification id) beyond the schema.

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

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

States a specific verb (조회/retrieve) and resource (공통코드, code values and names) and names the concrete downstream use — the reason/occupation fields of acquisition/loss reports — with example classification ids (B112, D114, A101). No sibling tool performs this lookup, so the agent can identify it unambiguously.

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

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

Gives a clear prerequisite (a prior fourinsure__session__login with the same account_link_id) and a clear context of use. There is no competing alternative tool to route away from, so the absence of explicit when-not guidance is minor.

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 (readOnlyHint=false, destructiveHint=false), the description adds real operational context: an auth prerequisite, per-call token cost ('호출마다 토큰 1소진'), idempotency behavior, and the note that the key is unavailable to anonymous taste calls. It does not state what server-side state the 'init' creates or how it is consumed downstream, which keeps it from a 5.

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

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

Front-loaded correctly, leading with the hard prerequisite before the purpose and the idempotency mechanics. The idempotency boilerplate is somewhat generic-heavy relative to the two optional parameters and could be tightened, but no sentence is pure 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 non-destructive init step with two optional params, no output schema, and annotation coverage, the description supplies the essential missing pieces: auth prerequisite, cost, and idempotency contract. The remaining gap is workflow context — what to call next (e.g., acqs_member_lookup / acqs_save) and what state this initializes.

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

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

Schema coverage is 100%, so baseline is 3, but the description pays off the schema's forward reference ('see the tool description') by fully explaining request_idempotency_key semantics and clarifying that a provider-specific idempotency_key is a different field. account_link_id semantics are left to the schema, which is adequate.

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: 'Initialize employee qualification acquisition declaration', matching the Korean title. An agent can tell what the tool creates, but there is no differentiation from close siblings such as acqs_precheck, acqs_save, chg_init, dependent_init, or los_init — the caller must infer the workflow position from the '_init' suffix.

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 prerequisite is explicit and front-loaded: 'REQUIRES prior fourinsure__session__login call with same account_link_id.' The idempotency-key paragraph gives clear when/when-not rules ('reuse ... only to recover that request', 'use a new key for a new execution'). It stops short of routing between sibling init/lookup/save tools, which is the main missing piece.

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 readOnly/non-destructive annotations, the description adds genuinely new behavior: it explicitly says nothing is stored or submitted to the institution, states a per-call cost ('호출마다 토큰 1소진'), and describes the return payload since there is no output schema. The idempotency paragraph is verbose and reads as mandatory while the schema marks the key optional, which is a minor internal inconsistency rather than an annotation conflict.

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 prerequisite, purpose, and read-only statement are well front-loaded, but roughly half the text is a four-sentence idempotency-key digression that crowds out the core lookup semantics, and the mixing of English and Korean adds friction.

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 usefully summarizes the returned values, plus prerequisites, read-only nature, and token cost — everything an agent needs to call it correctly. Only the sibling relationship to acqs_precheck/acqs_init remains unaddressed.

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 already 100%, so the baseline is 3; the description earns an extra point by explaining that applicant_name + resident_registration_number are the lookup keys and by tying account_link_id to the login session it must match. The idempotency-key explanation largely restates and lengthens what the schema already says.

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

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

The description states a specific verb and resource ('성명과 주민등록번호로 가입자를 조회해') and even enumerates the returned fields (rrkey, 대표자 여부, 보험별 자격취득일·상실일). It implicitly separates itself from the qualification-write siblings ('자격취득 신고서를 쓰기 전에') but never names acqs_init/acqs_precheck/los_member_lookup explicitly.

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

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

It gives a clear call context (call this before writing the acquisition report) and a hard prerequisite ('REQUIRES prior fourinsure__session__login call with same account_link_id'). What is missing is any mention of the nearby alternatives such as acqs_precheck or los_member_lookup, which an agent could easily confuse this with.

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 consistently reinforces that ("확인만 하며 기관에 저장하거나 제출하지 않습니다"). It adds real context, namely the auth prerequisite and the per-call token cost ("호출마다 토큰 1소진"), but the long generic idempotency paragraph is boilerplate that does not fit a read-only check and muddies rather than clarifies retry behavior.

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 relevant content is two front-loaded sentences, but roughly half the text is a generic idempotency-key block (including the odd phrase "anonymous taste calls") that is irrelevant to a read-only pre-check. Mixed Korean/English also costs parseability, so every sentence does not earn 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?

Auth, cost and non-mutating behavior are covered for a simple three-optional-parameter tool. However, with no output schema, the description never says what the check returns (a count? per-member rows?), leaving a gap an agent would want filled before calling.

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 explains up_cvrc_no, account_link_id and request_idempotency_key in detail. The description adds only indirect meaning, implying that up_cvrc_no is the parent receipt number to scope the pre-check; the baseline 3 applies when the schema carries the load.

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 Korean sentence states a specific verb and resource: before writing an acquisition report, check how many entries already exist under the parent receipt number. That cleanly separates it from the write-path siblings (acqs_init, acqs_save). It does not explicitly name those siblings, 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?

"자격취득 신고서를 쓰기 전에" gives an explicit precondition for calling it, and the REQUIRES line adds the login-with-same-account_link_id prerequisite. No explicit when-not or named alternative is given, which keeps it out of 5 territory.

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 declare destructive=true, and the description goes well beyond them: it states the write persists at the institution, cannot be reverted via this API, does not actually transmit the report (final submission is manual on the info-link center), that omitting confirm only previews, and that each call consumes 1 token. Rich, non-redundant behavioral context with 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?

Front-loaded with the REQUIRES prerequisite and the irreversible-write warning, then flows into the confirm flow. It is dense and long but nearly every sentence carries actionable information; no filler.

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

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

For an 11-parameter destructive mutation with no output schema, the description supplies the missing context an agent needs: auth prerequisite, irreversibility, preview-before-confirm procedure, input provenance, and token cost. Nothing essential is absent.

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

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

Schema coverage is 100%, so baseline is 3. The description nevertheless adds value beyond the schema: the confirm preview-vs-save semantics, the origin of rrkey, and the lookup sources for the health insurance and occupation codes. It does not cover every field (e.g., account_link_id resolution), so it stops short of full compensation.

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

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

States a specific verb+resource: saves the acquisition report as a draft to the info-link center and returns a receipt number. Clearly distinguished from siblings like los_save and from the final submission step, which is explicitly said to happen elsewhere.

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

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

Explicit prerequisites (prior login with same account_link_id), an explicit two-step confirm flow (preview, get user consent, re-call with confirm=true), and named sources for input values (acqs_member_lookup for rrkey, com_cd.list for codes). Leaves little to inference.

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

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

With annotations declaring a non-read-only but non-destructive operation, the description adds useful behavior: authentication is required, each call consumes one token, and the idempotency key lifecycle is explained in detail. It still does not say what state the initialization creates or what side effects occur, so it falls short of full 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 prerequisite is front-loaded and the description is reasonably structured around purpose, authentication, and idempotency. It is somewhat dense and includes an awkward phrase ('anonymous taste calls'), but most sentences carry operational meaning.

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

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

For an initialization tool with no output schema, the description covers authentication, idempotency, and cost, but it does not explain what the initialization returns or what the caller should do next. That leaves a meaningful gap for an agent trying to execute the full workflow.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description nonetheless adds meaningful semantics for request_idempotency_key, including when to generate it, when to reuse it, when to create a new one, and how it differs from a provider-specific idempotency_key.

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 employee qualification change declaration.' It distinguishes the 'change' flow from the sibling acquisition/loss/dependent init tools by naming the qualification-change context, though it does not explicitly route against those siblings.

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

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

It gives a clear prerequisite: a prior fourinsure__session__login call with the same account_link_id. However, it does not explain when to choose this init tool over the sibling member_qualification acquisition/loss/dependent init tools, nor what workflow step should follow.

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 readOnlyHint=false/destructiveHint=false; the description goes further by disclosing the login precondition, the per-call token cost ("호출마다 토큰 1소진"), and that the idempotency key is unavailable to anonymous calls. The idempotency/recovery semantics are explained in real depth, well beyond the annotations.

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

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

Front-loading the login requirement is good, but the middle is padded with idempotency boilerplate and a confusing clause ("not available to anonymous taste calls"; "provider-specific idempotency_key... it is a different field") that costs more than it earns for a 2-parameter init 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?

Covers auth, idempotency, and token cost for a simple 2-param, no-output-schema tool. It omits what initialization returns or which follow-up tool (e.g., dependent member lookup/save) should be called next, leaving the workflow incomplete.

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

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

Schema coverage is 100%, so baseline is 3. The description nonetheless adds meaning to request_idempotency_key that the schema does not: reuse only to recover a lost-response request, generate a new key for a new execution, and do not conflate it with a provider-specific idempotency_key.

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

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

States a specific verb and resource: "Initialize dependent qualification declaration." It is clearly a dependent (피부양자) qualification flow, distinguishable from the acqs/chg/los siblings by the resource name, though it never explicitly contrasts itself with those siblings.

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

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

"REQUIRES prior fourinsure__session__login call with same account_link_id" gives a concrete prerequisite, which is useful. But there is no guidance on when to pick this over the sibling inits (acqs_init, chg_init, los_init) or what to do after initialization, so usage is only implied.

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/destructiveHint, and the description stays consistent while adding real context: nothing is saved or submitted to the institutions, each call consumes 1 token, and a session/certificate binding is required. The idempotency-key paragraph is boilerplate that adds little for a pure read, but the cost and no-write guarantees are genuinely useful.

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 prerequisite is correctly front-loaded and the core check is one sentence, but the block mixes Korean and English and spends several sentences on request_idempotency_key guidance that is largely irrelevant to a read-only existence check, diluting the signal.

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 read-only pre-check with full schema coverage and no output schema, the description covers prerequisite, cost, and the no-side-effect guarantee. The main gap is not telling the agent what the check's verdict means for the next step (proceed to los_save vs. skip).

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 flag encodings, rrkey provenance, and account_link_id resolution are already documented. The description only restates that rrkey comes from the loss-member lookup result, adding no syntax or mapping detail beyond the schema — baseline 3.

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

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

The Korean sentence states a specific verb and resource: check whether a prior qualification-loss declaration already exists for one of four insurance types (national pension, health, employment, industrial accident), and frames it as a step taken before writing the loss form. This clearly separates it from the writing sibling los_save, though it never names that sibling explicitly.

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

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

Gives an explicit when-to-use (before composing the 자격상실 신고서) and a hard prerequisite (prior fourinsure__session__login with the same account_link_id). It implies rrkey originates from the loss member lookup but does not name los_member_lookup/los_save or state how to branch on the 'exists / does not exist' outcome.

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

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

Annotations only say readOnlyHint=false / destructiveHint=false, so the description carries most of the burden and does add real context: session prerequisite, a per-call token cost ('호출마다 토큰 1소진'), and detailed idempotency-key retry semantics. It still doesn't say what state initialization creates, whether it expires, or whether calling twice is harmful.

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 prerequisite is front-loaded correctly, but roughly two-thirds of the text is idempotency-key procedure that dwarfs the one-line statement of what the tool actually does. Useful content exists, but the balance is off and the trailing Korean token-cost note is tacked on rather than integrated.

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?

There is no output schema, and the description never says what init returns or which sibling to call next (member lookup, exist check, save). For a step in a multi-call declaration workflow, that next-step information is what an agent most lacks.

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 account_link_id is fully explained there. The description goes beyond the schema for request_idempotency_key — the schema only says 'see the tool description' — and the description defines generate-before-first-call, reuse-only-for-recovery, and new-key-for-new-execution, plus the warning not to confuse it with a provider idempotency_key.

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

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

The description gives a specific verb+resource: 'Initialize employee qualification loss declaration.' An agent can identify the domain, but it never distinguishes this from the closely-named siblings (los_exist_check, los_member_lookup, los_save, acqs_init, chg_init), so the boundary between 'init' and the rest of the LOS workflow is left to inference.

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 prerequisite is stated explicitly (requires a prior fourinsure__session__login with the same account_link_id), which is genuinely useful. However there is no guidance on when to run init versus los_exist_check or los_member_lookup, nor on what sequence follows init — the alternative-selection guidance 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 already declare readOnlyHint/destructiveHint, and the description adds real value on top: it explicitly states nothing is saved or submitted to the institution, that each call consumes 1 token, and that authentication must be established first. The idempotency-key prose is behavioral but generic boilerplate rather than tool-specific.

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 prerequisite and purpose are front-loaded well, but roughly half the text is a multi-sentence idempotency-key explanation that reads as boilerplate and could be compressed to one clause. The Korean and English sections are not merged, making the description read as two stitched-together blocks.

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 usefully enumerates what comes back (rrkey, dates, prior-declaration flag), which is what an agent needs to chain into los_save. Auth prerequisite and token cost are also covered; only the ambiguity around which RRN parameter form to supply is unaddressed.

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 earns an extra point by identifying name and resident registration number as the lookup keys, which tells the agent that the remaining parameters (bpmno, declaration_apply_date, account_link_id) are ancillary. It does not resolve the ambiguity of rrno_front/back versus the single resident_registration_number field.

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

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

States a specific verb and resource (자격상실 가입자 조회) and goes further by naming the returned fields: qualification key (rrkey), per-insurance acquisition/loss dates, and prior declaration status. This makes it clearly distinguishable from the sibling write tools los_init/los_save in the same member_qualification 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?

Gives an explicit workflow slot ('자격상실 신고서를 쓰기 전에') and a hard prerequisite (prior fourinsure__session__login with the same account_link_id). It does not name a specific alternative sibling (e.g. los_exist_check vs los_save), so it stops just short of full routing 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 only say readOnlyHint=false and destructiveHint=true; the description adds far more — the write persists permanently at the institution, cannot be rolled back through this API, and does NOT complete the final transmission. It also discloses the dry-run/preview behavior and per-call token cost, which are not in any structured field.

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 hard gate (REQUIRES prior login) is front-loaded, followed by purpose, then the irreversibility warning, then the confirm workflow, then the rrkey note. Every sentence carries actionable information with 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 9-parameter mutation tool with no output schema and no annotations beyond safety hints, the description covers the missing pieces an agent needs: auth precondition, return value (receipt number), reversibility, the confirm/dry-run protocol, and cost. Nothing essential to correct invocation is left unstated.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents types and formats. The description nonetheless adds real meaning by explaining what actually happens when confirm is absent (payload is previewed, not saved) and by tying rrkey to the loss member lookup output.

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

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

States a specific verb and resource: saves a qualification-loss report as a draft at the information linkage center and returns a receipt number. It also clearly delineates the boundary versus a final submission ('신고서를 기관에 전송하지는 않으며'), which an agent can use to distinguish this from a submit-type 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?

Gives an explicit prerequisite (prior fourinsure__session__login with the same account_link_id) and a concrete two-step workflow: call without confirm to preview, show the user, obtain consent, then call again with confirm=true. It also states where rrkey must come from, so the agent knows which sibling to call first.

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 readOnlyHint=false and destructiveHint=false; the description goes beyond them by disclosing the per-call cost ("호출마다 토큰 1소진"), the auth requirement, and detailed idempotency semantics (reuse only for lost-response recovery, new key for a new execution). Some phrasing is confusing ("anonymous taste calls") and the "provider-specific idempotency_key" note refers to a field that does not exist in this schema, which dilutes the value slightly.

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 prerequisite is correctly front-loaded, but the middle section is dense and partly off-topic: the "anonymous taste calls" sentence and the provider-specific idempotency_key warning reference concepts not present in this tool's parameters. Mixed Korean/English and a trailing token-cost line make it read as accumulated boilerplate rather than a tight definition.

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?

There is no output schema, and the description never indicates what an init call returns or which tool should be called next, which is a real gap for a workflow-start tool. Auth, cost, and idempotency are covered, so the agent can call it safely but cannot plan the surrounding flow from this definition alone.

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

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

Schema coverage is 100%, so both parameters are already documented; the schema explicitly defers the idempotency key's meaning to the description. The description therefore earns credit for supplying the missing semantics (when to generate, when to reuse, when to discard the key). The account_link_id meaning is left entirely to the schema.

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

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

States a specific verb and resource: "Initialize payroll amount change application." That is clearly distinguishable from search/report siblings. However, it never says what "initialize" actually produces or which tool consumes the initialized state, and it does not differentiate itself from the many other `__init` siblings in the namespace.

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 prerequisite "REQUIRES prior fourinsure__session__login call with same account_link_id" is an explicit gating condition, which is useful. But there is no guidance on when to choose this init over other init tools or what step follows it, so the workflow context is only implied.

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 is free to add what they cannot: the session-prerequisite, the per-call token cost ('호출마다 토큰 1소진'), and the exact retry/idempotency semantics. The idempotency explanation is genuinely useful behavior an agent could not get from the schema alone.

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 prerequisite is correctly front-loaded, but a large share of the text is generic boilerplate (anonymous taste calls, provider-specific idempotency_key) that is not obviously relevant to this read-only FAQ lookup and dilutes the core instruction.

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?

Auth, cost, and idempotency are covered, and there is no output schema so return-value detail is not strictly owed. Still, for a 'detail' endpoint it says nothing about what the FAQ detail payload contains or how errors (e.g., unknown qstn_sn) behave.

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 for qstn_sn, account_link_id and current_page_no. The description earns the bump by documenting request_idempotency_key semantics that the schema defers to it ('see the tool description'): when to reuse vs. generate a new key, and that a provider-specific idempotency_key is a separate field.

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

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

States a specific verb and resource: 'Get FAQ detail', which distinguishes it from the sibling faqs__list at a glance. It does not spell out what the detail contains, but 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?

Explicitly names the prerequisite (prior fourinsure__session__login with the same account_link_id) and the idempotency-key protocol. However, it never says when to pick this over faqs__list or faqs__list_init, leaving that inference to the naming convention.

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?

"No credential or login required" and "호출마다 토큰 1소진" add real context beyond readOnlyHint/destructiveHint: anonymous access and a per-call cost. However, most of the paragraph concerns request_idempotency_key, which is described as unavailable to anonymous calls and therefore largely inapplicable to this read-only list, muddying rather than clarifying behavior.

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 core statement is one short sentence, but it is followed by six sentences of idempotency-key protocol that do not apply to an anonymous read-only list call and obscure the actual purpose. Front-loading is fine, but the bulk of the text does not earn 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 an 8-parameter search endpoint with no output schema, the description explains none of the return shape, pagination, or what the search fields filter. Instead it spends its capacity on key handling that the description itself says anonymous callers cannot use, leaving the practical calling contract underspecified.

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 eight search parameters are already documented in the schema; the description adds nothing about srch_opt, srch_txt, srch_clsf_cd, current_page_no, or pagination behavior. Baseline 3 applies when the schema carries the full parameter 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?

States a specific verb and resource ("List FAQs for 4대보험") and covers the anonymous-read nature, so the agent knows what it retrieves. It does not distinguish itself from the closely named siblings faqs__detail and faqs__list_init, which an agent could easily confuse with a plain list.

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 routing signal is "No credential or login required"; there is no guidance on when to pick this over faqs__detail (fetch a specific FAQ) or faqs__list_init (the init handshake that typically precedes this list). The agent must infer the sequence from sibling names alone.

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 is freed from proving safety. It adds real value on top: no credential/login needed, an explicit per-call token cost ('호출마다 토큰 1소진'), and idempotency/retry semantics. It stops short of saying whether initialization creates server-side state or expires, which is relevant for an 'init' 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?

About two-thirds of the text is idempotency boilerplate for a single optional parameter, while the core question (what initializing means) is never addressed. The Korean cost note is front-loaded at the very end, and the phrase 'anonymous taste calls' is unclear/likely a typo.

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?

There is no output schema, so the description should convey what an 'init' call produces, and it does not — no mention of return values, a session handle, or how it chains into faqs__list. Auth and cost are covered, but the missing return/sequencing information is a real gap for an initialization tool.

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

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

Schema coverage is already 100%, so baseline would be 3. The description goes further, explaining the lifecycle of request_idempotency_key (generate before first call, reuse only to recover a lost response, new key for new execution) and explicitly distinguishing it from a provider-specific idempotency_key.

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?

It names the resource (4대보험 FAQ list) and a verb (initialize), but never explains what 'init' actually does or how the result differs from the sibling fourinsure__b1__resources__faqs__list. An agent cannot tell from this text whether init returns data, creates a session, or just primes state.

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 detailed instructions on how to use request_idempotency_key, but no guidance on when to choose this tool over faqs__list or faqs__detail. Usage of the tool itself is left to inference.

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

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

With readOnlyHint=true and destructiveHint=false already provided, the description still adds substantial behavioral context: link validity for 15 minutes, file retention of 7 days, recovery receipt handling, idempotency key semantics, and token cost. It omits the critical default dry-run behavior, which determines whether an actual file is returned.

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 authentication requirement and core download behavior, but it is long and mixes preconditions, file retention, recovery receipts, idempotency, and token cost in dense paragraphs. Every detail is relevant to some flow, but the overall structure could be tighter.

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?

It covers authentication, link expiry, file retention, and idempotency well. However, it never mentions that dry_run defaults to true and returns only existence and file name unless set to false. For a download tool, omitting this default behavior is a significant completeness gap that could cause an agent to invoke it without receiving the actual file.

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 five parameters. The description adds meaningful detail for request_idempotency_key and account_link_id beyond their schema text. It does not add meaning for dry_run, atfl_id, or atch_file_sn, but those are adequately 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 clearly states a specific verb and resource: download a resource file, with details on formats (hwp/PDF), artifacts, and download URLs. It is clear what the tool does, but it does not explicitly distinguish this download tool from similar sibling download tools such as certificate history or forms attachments.

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 a strong precondition (prior fourinsure__session__login with the same account_link_id) and an alternative for expired links (xdata__job__result). However, it does not explicitly state when to use this tool versus other download siblings, leaving that inference to the agent.

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 does add real context — anonymous access works, and each call consumes one token (호출마다 토큰 1소진) — but the bulk of the text is idempotency boilerplate that is conceptually odd for a read-only lookup and includes the confusing phrase "not available to anonymous taste calls."

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 first two sentences are correctly front-loaded, but roughly two-thirds of the text is idempotency-key mechanics that are disproportionate for a read-only attachment lookup and bury the useful token-cost and auth-free facts at the edges.

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

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

With no output schema, the description carries the burden of saying what comes back — an attachment list, a download URL, or bytes — and it never does, nor does it point at files__download for the actual fetch. For a lookup tool whose return shape determines the next call, that omission is material.

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 three required IDs and current_page_no are already fully documented. The description marginally helps by clarifying that the optional key is distinct from a provider-specific idempotency_key, but adds nothing about the ID formats or the page-number recovery 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?

"Get form attachments" states a verb and a resource, and the title confirms it is an attachment lookup for forms. However, "Get" is ambiguous between listing attachment metadata and fetching file bytes, and the description never distinguishes this from the sibling files__download or forms__detail, so an agent cannot resolve the boundary without outside knowledge.

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 selection guidance is "No credential or login required," which is a precondition, not a when-to-use rule. Nothing says when to call this versus files__download, forms__detail, or forms__list, nor when the idempotency key branch applies beyond the vague "authenticated call."

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

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

Annotations already declare this a safe read (readOnlyHint true, destructiveHint false), so the bar is lower; the description usefully adds that no login is required and that each call costs one token. However, the bulk of the text is generic idempotency-key boilerplate that is largely irrelevant to a read-only, anonymously accessible detail fetch and may mislead an agent into overthinking key management.

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 first two sentences are efficient and front-loaded, but five sentences of idempotency-key policy dominate a one-line read operation, dwarfing the actual purpose. The token-cost note is buried at the end after boilerplate the agent likely doesn't need here.

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?

Auth availability and token cost are covered, and annotations carry the safety profile, but with no output schema the description never indicates what a form detail contains (body text, metadata, attachment references) or that forms__attachments is the route to files. Adequate but leaves real gaps for a detail-lookup tool.

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

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

Schema coverage is 100%, so the schema already documents bbs_id and pst_sn with their source (forms.list), and the description adds no field-level meaning. It only expands on request_idempotency_key behavior, which is already referenced in the schema – baseline 3 applies.

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

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

States a specific verb+resource ('Get form detail'), which an agent can distinguish from the sibling forms__list and forms__attachments reads. It does not explicitly name those siblings or clarify the boundary, 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?

There is no statement of when to use this detail fetch versus forms__list (to discover IDs) or forms__attachments (to get files); the list-to-detail workflow only appears in the schema's parameter text, not the description. The only guidance given is authentication availability, which is context rather than tool selection.

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 non-derivable behavior: the auth-free access mode and the per-call cost ("호출마다 토큰 1소진"), which matters for budgeting repeated list calls. The idempotency discussion is largely boilerplate for a read-only list, which keeps it from a 5.

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

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

The purpose sentence is buried in second position behind an auth note, and the majority of the text is a long idempotency-key tutorial that is irrelevant to an anonymous read-only list operation. The token-cost warning is appended at the very end, where it is easy to miss.

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?

Auth mode, token cost, and key handling are all addressed, and parameters are fully covered by the schema with no output schema to explain. What is missing is anything about result volume, paging behavior, or how results relate to forms__detail, which an agent needs before calling.

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% across all six parameters, so the schema already documents search fields and paging. The description adds nothing about srch_txt, the code filters, or default paging beyond what the schema states; it only elaborates request_idempotency_key, which the schema already flags as optional. 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 second sentence, "List available forms," states a clear verb and resource, and the Korean title mirrors it. However, it does not distinguish this tool from close siblings like forms__detail, forms__attachments, or forms__list_init, so an agent must infer which of the four to pick.

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

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

"No credential or login required" is a useful precondition that tells the agent this can be called anonymously, and the idempotency paragraph implicitly scopes the key to authenticated calls. But there is no guidance on when to use this versus list_init or detail, and no instruction about paging through results.

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/destructiveHint, and the description adds real context the annotations do not: no credential/login required, token cost per call (호출마다 토큰 1소진), and the fact that the idempotency key is unavailable to anonymous test calls. It doesn't describe what the init actually returns or whether it establishes session state, which caps it at 4.

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 purpose is buried in the second sentence after the auth note, and idempotency mechanics dominate the bulk of the text. Nothing is outright waste, but the ordering is not front-loaded and 'anonymous taste calls' reads as a garbled translation.

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-param init tool with no output schema, the description covers auth, cost, and the key, but omits what an init returns and how it relates to the sibling forms__list call an agent will presumably make next. Adequate but with a real gap for an 'init' tool.

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

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

Schema coverage is 100%, so a baseline of 3 applies, and the description meaningfully extends it: generate the key before the first request, reuse it only to recover a lost response, use a new key per execution, and do not conflate it with a provider-specific idempotency_key. That is genuine semantics beyond the schema's one-liner.

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 sentence "Initialize forms list" gives a clear verb and resource, but dozens of sibling *__init tools exist and a direct sibling forms__list also exists. The description never explains what 'initialize' means here or why it precedes forms__list, so an agent cannot distinguish the two without opening schemas.

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 conditional guidance is about the idempotency key (when to reuse vs. create new), not about when to call this tool versus forms__list or faqs__list_init. The ordering relationship with the downstream list call is left entirely 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, and the description goes beyond them by stating no credential/login is required and that each call costs one token (호출마다 토큰 1소진), which is real operational context. The idempotency-key recovery semantics add further value, though the phrasing about 'anonymous taste calls' is muddled.

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 purpose sentence is correctly front-loaded, but four of the five sentences are reusable idempotency boilerplate that dwarfs the actual tool-specific content. Each sentence is arguably necessary in isolation, yet the ratio makes it bloated for a simple read.

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 attachment fetch with no output schema, the description never says what comes back (file metadata vs. download URLs) or how to actually retrieve the files via the download sibling. That return-shape gap is the main thing an agent still has to guess.

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 pst_sn and account_link_id fully documented in the schema, so the baseline is 3. The description only elaborates on request_idempotency_key, which the schema already flags as optional, so it adds no parameter meaning beyond what is structured.

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 sentence "Get institution notice attachments" names a specific verb and resource, which is enough for an agent to grasp it. It does not, however, distinguish it from sibling tools such as notices__institutions__detail, forms__attachments, or files__download, so the agent must infer the difference.

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 guidance is about idempotency keys; the description never says when to use this tool instead of the notice detail or the file download tool, nor what prerequisite the pst_sn from institutions.list implies beyond what the schema already states. Nothing tells the agent 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 cover read-only safety, but the description adds real behavioral context: no login required, per-call token consumption ('호출마다 토큰 1소진'), and idempotency-key semantics including the rule that reuse only recovers a lost response. The idempotency paragraph is somewhat boilerplate for a read-only detail call, but the auth and cost disclosures are genuinely useful.

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

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

Purpose and auth status are front-loaded, which is good. However, the long idempotency-key paragraph is repetitive and disproportionate for a read-only detail endpoint, and the trailing Korean token note reads as an afterthought.

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 single-record tool with full schema coverage and safety annotations, the definition covers auth, cost, and idempotency adequately. It doesn't describe what the notice detail returns (body, fields), but with no output schema and a clear 'detail' name that gap is minor.

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

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

Schema coverage is 100%, so pst_sn and account_link_id are fully documented in the schema. The description earns extra credit by carrying the semantics for request_idempotency_key, which the schema explicitly defers to ('see the tool description'), explaining when to reuse vs. create a new key.

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

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

States a specific verb and resource ('Get institution notice detail'), which is clearly a single-record fetch. It doesn't explicitly contrast with siblings like notices__institutions__list or __attachments, so an agent must infer the list-vs-detail vs attachments split from the names 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?

There is no when-to-use guidance, no mention of when NOT to use it, and no routing to the list or attachments siblings. The only contextual hint is 'No credential or login required', which is about auth rather than tool selection.

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 two genuinely non-obvious traits: anonymous access is possible, and every call consumes one token ('호출마다 토큰 1소진'). The idempotency paragraph explains retry and key-reuse semantics, though it is heavier than a read-only list warrants.

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 purpose and the no-login constraint are front-loaded, which is good. But the middle of the description is a dense idempotency treatise with multiple restatements ('Without it, calling again remains a new request', provider-specific key distinction) that outweigh the payload for a zero-required-parameter list call.

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?

There is no output schema, so the description should say what a notice list entry looks like or how paging works given the current_page_no parameter. It never does, leaving the agent to infer the return shape and pagination behavior from the parameter names alone.

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 srch_opt, srch_txt, srch_inst, and current_page_no are already documented and the baseline is 3. The description adds meaning only for request_idempotency_key (generate before first call, reuse only to recover a lost response, not available to anonymous calls), which is real value but limited to one of five parameters.

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 single sentence 'List institution notices' gives a specific verb and resource, and the tool name scopes it to the institution notice category. It does not, however, distinguish itself from adjacent siblings such as institutions__detail, institutions__attachments, or institutions__list_init.

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 usefully states that no credential or login is required, which tells the agent this can be called anonymously. It gives no guidance on when to use this list versus the detail/attachments siblings, nor when an authenticated variant or list_init should be preferred.

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

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

Annotations already declare readOnlyHint=true / destructiveHint=false, and the description adds real context beyond them: no login required, one token consumed per call, and how repeat calls are treated as new requests. What it never discloses is what 'initialization' actually does — whether prior list state is reset — which matters for an init-style 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?

The purpose sentence is buried after an auth caveat, and roughly three-quarters of the text is idempotency boilerplate that reads like it was templated across many tools. The trailing Korean token-cost note is useful but tacked on rather than integrated.

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?

Auth, token cost, and idempotency are covered, but for a one-parameter read-only init tool with no output schema, the description never says what the initialization returns or what the agent should call next. That missing hand-off makes it only 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 coverage is 100%, so a 3 is the floor, and the description genuinely earns the extra point by explaining how request_idempotency_key should be generated, when it may be reused, why it must not be confused with a provider-specific idempotency_key, and that anonymous calls cannot use it.

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?

"Initialize institution notices list" names a resource but 'initialize' is left unexplained — it restates the title and the sibling name (list_init) without saying what state is established or what the caller gets back. Siblings such as notices__institutions__list, __detail, and faqs__list_init are not distinguished in any way.

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 offers no when-to-use guidance: no statement of why an agent would call list_init before notices__institutions__list, and no prerequisites beyond 'no credential required'. The idempotency-key advice is procedural for a single parameter, not a routing rule between 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 declare readOnlyHint/destructiveHint; the description adds meaningful behavior beyond that: the required authentication state, per-call token consumption ('호출마다 토큰 1소진'), and idempotency semantics including what happens when no key is supplied. The opaque sentence about the key being 'not available to anonymous taste calls' is confusing and detracts slightly.

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 prerequisite is front-loaded, but the core purpose statement is buried behind it and the idempotency guidance sprawls across five sentences, one of which ('anonymous taste calls') is unclear filler. The token-cost note is useful but tacked on in Korean at the end.

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, an agent is left not knowing what the init returns (e.g., a prepared application handle or reference data) or what step follows, which matters for an init tool in a multi-step flow. Auth and idempotency are well covered, so it is adequate but not 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 coverage is 100%, so the baseline is 3, but the description adds real semantics the schema defers on: the idempotency key is for recovering a lost-response request with identical arguments, a new key is needed for a new execution, and provider-specific idempotency_key fields must be left untouched. account_link_id meaning is left entirely to the schema.

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

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

States a specific verb and resource: 'Initialize auto transfer cancellation application,' which an agent can act on directly. It does not, however, distinguish this tool from adjacent init-style siblings (e.g., fourinsure__b1__workplace__withdrawal__init) or describe what the initialization produces.

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 fourinsure__session__login call with same account_link_id,' which is the key gating condition. It also gives a concrete reuse-vs-new-key policy for request_idempotency_key, but names no exclusion or alternative tool for a different situation.

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 readOnly/non-destructive annotations, it discloses authentication requirements, request idempotency semantics, that the key is unavailable to anonymous calls, that provider-specific idempotency_key fields must be left unchanged, and that each call consumes one token. This is unusually rich behavioral context for an initialization endpoint.

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 authentication prerequisite and tool purpose, followed by idempotency details and cost. It is reasonably efficient, though the idempotency block is dense and the phrase 'anonymous taste calls' is potentially confusing.

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

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

For a two-optional-parameter initialization tool with rich schema descriptions and readOnly annotations, the description covers the key operational concerns: login prerequisite, idempotency behavior, and token cost. It does not explain what initialization returns or what the next workflow step is, but no output schema exists to make that omission less 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 both optional parameters are already documented structurally. The description still adds meaningful semantics for request_idempotency_key by explaining when to generate it, when to reuse it, and when to use a new key; account_link_id remains mostly schema-driven.

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 the household worker insurance support declaration. It is clearly distinguishable from unrelated sibling tools, though it does not explicitly contrast itself with the nearby insurance_support__init variant.

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 a clear prerequisite: a prior fourinsure__session__login call with the same account_link_id, and explains the idempotency-key reuse condition after a lost response. It does not state when to choose this over sibling initialization tools, but the workflow 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 declare readOnlyHint=true and destructiveHint=false, so the description adds real value beyond them: it discloses token consumption ('호출마다 토큰 1소진'), the auth precondition, and detailed idempotency-key recovery semantics. What it omits is any statement of what state the 'init' actually creates or how that squares with a read-only 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 critical precondition is front-loaded and the idempotency guidance is compact. Some phrasing is awkward or possibly mistranslated ('anonymous taste calls', the trailing Korean token note), which slightly blunts readability but does not bury the actionable 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?

Auth requirements and idempotency handling are well covered, but with no output schema the description never explains what the init returns or what the caller should do with it next in the declaration workflow. For a 0-required-parameter setup tool this leaves a meaningful gap in what the agent needs to proceed.

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 goes further by explaining the lifecycle of request_idempotency_key (generate before first request, reuse only to recover a lost response, new key per execution) and by noting a provider-specific idempotency_key is a distinct field. This meaningfully enriches the parameter beyond the schema's 'see the tool description' pointer.

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

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

States a specific verb and resource: 'Initialize workplace insurance support declaration'. An agent can identify this as the setup step for the 두루누리 insurance support flow. It does not, however, explicitly contrast itself with closely related sibling init tools like workplace_support__household_worker__init or workplace__auto_transfer_unagreement__init.

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 prerequisite is stated up front ('REQUIRES prior fourinsure__session__login call with the same account_link_id'), which is useful context. However, it gives no guidance on when to pick this over the sibling init tools or what conditions distinguish the insurance_support variant, so usage selection is only partially implied.

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 give only readOnlyHint=false and destructiveHint=false. The description adds substantial behavior beyond that: authentication prerequisite, the cost of one token per call, and a precise idempotency-recovery policy (reuse key only after a lost response, new key for new execution, do not confuse with a provider-specific idempotency_key field). It does not say what state is created or whether a partial initialization expires, but the operational traits it does disclose are valuable.

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 critical precondition is front-loaded, which is good, but the middle section is dense and slightly muddled (e.g., the odd phrase 'anonymous taste calls' and a somewhat repetitive restatement of the new-key rule). It is longer than needed for two optional parameters.

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?

Auth prerequisites and idempotency are fully covered, but there is no output schema and the description never indicates what the initialization returns or what the natural next step is (none of the sibling tools is named as a follow-up). For an init tool that stages state, that leaves a gap an agent must guess at.

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

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

Schema coverage is 100%, so baseline would be 3, but request_idempotency_key's schema description explicitly defers to the tool description ('see the tool description'), and the description fulfills that with concrete reuse semantics. account_link_id is left entirely to the schema, which is acceptable given its detailed description there.

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: 'Initialize workplace withdrawal declaration,' which distinguishes it from sibling init tools like business_establishment__init or auto_transfer_unagreement__init by resource. It does not explain what the initialization actually produces or stages for a later call, but 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?

It states a hard precondition ('REQUIRES prior fourinsure__session__login call with same account_link_id') and gives clear rules for when to reuse vs create a new request_idempotency_key. No exclusion or alternative-tool guidance is given, but the invocation context is well specified.

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, the description discloses that the tool returns API_KEY, consumes one token per call, and has detailed idempotency behavior after lost responses. It also notes that the optional idempotency key is unavailable to anonymous calls, which is meaningful operational context.

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

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

The description front-loads the critical ordering and purpose, then covers idempotency. It is somewhat long and includes a confusing phrase ('anonymous taste calls'), but most sentences add actionable context.

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 login tool with complete schema coverage and no output schema, the description explains the return value (API_KEY), the required call ordering, token cost, and idempotency behavior. Nothing essential for correct invocation appears to be 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 auth_provider and account_link_id are already documented in the schema. The description adds useful semantics for request_idempotency_key, including when to reuse it and how it differs from a provider-specific idempotency_key.

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: login to FourInsure (4대보험) EDI, with the added instruction to call it first for this provider. It also names the provider explicitly, which distinguishes it from the many sibling session__login tools for other providers.

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 first sentence gives an explicit ordering rule: call this FIRST before any other tool for this provider. The description also explains when to reuse request_idempotency_key for recovery versus when to use a new key for a new execution.

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, but the description adds genuinely non-obvious behavior: independent per-axis reporting, empty-vs-blocked distinction, and especially the data_availability taxonomy where 'no_rows and access_error do not mean zero' — that prevents a serious misinterpretation. It also flags externally-authored strings as data, not instructions. It loses a point because the idempotency paragraph is generic boilerplate awkwardly grafted onto a read-only, zero-required-parameter call, and the phrase 'not available to anonymous taste calls' is irrelevant template bleed that adds noise rather than 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?

Well front-loaded: purpose, asset list, read-only status and the 'call this first' rule all land in the first three sentences. But roughly a third of the text is reusable idempotency boilerplate that does little for a read-only status call, plus an unexplained Korean trailing line about token consumption, so several sentences do not earn their 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?

With no output schema, the description carries the burden of describing the return value, and it does reasonably well: per-axis asset lists, the data_availability status set with semantics, and the note that some lists start empty. What is missing is the concrete shape of a per-axis entry (e.g., whether blocked axes carry an error code or message), so an agent knows what to expect but not exactly what fields it can read.

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 both optional parameters are already documented, and the description's only parameter-adjacent content is the idempotency-key reuse rule (new key per new execution, reuse only to recover a lost response), which is useful. However, 'Takes no parameters' slightly understates the schema, which exposes an optional account_link_id that the agent may need when multiple connections exist; the description never mentions that escape hatch.

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

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

States a specific verb and resource ('Report whether the Google link is usable and list the assets it can read') and enumerates the five asset axes it covers. An agent can immediately distinguish this preflight/status tool from the dozens of google__ads__*, google__analytics__*, google__search_console__* and google__tag_manager__* siblings that operate on a single asset type.

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: the other google tools only accept assets the customer selected for this link' gives an explicit ordering rule and the reason for it, and names the alternative family it gates. The follow-on notes about per-axis independence and empty Ads/YouTube/Tag Manager lists until features are enabled tell the agent what to expect rather than to retry or misread an empty result.

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 declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context beyond that: date inclusivity and account time zone, metric reshaping rules, currency conversion behavior, row_limit semantics, data_availability states, prompt-injection caution, and idempotency-key handling. Nothing in the description contradicts 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 a clear purpose statement and most sentences carry operational value. It is nevertheless a dense, run-on block, and lines such as 'metrics.impressions is returned as metrics.impressions' are repetitive; a more structured presentation would improve scanability without losing information.

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

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

There is no output schema, so the description must explain return behavior, and it does: row-level metric placement, currency_code and currency_minor_unit_digits, data_availability meanings, truncation signaling, and next_page_token constraints. For a 9-parameter read-only report with complex metric reshaping, this is complete enough for an agent to call and interpret results 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 coverage is 100%, so the baseline is 3, but the description adds important meaning the schema does not provide: which metrics stay at top level, which are moved under channel_metrics, why conversions differ from GA4, how cost_micros becomes metrics.cost, and that row_limit is not forwarded to Google. It also clarifies practical usage of page_token and request_idempotency_key.

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

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

The first sentence states a specific verb, resource, and scope: report combined performance across four named campaign types for one Google Ads account over a date range. It also explicitly distinguishes this tool from the video report tool, so an agent can tell it apart from siblings without opening schemas.

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 when/when-not guidance: video campaigns are excluded and routed to the video report tool. It also tells the agent what to do on no_rows, when next_page_token is safe to reuse, and how to recover from truncated or partial results, which goes beyond routine usage guidance.

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