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

Annotations indicate readOnlyHint=false (write), openWorldHint=true (unbounded/stateful), destructiveHint=false. The description complements these by disclosing that the tool saves files to disk (out_dir), automatically routes between REST/OAI, performs dual-axis union searches on REST path, and may produce multiple sweeps with retry_incomplete. It also warns about truncated results (truncated=true) and how to interpret meta fields. The only minor gap is that it doesn't explicitly state file write permissions or overwrite 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 quite long, with dense text covering multiple scenarios. While it packs valuable information, it lacks clear section breaks or bullet points for readability. Key warnings are fronted with ⚠️, which helps, but the overall structure is a single block of Korean text that could be better organized for an AI agent to parse quickly.

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 tool's high complexity (13 params, no output schema, multimodal routing), the description does a commendable job of covering core behaviors: REST vs OAI selection, dual-axis queries, retry logic, file output, date formats, and truncated data warnings. It is functionally complete for an experienced user, though it could benefit from an explicit listing of output file format or return value shape (since 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?

Schema description coverage is 0%, so the description must carry full weight. The description explains many parameters implicitly: terms, title, retry_incomplete, out_dir, date_from/until, year_from/to, contains, max_records, set_spec. It clarifies that dates are YYYY-MM-DD and years are integers. However, it does not explain formats, name, or provides a formal parameter-by-parameter mapping. But given the complexity (13 params), the description does a good job making sense of the core parameters through contextual examples.

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 precisely states that the tool collects (saves) articles from KCI by automatically choosing between REST (with key) or OAI (without key) based on the presence of authentication key and the nature of the request. It distinguishes itself from sibling tools like kci_search (which likely only searches), kci_detail (single article details), and kci_harvest (which may be a different collection method) by describing its dual-mode routing logic and file-saving behavior.

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-to-use guidelines by outlining the decision logic: use REST if terms/title are present and auth key exists, use OAI otherwise. It also warns about the behavior of retry_incomplete and when to set it to 0 to save cost. However, it does not explicitly compare against each sibling tool (e.g., when to use kci_harvest instead), and it lacks an explicit 'do not use if' clause.

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 the description does not need to cover safety. It adds useful context: the tool is RESTful, requires an authentication key, and provides fields absent from other endpoints. However, it does not detail rate limits, response size, or error handling. The description adds value beyond annotations 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?

The description is brief: two sentences plus a bolded summary. It front-loads the REST nature and authentication requirement, then explains unique value and use case. Every sentence adds value, though the first sentence could be more explicit about the input parameter.

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 a simple input schema (1 required string param) and no output schema, the description covers purpose, unique fields, and relation to other endpoints. It does not explain the output format or other potential usage nuances, but the tool appears simple and the description is largely complete for its complexity.

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?

There is only one required parameter (arti_id) with 0% schema description coverage. The description does not directly explain the parameter, but the tool name and context ('Control Number(ART…)') imply the parameter is a Control Number. Since the schema is minimal and the description adds some implicit meaning, a baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves detailed paper information by Control Number (ART…). It distinguishes itself from siblings by explicitly listing unique fields (author keywords, ISSN, indexing status, FWCI, author affiliations, references) not available in other tools like articleSearch. This is a specific verb+resource combination with explicit differentiation.

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

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

The description explains when to use this tool: for fields missing from articleSearch (e.g., keywords). It also mentions the prerequisite of an authentication key. However, it does not explicitly state when not to use it or name specific sibling alternatives, only contrasting with articleSearch which is not listed among siblings.

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

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

Annotations indicate read-only and open-world behavior, and the description adds valuable context: it's an OAI-PMH harvest requiring no authentication, and the 'contains' filter is a local post-filter rather than a server-side query. This discloses behavior not evident 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?

The description is a compact block with a leading summary and a short parameter legend. Every sentence delivers useful information without redundancy.

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

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

It covers all critical parameters and usage conditions, but does not describe the return format or pagination behavior, which is relevant for a bulk harvest tool. However, with no output schema, the description could have mentioned output details; still, the provided info is strong.

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?

Despite 0% schema description coverage, the description manually explains the meaning and allowed values for set_spec (ARTI/ARTI_CONF/JOUR), date formats (YYYY-MM-DD), metadata_prefix (oai_kci/oai_dc), and contains (local filter on title/abstract/keywords). It also specifies the no-auth condition, leaving only max_records implicit, which is self-explanatory.

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 '세트+날짜범위 대량 수확' (batch harvest by set+date range) and identifies the OAI-PMH protocol and no-auth requirement. This clearly differentiates it from siblings like kci_search/kci_detail which are not bulk harvesting operations.

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 implies usage for bulk harvesting via '대량 수확' and notes no auth key is needed, but does not explicitly compare against sibling tools or state when not to use it. There is no mention of alternatives like kci_search for targeted queries.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds the API key requirement and clarifies the two operational modes (year/year range for list, journal_id for detail), which is valuable context beyond annotations. However, it does not describe pagination or response formatting.

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 dense sentence that front-loads the tool's purpose and key parameters with no filler or redundant 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?

The description covers the API key, list/detail modes, and detail content (registration history and yearly IF), but with no output schema it does not describe the list response structure or the rows parameter behavior, making it incomplete for thorough understanding.

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 the description must compensate. It explains that year and years (2-5) drive list queries and journal_id drives detail, but it does not explain the rows parameter or how it interacts with the others, leaving a notable 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 identifies the tool as a journal citation index REST API with two distinct modes: listing by year (with years range) and retrieving details by journal_id. It is specific and distinguishable from sibling tools like kci_search and kci_detail.

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

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

The description implies usage for citation index lookups and outlines the parameter-driven modes, but it does not explicitly state when to choose this tool over alternatives or provide exclusions. It mentions the API key requirement as a prerequisite, which is helpful.

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 indicate readOnlyHint and openWorldHint, aligning with the description's data retrieval purpose. The description adds key behavioral details not in annotations: API has a 100-record limit per request, no pagination support, and the workaround of flipping sort_dir. It also clarifies that article_id in results is the citing article. No contradictions with annotations.

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

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

The description is relatively concise but includes a mix of Korean and English, potentially adding cognitive load. Key information is front-loaded (purpose, auth requirement). The workaround explanation is detailed but necessary; one sentence could be slightly trimmed.

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 moderate complexity (7 parameters, 1 required, no output schema, 0% schema coverage), the description covers core functionality, edge cases (100-record limit), and provides workarounds. It explains the return field meaning (article_id is citing article) and filter options, sufficient for an agent to use correctly without output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining institution filters, sort_by and sort_dir options, and the significance of the page parameter absence. However, it does not fully explain all parameters (e.g., author, pub_year, rows) leaving some burden on the agent to infer from names.

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 fetches raw reference records matching a title search term, specifying the resource (reference raw data), action (collect), and scope (title-matched articles). It distinguishes from siblings like kci_search (which likely searches articles directly) by focusing on references of matched articles.

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

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

The description provides explicit context on when to use this tool, including authentication requirements and filter usage. It also details workarounds for API limits when total records exceed 100. However, it does not mention when NOT to use this tool or explicitly compare against sibling tools for reference-related tasks.

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 (safe read) and openWorldHint=true (may not be exhaustive). The description adds substantial behavioral context: authentication requirement, the truncated flag meaning, and the critical warning that keyword search may not include keywords in results. The description is open about field absence, which goes beyond annotations. Minor deduction: does not explicitly state it is a REST-based tool beyond the tag, but that is acceptable.

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

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

The description is well-structured with a first line giving the core purpose, then parameter details, and finally a warning section and alternative. The warning about missing fields is front-loaded after the parameters. It is slightly long but every sentence adds value. Could be marginally more concise by combining some sentences, but overall efficient.

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

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

Given the 12 parameters, no output schema, and complex sibling tools, the description covers the essential usage: required auth, parameter formats, behavior for pagination and truncation, and field limitations compared to kci_detail. It lacks an explicit mention of the response structure beyond total/truncated, but since the tool is a search with a likely list response, the absence of output schema is partially mitigated. A more complete description might list other response fields (e.g., title, author, journal), but not required.

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?

Despite 0% schema description coverage (the schema has no descriptions), the narrative description explains the meaning of date_from/date_to (YYYYMM format), rows (max 100), institution filter, sort_by/sort_dir values, and the behavioral note about using sort_dir for pagination. It also explains the total and truncated fields. This is strong compensation for the missing schema descriptions. One minor gap: 'author' and 'journal' are listed in schema but not explained in text, though their names are self-describing.

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 begins with '[REST] 논문 검색 — title 필수 + 선택 필터', which clearly states the tool searches for KCI papers, identifies the required parameter (title), and notes optional filters. It distinguishes itself from siblings like kci_detail (used for per-item enrichment) and kci_harvest (for unauthenticated access), so purpose is very clear.

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

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

The description explicitly says '인증키 필요' (API key required) and directs users to kci_harvest (OAI without auth) when no key is available. It explains the sorting strategy for pagination and warns about the absence of certain fields in articleSearch. These provide both use-case guidance and alternatives.

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

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

Annotations already indicate read-only and open-world behavior. The description adds specific behavioral details by stating it checks OAI Identify without authentication and whether a REST API key exists. 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 succinct line in Korean, immediately conveying the tool's purpose without any extraneous words 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?

With no parameters and no output schema, the description covers the core purpose and scope adequately. It could optionally mention the return format, but for a simple status check, the description is reasonably 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?

The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter behavior since there are none.

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 performs a connection check, specifying both OAI Identify (no authentication) and REST API key possession status. This distinguishes it from sibling tools like kci_search and kci_detail.

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

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

The description provides clear context that this is a connectivity/status check, implying it should be used to verify API access before other operations. However, it does not explicitly name alternatives or state 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.