pubmed_related_article_search_by_pmid

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

With no annotations, the description carries the full burden. It discloses that the source PMID is excluded, that results are ranked by relevance, and that the underlying service is NCBI ELink. It does not mention error behavior, rate limits, or how max_results affects the response, which are important for a read-only network call. The provided details are useful but not exhaustive.

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 two-sentence description is tightly written with no filler. The first sentence front-loads the core purpose and the second sentence adds a practical follow-up instruction. Every clause contributes value, matching the conciseness ideal.

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 simple 2-parameter interface and no output schema, the description explains the return value (list of PMIDs, source excluded) and suggests a follow-up, which is helpful. Yet it omits the semantics of max_results and does not cover potential edge cases like invalid PMIDs or empty result sets, leaving a meaningful gap for an agent that must invoke the tool autonomously.

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 for both parameters. It makes no mention of max_results' meaning or default (10) beyond the schema default, and it only implicitly ties pmid to the primary input. The description's 'related PMIDs' phrasing hints at the output but does not clarify parameter semantics, leaving an agent with inferential gaps.

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 a specific action ('find PubMed articles topically related to a given PMID') and the underlying ELink mechanism, which distinguishes it from search-by-query tools. It also clarifies that the output is a list of related PMIDs, not full records, and suggests a follow-up tool. However, it does not explicitly contrast with pubmed_paper_search_by_query, so an agent must infer the intended use case from the PMID-based input.

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 when you already have a known PMID and want similar articles, and it gives an actionable next step ('Call pubmed_paper_summary_lookup_by_pmids'). It does not explicitly state when to avoid this tool or when to prefer a sibling like pubmed_paper_search_by_query, leaving some inference to the agent.

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