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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no indication of what the returned code list looks like, whether it is static or per-account, or how the codes relate to the search/collect siblings. With no output schema, this gap matters.

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

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

Two short fragments, no padding — but the second fragment is vague enough that its brevity comes at the cost of meaning. Short and front-loaded, yet under-specified rather than efficient.

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

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

With no output schema and no parameters, the description is the only place an agent can learn what this returns and how to use it. It says 'codes' exist for three dimensions but never explains the return shape, code granularity, or that the codes feed into auction_search filters — leaving a real gap for a discovery-style tool in a seven-tool family.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the description misleads about inputs.

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 the resource (court / province / land-building major classification codes) but the action is muddled: '하위 코드 목록 지원 범위 확인' reads as 'check the supported range of sub-code lists', which is not a clear verb. It does not distinguish itself from the similarly-named sibling auction_coverage, so an agent cannot confidently pick between 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?

There is no statement of when to call this versus auction_search, auction_coverage, or auction_detail. The closest thing to guidance is the mention of '하위 코드 목록 지원 범위', which is a hint at scope-checking but not an explicit usage condition or exclusion.

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 openWorldHint=true; the description adds substantive traits beyond that — progress is checkpointed atomically (safe to interrupt) and the query is frozen for a job_id, so changing conditions is refused. It omits failure/retry behavior and how max_calls interacts with the checkpoint, keeping it below 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?

Two terse sentences with zero filler, and the core mechanism (sequential + atomic checkpoint) is front-loaded. For a tool with a deeply nested query schema it is arguably under-sized, which keeps it from a 5.

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

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

Given the nested 14-property query object, no output schema, and the existence of auction_job_status for polling, the description should explain what the call returns (a job handle?) and how it relates to the status sibling. Those gaps are significant for a complex, long-running collection 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 only 25% across 4 params plus a 14-property nested query object. The description does add real meaning to job_id and query by explaining that the query must stay identical across resumes, but the nested filter fields and max_pages remain undocumented anywhere.

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 indicates a sequential bulk collection operation with atomic checkpointing, and the tool name supplies the 'auction' resource. However, it never says what is being collected (auction listings) or how it differs from sibling auction_search / auction_export, so an agent must infer the distinction.

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 rule for resuming ('resume with the same job_id, condition changes rejected') but gives no guidance on when to pick this tool over auction_search or auction_export, nor any prerequisite such as needing a prior run or a quota.

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 openWorldHint=false, so the safety profile is covered. The description adds the important nuance that this reflects 'actual verification scope and limits' (i.e., measured rather than advertised coverage), but says nothing about how results are produced or refreshed. Some added value beyond annotations, but not rich 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?

A single short sentence with no filler, and the key idea (scope and limits) is front-loaded. It is arguably under-specified rather than over-long, which does not hurt this dimension.

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 parameters and no output schema, the description carries the full burden of explaining what an agent will receive, yet it gives no sense of the return content (list of capabilities? pass/fail per feature?). For a meta/coverage tool whose whole value is the shape of its report, this is a significant omission.

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 takes zero parameters and the schema is an empty, closed object, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter guidance is needed or missing.

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 phrase '지원 기능과 실제 검증 범위·한계 확인' does name what the tool reports (supported features plus actual verification scope and limits), which is more than a restatement of the name. However, it never identifies the subject domain (the auction API/service) or the form of the output, so an agent cannot fully distinguish it from auction_detail or auction_job_status. Purpose is inferable but vague.

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 explicit when-to-use or when-not-to-use guidance, and none of the five sibling tools (auction_search, auction_codes, auction_detail, etc.) are mentioned as alternatives. An agent must guess whether this is a pre-flight capability check or a post-run validation report.

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 with openWorldHint=true, meaning this is not a pure local read and may reach external systems, yet the description says nothing about network calls, retries, rate limits, or whether a job/collection step is involved. The phrase about 'verifying' court/case identity hints at a lookup but does not disclose what happens when verification fails.

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

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

Two short fragments, front-loaded and free of padding, so it is certainly concise. However, the brevity is achieved by omitting necessary detail rather than by efficient expression, so it is terse without being informative.

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 openWorld non-read-only profile, and two undocumented required parameters, the description should carry much more weight than it does. It leaves the agent unable to predict return shape, failure behavior, or parameter formats.

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

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

Schema description coverage is only 33%: max_calls is documented, but court and case are bare strings with no format hints (court code? name? case number pattern?) and the description does not compensate at all despite those being the two required parameters. This is a critical gap because the tool's own stated purpose is verifying court/case identity.

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 identifies a 'detail' (상세) tool for auctions scoped to court/case, which gives some resource specificity. But '15A 상세' is unexplained internal shorthand and it never distinguishes itself from siblings like auction_search or auction_collect, so an agent cannot tell why to pick this one from the name text 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?

The only usage-adjacent statement is a disclaimer that this is not rights analysis or investment advice, which is scope exclusion rather than a when-to-use rule. There is no guidance on preconditions (that court and case must already be identified) or when to prefer auction_search/auction_collect 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?

With annotations declaring readOnlyHint=false but destructiveHint=false, the description corroborates this by stating output goes to a NEW local folder and existing output is not overwritten — resolving the apparent tension between writing and non-destructiveness. It could still mention prerequisite job state or permissions, but the key behavioral trait is disclosed.

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

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

It is extremely short and front-loads the formats and destination, but it reads as a sentence fragment and omits essential framing (that this is an export of a job's results). Brevity here costs clarity rather than earning it.

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

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

For a tool with a required identifier, multiple output formats, and no output schema, the description is missing the job_id relationship, the naming semantics of 'name', and any indication of what the return value contains. Only the overwrite policy is covered.

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 0%, so job_id (the only required parameter) and name have no documented meaning anywhere. The description does not clarify what job_id refers to or what the optional name does (presumably output file/folder naming), leaving both parameters to guesswork.

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 conveys the action indirectly: export output (JSONL/CSV/Excel) into a new local folder, with existing output preserved. The verb is only implied by the tool name rather than stated, and there is no explicit differentiation from siblings such as auction_collect or auction_job_status, which likely also produce output tied to a job.

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

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

There is no guidance on when to choose this over auction_collect or how it relates to auction_job_status (e.g., must a collect job finish first?). The only usage-adjacent statement is the no-overwrite rule, which is a behavior rather than a selection criterion.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds almost no behavioral context: it does not say whether the job may still be running, whether failures are truncated, or whether checkpoint data is stable across polls — the kind of context that actually matters for a status 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?

It is a single terse fragment with no wasted words, but that brevity comes at the cost of a missing verb and subject. Short is good here, yet the content is a return-value teaser rather than a structured statement of purpose.

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 a required identifier, no output schema, and no documented parameters, the description should explain how job_id is obtained and what a status response means for the caller. Instead it provides only a comma-separated list of fields, leaving the agent under-informed for even this simple tool.

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

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

Schema description coverage is 0% — the single required job_id has no description and carries only a regex pattern. The description never mentions job_id, its provenance (presumably returned by auction_collect), or what form it takes, so it fails to 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 is a noun fragment ('저장 건수·누적 요청·체크포인트·실패 요약') that lists the contents of a status report but never states the action or the resource — no verb like 'retrieves job status'. It hints at what the status contains, yet an agent must infer from the tool name that this reports on a collection job, and nothing ties it to the auction_collect sibling that presumably creates the job.

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

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

There is no guidance on when to call this versus auction_collect or auction_export, no mention of polling a running job, and no statement of prerequisites beyond the implicit job_id. The agent is left to infer the entire usage pattern from the name 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 openWorldHint=true and destructiveHint=false, but the description adds nothing about the remote court-data lookup, rate limiting, or the retry/connection budget governed by max_calls. Note the tension between the description's read-flavored '조회' and readOnlyHint=false; it is not an outright contradiction (the flag likely reflects network behavior), but the description gives no help in resolving 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?

A single short sentence with the essential scope front-loaded and no filler. Its brevity is appropriate in style but is under-specification rather than economy given the tool's complexity.

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 nested-object search with pagination, price/failure range filters, and a cumulative call budget, with no output schema and thin schema descriptions, the description leaves too much unaddressed. An agent cannot tell what a page contains, how results are ordered, or how paging terminates.

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

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

Schema description coverage is only 33% on a nested query object with roughly fourteen properties, so the description needs to compensate and largely does not. It mentions court/region and the sale-date range (start/end) but says nothing about page, page_size, usage/usage_mid/usage_small, or the appraisal/minimum/failures min-max range pairs.

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 (조회) plus resource and scope: one page of auction listings filtered by court/region and sale-date range. The phrase '한 페이지 조회' implicitly separates it from siblings like auction_export and auction_collect (bulk operations) and auction_detail (single record), though it never names them 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?

There is no statement of when to use this versus auction_export, auction_collect, or auction_detail, and no prerequisites or exclusions. The only usage signal, that it returns a single page, must be inferred from the word '한 페이지'.

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