Server Quality Checklist

Tool Scores

• kci_search_articlesB
  3.1/5.0
  Behavior2/5

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

  No annotations provided, so the description carries full burden. It only states 'retrieves basic information' without disclosing traits like pagination, rate limits, or read-only nature. The presence of 'displayCount' parameter implies pagination, but not explained.

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

  Conciseness5/5

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

  Single sentence that effectively communicates the tool's purpose and scope. No unnecessary words, front-loaded with action verb and target resource.

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

  Completeness3/5

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

  Adequate but incomplete: describes general functionality but lacks details on output format, pagination behavior, or handling of large result sets. For a search tool with 18 parameters, more contextual framing would help.

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

  Parameters3/5

  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 mentions key parameters (title, author, journal) but adds no new semantics beyond the schema definitions. No enrichment of meaning.

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

  Purpose4/5

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

  The description clearly states the tool's function: searching KCI-registered articles by various fields (title, author, journal) and retrieving basic info. It implies a search-and-list capability, distinguishing it from sibling tools like kci_get_article_detail which likely provides full details on a single article.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives. The description is generic and does not specify use cases, prerequisites, or exclusions, leaving the agent to infer context from sibling names.

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

• kci_search_referencesB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the operation is read-only, destructive, or has side effects. Also missing are details on pagination, rate limits, or any constraints beyond the input schema. The description only states what the tool does, not its behavioral characteristics.

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

  Conciseness4/5

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

  The description is a single, well-formed sentence that covers the essential purpose. It is front-loaded and avoids unnecessary verbosity. However, it could be slightly improved by adding structure (e.g., separating search criteria from output description) without increasing length significantly.

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

  Completeness2/5

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

  Given the tool has 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination behavior, or how results correspond to input parameters. A more complete description would provide an overview of the response structure and any limitations.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds context that parameters are used to search for papers whose references are retrieved, but it does not provide additional semantics beyond what the schema descriptions already specify (e.g., format constraints, default values). Thus, it meets the baseline without significant added value.

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

  Purpose5/5

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

  The description clearly states the tool's action ('조회합니다' - retrieves) and resource ('참고문헌 목록' - reference list) with specific search criteria (title, author, institution, year). It effectively distinguishes from sibling tools like kci_search_articles (which searches articles) and kci_get_citation_detail (which gets citation details).

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. While the purpose implies its use for retrieving references, there is no mention of when not to use it, prerequisites, or comparison with sibling tools. This lack of contextual guidance reduces its helpfulness for an AI agent deciding between tools.

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

• kci_get_journal_citationsA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or permissions. It only states what the tool retrieves, leaving behavior largely unspecified.

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

  Conciseness5/5

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

  The description is a single concise sentence in Korean. It front-loads the key parameters and purpose without any redundant or unclear phrasing.

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

  Completeness3/5

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

  The description mentions examples of returned data but does not explain pagination, sorting, or other parameters' roles. For a tool with 11 parameters and no output schema, more detail would improve completeness.

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

  Parameters4/5

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

  Schema description coverage is 100%, so baseline is 3. The description adds value by listing specific citation indices (영향력 지수, 즉시성 지수, 자기인용 비율 등) that are returned, which is beyond what input schema provides.

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

  Purpose5/5

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

  The description clearly states the tool retrieves citation indices (impact factor, immediacy index, self-citation rate) for journals based on year and years. It distinguishes from sibling tools which focus on article details, citation details, or search.

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

  Usage Guidelines3/5

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

  The description implies use when needing journal citation indices by year range, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No usage guidance beyond implied context.

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

• kci_get_citation_detailA
  4/5.0
  Behavior4/5

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

  With no annotations, the description bears full burden. It clearly states this is a read-only retrieval operation (상세 조회) and lists the types of data returned. It does not mention side effects, authentication, or rate limits, but the absence is acceptable for a simple read tool. The disclosure of return content is sufficient.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the core action and then lists specific data categories. Every word adds value, and there is no redundant or off-topic content. It is highly efficient.

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

  Completeness4/5

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

  The description covers the input (control number) and enumerates the types of output (registration, institution, change history, citation history). Given the simple schema (1 parameter, no output schema), this is largely complete. Lacking only is mention of output format or potential errors, which are minor omissions.

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

  Parameters3/5

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

  The input schema already provides a description for the only parameter (id: control number). The tool description merely restates 'journal control number' without adding new semantics, format constraints, or examples. Since schema coverage is 100%, a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description specifies the verb (상세 조회, retrieve detailed information), the resource (저널/학술지, journal), and the method (by 제어번호, control number). It lists specific data types (registration info, citation history) that clearly differentiate it from sibling tools like kci_get_article_detail or kci_get_journal_citations.

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

  Usage Guidelines3/5

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

  The description implies usage when the user has a journal control number and needs detailed citation and registration data. However, it does not provide explicit guidance on when not to use it or how it compares to siblings (e.g., ‘for article-level data, use kci_get_article_detail’). The context is clear but lacks exclusions.

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

• kci_get_article_detailA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully compensates by stating that it reads data (조회) and listing returned fields like author affiliations, URL, DOI, etc. There is 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.

  Conciseness5/5

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

  Two concise sentences that front-load the purpose, provide a concrete example, and explain how to obtain the required input. No wasted words.

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

  Completeness5/5

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

  Given the simple single-parameter tool and no output schema, the description fully covers the needed context: what the input is, how to get it, and what information will be returned.

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

  Parameters5/5

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

  The description adds significant meaning beyond the schema: it explains the parameter as 'KCI 논문 제어번호' with an example, and crucially tells the agent that the value should come from another tool's result. Schema coverage is 100% but the description enriches it.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: retrieve article details from KCI using a control number, listing specific fields. It differentiates from siblings by specifying the input (control number) and output (detailed info), and explains the relationship with kci_search_articles.

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

  Usage Guidelines4/5

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

  The description explicitly indicates when to use the tool (after obtaining a control number from kci_search_articles) and provides context for the input. However, it does not explicitly state when not to use it or mention alternatives.

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