get_similar_articles

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it uses NCBI eLink service, automatically filters for recent 5-year articles, batches retrieval of detailed information, and includes complete error handling. It also mentions that the 'email' parameter can provide higher API access limits. However, it does not specify rate limits, authentication requirements beyond the optional email, or potential costs/quotas.

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 sections (功能说明, 参数说明, 返回值说明, 使用场景, 技术特点), making it easy to scan. It is appropriately sized for a tool with 3 parameters and detailed output. However, some redundancy exists (e.g., '批量获取详细信息' appears in both 功能说明 and 技术特点), and the 返回值说明 section is lengthy but necessary given the output schema's existence.

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 (algorithm-based similarity search), no annotations, and an output schema (which covers return values), the description is complete. It explains the purpose, parameters, usage scenarios, technical characteristics, and behavioral aspects. The output schema handles return value details, so the description appropriately focuses on operational context without redundancy.

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 fully compensate. The '参数说明' (Parameter explanation) section provides detailed semantics for all three parameters: 'doi' is required and defined as a Digital Object Identifier with an example; 'email' is optional and explained as providing higher API access limits; 'max_results' is optional with a default of 20. This adds comprehensive meaning beyond the bare schema.

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: '根据DOI获取相似文章（基于PubMed相关文章算法）' (Get similar articles based on DOI using PubMed's related articles algorithm). It specifies the verb ('获取' - get/fetch), resource ('相似文章' - similar articles), and method ('基于PubMed相关文章算法' - based on PubMed's related articles algorithm), distinguishing it from siblings like 'get_article_details' or 'search_europe_pmc' which serve different functions.

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 '使用场景' (Usage scenarios) section lists four specific contexts: literature review research, finding related studies, academic investigation, and related work analysis. This provides clear guidance on when to use the tool. However, it does not explicitly mention when NOT to use it or name alternatives among sibling tools, such as 'search_europe_pmc' for broader searches.

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