kr-groundtruth

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

Annotations already declare the operation read-only and open-world, so the description does not need to restate safety. It adds useful operational context beyond the schema: credit cost per call, cache-hit behavior, dependency on search_address output, and the integer-KRW semantics of deal_amount_krw. Response pagination details are not disclosed, but this is a minor gap given 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 compact and front-loaded: cost appears first, followed by the core resource and required dimensions, then the one non-obvious input source. The example is embedded efficiently in parentheses. Every clause earns its place with no filler.

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

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

Required inputs and their source are well covered, and the mention of deal_amount_krw hints at the response contents despite the lack of an output schema. Still, since there is no output schema, the description should clarify the overall return shape, pagination behavior, and result-list semantics; these are only implied by page/per_page parameters.

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

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

The description enriches lawd_code by telling the agent to reuse search_address's lawd_code and provides a concrete example, which the schema itself does not convey. However, page and per_page receive no semantic enrichment beyond their names and default values, and schema coverage is only 50%. This is adequate but leaves clear gaps for the optional 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 description names a specific resource ('국토교통부 아파트 매매 실거래가'), a concrete query dimension (시군구 + 계약월), and the exact code format. This goes well beyond restating the tool name and makes it easy to distinguish from sibling tools such as search_address or get_pricing.

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 actionable guidance: use the lawd_code returned by search_address, with an explicit Gangnam-gu example. It clearly implies this is a follow-up lookup after address resolution. It does not explicitly state when not to use it, but the context is strong enough for an agent to choose correctly.

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 carry readOnlyHint=true and openWorldHint=true, so the description's job is lighter. It adds useful context: the scope ('current API key account') and both return elements (credit balance plus recharge URL guidance), all consistent with read-only behavior. No contradiction with annotations, but it stops short of disclosing response format or any side effects.

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?

A single efficient sentence that front-loads 'Cost: free' before stating the full functional result. Zero wasted words or redundant restatements of the title.

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

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

Complete for a simple, parameterless read-only tool: it discloses the account scope and both returned items (balance, recharge URL). There is no output schema, so a brief note on response structure would be nice, but for a balance check this is 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?

The tool has zero parameters and schema coverage is 100% vacuously, so the baseline per the rubric is 4. There is nothing for the description to explain; the 'current API key account' scope already clarifies what balance is returned. No compensation is needed.

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

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

The description states a clear verb ('returns') and resource ('current API key account's credit balance and recharge URL guide'). The purpose is inherently distinct from all siblings, which handle business-dataset lookups (apartment prices, corporations, addresses, laws), so an agent can tell it apart without extra cues. It would earn a 5 if it explicitly named a sibling, but differentiation is still obvious.

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?

Offers no guidance on when to use this tool versus alternatives and names no alternative tool. The 'Cost: free' note is a light usage hint about cost implications but says nothing about selection context, prerequisites, or when not to use it. For a balance-inquiry tool this is a modest but real 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 already provide readOnlyHint and openWorldHint. The description adds the 'Cost: free' note and enumerates the returned information, but it does not disclose output format, pagination, or other operational behavior. It does not contradict the annotations.

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

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

The description is a single compact sentence that leads with the cost and then lists the three pieces of returned information. There is no filler, repetition, or unnecessary detail.

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

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

For a zero-parameter, read-only tool with annotations already present, the description is mostly complete. It clearly states what is returned, though it omits the exact response structure or format, which is a minor gap given no output schema exists.

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

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

The tool has zero parameters, so parameter-level semantic details are not needed. The baseline of 4 for zero-parameter tools applies, and the description carries no parameter documentation burden.

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

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

The description uses a specific verb '반환합니다' and names three concrete resources: per-tool credit cost, credit unit price in KRW, and recharge methods. It clearly defines the tool's purpose, but it does not explicitly distinguish it from sibling tools.

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

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

The description implies that the tool is used to fetch pricing and credit information, but it does not state explicit conditions for when to use it over alternatives such as get_balance. The usage context is understandable but 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 already signal read-only and open-world behavior; the description adds non-schema info about cost (2 credits/call, 1 on cache hit) and lists the returned fields. This is meaningful behavioral context, though it does not detail response structure or not-found behavior beyond what the open-world hint implies.

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

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

Two sentences, front-loaded with cost and purpose, no filler; the fallback instruction 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?

Low-complexity tool with a single fully documented parameter; the description lists all return fields, mitigating the absent output schema and referencing the relevant sibling for the lookup flow.

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 covers the sole parameter 100%, including pattern and meaning. The description reiterates corp_code and adds the conditional 'if unknown, search first,' a small usage boost, but does not add format or value semantics beyond the schema.

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

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

The description uses a specific verb ('조회합니다') with a clear resource ('기업개황') and enumerates the exact fields returned, so the agent knows precisely what this tool does. It contrasts with search_corporation by requiring corp_code, which differentiates it from the 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?

Explicitly states the precondition: corp_code is required. Instructs the agent to call search_corporation first if corp_code is unknown, which is an explicit alternative routing.

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 openWorldHint=true, so safety is covered. The description adds value by disclosing cost behavior (1 credit/call, cache hit 1), the normalization behavior, and the specific result fields returned. It does not describe pagination or ambiguous-match behavior, but the annotation coverage lowers the burden.

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

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

The description is compact and front-loaded with cost, then states purpose, return fields, and examples in two efficient sentences. Every sentence earns its place, and the examples clarify keyword formats without adding bulk.

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 carry the burden of explaining return values. It lists the key returned fields and gives a use case for lawd_code, but it does not describe the output shape, pagination behavior, or handling of no or multiple results. This is adequate but not fully complete.

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

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

Schema description coverage is low at 33%, and the description adds concrete keyword examples but does not explain page or per_page semantics. The pagination parameters have conventional names and defaults in the schema, so they are inferable, but the description does not fully compensate for the coverage 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?

The description clearly states a specific action ('search and normalize official address') and names the resource types (road-name, lot-number, building-name). It also enumerates concrete return fields (postal_code, adm_code, lawd_code, English address), making it easy to distinguish from sibling tools like search_corporation or search_law.

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 context for when to use the tool: resolving Korean address keywords into normalized official address data, including the lawd_code needed for apartment trade price lookup. It does not explicitly state when-not-to-use or name alternatives, but no sibling is closely ambiguous enough to require that.

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 provide readOnlyHint=true and openWorldHint=true, so the description's burden is reduced. It adds concrete details: cost per call, cache pricing, and that listed companies return stock_code. However, it omits behavior like result limiting (via limit parameter) or pagination, which are not covered by annotations.

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

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

The description is a single, compact sentence (plus a cost line) that front-loads key constraints and the primary use case. No filler or repetition; every element 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?

Given the annotations cover read-only and open-world aspects, the description covers the core functionality, output highlights (corp_code and stock_code), cost, and the downstream tool. It does not mention result limits or the exact return format, but these are minor given the schema and the clear linkage to lookup_corporation.

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 50% (name has a description, limit does not). The description adds no parameter-specific details beyond what the schema provides; it mentions neither the meaning of a partial name nor the function of the limit field. For the name parameter, the schema description is adequate; for limit, the schema's range and default offer some clarity, but the description does not compensate for the coverage 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?

The description explicitly states the verb (search), resource (법인 registered with DART), and outcome (find corp_code). It also distinguishes from lookup_corporation by noting the returned corp_code feeds that tool, making its unique role clear among 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 clearly states the primary use case (searching for a corporation by name to get corp_code for lookup_corporation) and mentions cost. It does not explicitly enumerate alternatives or exclusion conditions, but the linkage to lookup_corporation and the distinct domains of siblings provide adequate guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by disclosing the credit cost (2 credits/call, cache hit 1) and the return fields (law ID, department, dates, link). This goes beyond the annotations and gives an agent useful operational context, though it doesn't discuss pagination limits or error 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 description is a single focused paragraph, starting with the cost, then the purpose, returns, and examples. There is no redundant filler, and every sentence serves a function.

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

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

For a search tool with three parameters and no output schema, the description covers the essential return fields and provides examples. It does not mention sorting, result count behavior, or that the search is Korean-specific, but these are minor gaps given the tool's simplicity and the read-only nature conveyed by annotations.

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

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

The schema description coverage is only 33% (only the query parameter is described in the schema). The tool description does not compensate by explaining the page or per_page parameters; it only gives examples of query values. An agent would have to infer pagination semantics from the schema defaults alone, which is insufficient given the low coverage.

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

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

The description clearly states the tool searches current Korean statutes (현행 법령) from the National Legal Information Center, returns specific fields (ID, department, dates, link), and gives concrete examples. It is clearly distinct from the sibling tools which address real estate, balance, pricing, corporations, and addresses.

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?

While the description does not explicitly name alternatives or when-not-to-use, the sibling list is thematically unrelated, making the intended usage obvious. The description conveys it is for searching current laws, and examples reinforce the query format. Still, an explicit 'use this for legal searches' guidance would be clearer.

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 openWorldHint=true, covering safety and mutability. The description adds valuable behavioral context: cost per call (2 credits, 1 on cache hit), max 100 items per request, and the result status enum. These go beyond what annotations provide, though it omits details like rate limits or error handling.

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

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

The description is compact and front-loaded with the cost, then the primary function, verification condition, batch limit, and result statuses. Each sentence adds new information with no redundancy or filler, making it efficient for an agent to parse.

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

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

The description covers the essential aspects for calling the tool: cost, purpose, verification trigger, batch size, and result interpretation. Since there is no output schema, providing the status enum is helpful. Minor omissions like error conditions or behavior when verification fields are partially provided are not critical for a read-only API with clear annotations.

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 adds meaning by stating that providing representative_name and opened_date together enables verification, and that business_numbers accepts up to 100 items. It also clarifies the output status values, which helps the agent understand the parameter relationships and expected result format.

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

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

The description clearly states the tool queries business registration status (active/suspended/closed/not_registered) and tax type from the National Tax Service, with optional verification when name and opened date are provided. It also explicitly distinguishes itself from sibling tools like lookup_corporation or search_corporation by focusing on the registration number status rather than general corporate info.

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

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

The description gives clear context on when to use the tool (for registration status/verification) and how to trigger verification by providing representative_name and opened_date together. It does not explicitly mention when not to use it or name alternatives, but sibling tools operate in different domains (address, law, pricing, balance), so the intended use is evident.

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