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

The description goes well beyond the annotations by explaining key behavioral details: save=true writes a file and returns a path, while save=false returns records directly but only the first 100 ('앞 100건만 싣는다'). It also warns about meta.truncated and explains how to resolve truncation by raising max_records above meta.union_upper_bound. This provides actionable insight into side effects and output limits not present in the annotations.

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

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

The description is well-organized and front-loaded with the core purpose. It uses bullet-like explanations for the group structure, a concrete example, and a clearly marked warning. Every sentence adds value; no filler. Despite being longer than average, it remains scannable and information-dense.

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 complexity (10 parameters, nested groups) and the absence of an output schema, the description does a solid job of explaining the main flow, output modes, and truncation semantics. It falls slightly short on fully documenting every parameter, but the core behavior is well covered and the example clarifies the most complex part.

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

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

The schema has 0% description coverage, so the description must compensate. It thoroughly explains the 'groups' parameter with its nested fields (field, terms, contains, lang, max) and provides a JSON example. It also clarifies 'save' behavior. However, other parameters like target, formats, out_dir, year_from, year_to, and retry_incomplete are left unexplained, though some are self-explanatory from their 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's function: merging multiple search groups into a single corpus with deduplication ('여러 **검색 그룹**을 한 코퍼스로 합쳐 수집(CN 중복제거)'). It uses a specific verb (collect/merge) and resource (search groups into corpus), and this clearly distinguishes it from siblings like scienceON_search, scienceON_export, and scienceON_status.

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 the intended use case: building corpora that cannot be created with a single query ('단일 검색어로는 못 만드는 코퍼스를 만든다'). It provides a concrete example with different fields and filters. It does not explicitly mention alternative tools or when not to use it, but the use case is clear from the contrast with single-query search.

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

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

Annotations already declare readOnlyHint=true, signaling a safe read operation. The description adds no additional behavioral context such as return format, scoping constraints, or side effects; with the annotation coverage, this meets the minimum but does not go further.

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

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

The description is a single, concise Korean sentence with no redundant wording. It is appropriately sized for the tool's simplicity, though it lacks structure and would benefit from a brief usage note.

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

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

The tool is simple, and the description covers the core purpose and primary parameter. However, it omits any explanation of the target parameter, return behavior, and does not position the tool against its siblings, leaving noticeable gaps for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It provides meaning for control_no as the lookup key, but says nothing about the target parameter (default 'ARTI'), leaving a significant gap in parameter understanding.

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 bibliographic/abstract information by control number (CN). It uses a specific verb and resource, and the CN-based lookup distinguishes it from the sibling search tool, though it does not explicitly name alternatives.

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?

Usage is implied: this is the tool to use when you have a control number and need detailed record data. However, there is no explicit guidance on when to use this versus scienceON_search or other siblings, nor any stated prerequisites or exclusions.

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

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses crucial traits: max_records does not silently truncate but sets meta.truncated=true with a warning, meta.union_upper_bound is described, and out_dir defaults to user home scienceon-output/ due to arbitrary cwd. This is high-value behavioral context not visible in structured fields.

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

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

The description is front-loaded with the core purpose and uses line breaks and a warning block to organize details. The warning about max_records is detailed but earns its place because it prevents user misunderstanding. It is slightly dense but remains scannable.

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 13 parameters and no output schema, the description covers important behavioral warnings (truncation, return meta fields, out_dir default) but omits explanations for many parameters and does not fully specify the return structure beyond the path and meta fields. It is helpful but incomplete for a tool of this 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?

Schema description coverage is 0%, so the description must compensate. It explains queries, contains, lang, out_dir, and max_records, but leaves many parameters unexplained: name, field, target, formats (though formats are inferred from file extensions), year_from, year_to, retry_incomplete, and query (singular). This is a significant gap for a 13-parameter tool with no schema descriptions.

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

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

The description clearly states the tool's purpose: '검색 결과를 대량 수집해 파일로 저장(xlsx/csv/json/sqlite). 저장 경로 반환.' This specifies the verb (collect, save), resource (search results), and output (file formats and path), which distinguishes it from siblings like search, status, detail, and collect_groups.

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 concrete usage context: queries for multiple terms with union, contains as post-filter, lang for domestic-only, and out_dir behavior. While alternatives are not explicitly named, the description makes it evident this is for bulk export versus the sibling search tool. It lacks explicit 'when not to use' but provides sufficient context to select it appropriately.

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?

Despite having readOnlyHint and openWorldHint annotations, the description adds extensive behavioral context: it explains the 'CN 합집합' (CN union) logic for multiple queries, the post-processing filter (contains, case-insensitive), wildcard support, and importantly the semantics of total as an upper bound and truncated=true with a warning. It even warns against misinterpreting truncated results as a complete corpus, which goes 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?

The description is well-structured with clear line breaks and semantically grouped parameters. Each sentence adds value, including the critical truncation warning. Despite being dense, it remains concise and easy to parse, covering complex behavior without redundant text.

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

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

Given the tool has 10 parameters, no output schema, and complex union/filter behaviors, the description is remarkably complete. It covers parameter semantics, return value semantics (total, truncated, warning), and operational caveats. The only missing piece is retry_incomplete, but overall the description provides sufficient context for an agent to use the tool correctly.

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

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

With 0% schema description coverage, the description compensates well by explaining nearly every parameter: query, queries, target, field, year range, rows, contains, and lang. It provides allowed values and behaviors. However, the parameter 'retry_incomplete' is absent from the description, creating a minor gap for that one parameter.

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 opens with 'ScienceON 문헌 검색' (ScienceON literature search), clearly identifying the action (search) and resource (literature). It further specifies target types (ARTI, REPORT, ATT, RESEARCHER, ORGAN) and field options, which distinguishes it from sibling tools like status, detail, export, and collect_groups.

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 detailed parameter usage (query vs queries, target, field, rows, etc.) and explains the union search behavior, but it never explicitly states when to use this tool versus alternatives like scienceON_status or scienceON_export. The usage context is clear for the search operation itself, but no alternative guidance is provided.

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

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

The description goes beyond the readOnlyHint and openWorldHint annotations by explaining that on failure it returns cause hints and the current public IP. This adds valuable behavioral context without contradicting the annotations.

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

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

The description is a single, focused sentence that immediately states the tool's purpose and failure behavior. No redundant or extraneous information is included.

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 status check, the description covers the essential purpose and failure behavior. However, it does not specify what success returns (e.g., success status or token validity), which is a minor gap for a health-check tool.

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

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

The tool has zero parameters, so parameter semantics are trivially satisfied. The empty schema and lack of parameters mean the description does not need to explain parameter meaning; baseline 4 is appropriate.

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

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

The description specifies a clear action ('check ScienceON connection/token status') and resource, distinguishing it from sibling tools like scienceON_search or scienceON_detail. It also mentions the failure response, adding purpose specificity.

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?

Usage is implied (checking status before or during interactions with ScienceON), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The name and description make the primary use case evident, but no direct guidance is provided.

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