Server Quality Checklist

Tool Scores

• get_literature_relationsA
  4/5.0
  Behavior4/5

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

  The description details relation types and analysis modes, adding behavioral context beyond the readOnlyHint annotation. However, it does not mention potential rate limits or data volume implications for network analysis.

  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 well-structured with clear sections (purpose, relation types, parameters, analysis modes). While it is somewhat long, it is front-loaded with essential information. A few sentences could be tightened, but overall it is efficient.

  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?

  Given the complexity (8 parameters, no output schema), the description covers most aspects but misses the return format or examples of output. The analysis modes and parameter details are good, but the missing 'sources' parameter and lack of output documentation leave gaps.

  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?

  With 0% schema description coverage, the description explains most parameters (identifiers, id_type, relation_types, max_results, analysis_type, max_depth) but omits 'sources' and does not clarify the dual 'identifier'/'identifiers' fields. The parameter explanations are helpful but incomplete.

  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 it analyzes citation relationships, referencing, similar, and citing papers. It uses specific verbs ('分析') and resources ('文献关系'), and distinguishes itself from siblings like 'get_references' by offering multiple relation types and analysis modes.

  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 provides implicit usage guidance through analysis modes (single, batch, network) and parameter combinations, but does not explicitly compare with sibling tools or state when not to use it. The three analysis modes help the agent decide based on input cardinality.

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

• get_journal_qualityA
  4.2/5.0
  Behavior4/5

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

  The description discloses key behaviors: integration of EasyScholar and OpenAlex data sources, 24-hour cache via 'use_cache', and sorting constraints ('仅批量查询有效'). These details add value beyond annotations that already indicate read-only.

  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 well-organized with bullet points for metrics and parameters, front-loaded with purpose. It is slightly verbose with repeated '仅批量查询有效' but each section earns its place.

  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?

  For a multi-source, multi-parameter tool with no output schema, the description covers data sources, metrics, parameters, and usage examples. Missing details on error handling or data source fallback, but overall sufficient for effective use.

  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?

  With 0% schema description coverage, the description compensates fully by explaining each parameter: 'journal_name' supports single/list, 'include_metrics' lists default metrics, 'sort_by'/'sort_order' note batch-only validity. It provides defaults and constraints not in the schema.

  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 '评估期刊的学术质量和影响力指标' (evaluates journal academic quality and impact metrics), specifying it uses dual data sources. It distinguishes itself from sibling tools like 'get_article_details' by focusing exclusively on journal-level metrics.

  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 provides usage examples (single/batch queries) and parameter guidance but lacks explicit when-to-use or comparison with alternatives. It does not explain when to prefer this tool over siblings like 'search_literature'.

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

• get_referencesA
  4.3/5.0
  Behavior4/5

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

  Adds dedup rules and data source priorities beyond annotations (readOnlyHint=true). Discloses behavioral traits like '智能去重' (smart dedup) but doesn't cover all behaviors (e.g., pagination).

  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?

  Concise yet comprehensive: one sentence for purpose, bulleted parameter list, and notes on data sources and dedup. No filler, every sentence adds value.

  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?

  Covers parameters and behavioral rules well, but lacks description of return format or example. For a reference-listing tool without output schema, a brief note on output structure would improve completeness.

  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?

  With 0% schema description coverage, the description fully explains each parameter: identifier types, id_type enum, sources defaults, max_results range, include_metadata purpose. Adds meaning beyond the plain schema.

  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?

  Description clearly states '获取参考文献工具' (get references tool) and specifies it retrieves references for a given identifier with dedup. It is distinct from siblings like get_article_details or search_literature.

  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?

  Implied usage through parameter descriptions, but no explicit when-to-use or when-not-to-use compared to siblings. The dedup rules and data sources provide context but not direct alternatives.

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

• get_article_detailsA
  4.9/5.0
  Behavior5/5

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

  The description extensively covers behavioral aspects: data source (Europe PMC + PMC), return fields, batch structure with stats, format conversion, and section extraction. Annotations indicate readOnlyHint=true, and the description confirms read-only behavior, with no contradictions.

  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 well-structured with clear sections (prerequisites, parameters, data source, return structure, supported sections) and front-loaded purpose. Though verbose, every part serves a purpose; a slight reduction in redundancy could improve conciseness.

  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 no output schema and limited schema descriptions, the description provides complete context: prerequisites, parameter semantics, return structure example, supported sections, and batch statistics. It also references the sibling search_literature tool for alternative scenarios.

  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?

  With 0% schema description coverage, the description fully compensates by explaining each parameter in detail: pmcid (required, can be list, max 20), sections (acceptable values and mapping), format (options with recommendations). It adds meaning well beyond the schema.

  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 it is a tool for retrieving full text of literature using PMCID. It distinguishes itself from sibling tools by specifying that if only keywords or title are available, the search_literature tool should be used first.

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

  Usage Guidelines5/5

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

  The description explicitly provides usage guidance: use when you have a PMCID, otherwise use the search_literature tool. It also details batch mode limits and parameter behavior (e.g., sections defaulting to None for full text).

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

• search_literatureA
  5/5.0
  Behavior5/5

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

  Annotations include readOnlyHint=true, and the description reinforces that this tool is read-only and returns only metadata (no full text). It also discloses caching behavior (24-hour cache via use_cache parameter). There is no contradiction between description and annotations.

  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 well-organized with bullet points and sections. The first sentence states the primary purpose, followed by a warning, search strategies, and parameter details. Every sentence is informative, with no redundancy or filler.

  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?

  The tool has 5 parameters (1 required) and no output schema, but the description covers all aspects: input parameters with defaults, return values (titles, authors, abstract, PMCID, DOI, etc.), and behavioral notes (caching, metadata-only). This is complete for an agent to use correctly.

  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?

  Despite 0% schema description coverage, the description thoroughly explains each parameter: keyword (required), sources (optional, auto-selected), max_results (default 10), search_type (with enum values and explanations), and use_cache (default true). This adds significant meaning beyond the schema.

  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: '多源文献搜索工具。用于查找文献并获取 PMCID.' It specifies the resource (literature) and action (search), and distinguishes from siblings like get_article_details by focusing on searching and returning metadata.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool vs alternatives: it returns only metadata; for full text, users should use the '文献全文' tool with the returned pmcid. It also details search strategies (comprehensive, fast, precise, preprint) with explanations, helping the agent choose appropriately.

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