pubmed-search-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.16
Disambiguation2/5
Many tools have overlapping purposes, such as multiple search tools (unified_search, search_biomedical_images, search_clinvar, etc.) and multiple citation exploration tools (find_citing_articles, get_article_references, find_related_articles, build_citation_tree). Agents may struggle to choose the correct tool for a given task.
Naming Consistency4/5
Most tool names follow a consistent verb_noun pattern (e.g., fetch_article_details, build_citation_tree, configure_institutional_access). However, 'unified_search' is an adjective-verb hybrid, and a few names like 'get_text_mined_terms' have slightly awkward phrasing. Overall, the pattern is clear and predictable.
Tool Count3/5
With 46 tools, the server is feature-rich but borders on being overwhelming. While each tool serves a specific purpose, many utilities (pipeline management, session management, institutional access diagnostics) could be consolidated, making the set feel bloated for a typical literature search use case.
Completeness4/5
The tool surface covers a wide range of literature search needs: search, retrieval, fulltext, figures, citations, metrics, export, pipelines, session management, gene/compound lookup, and more. Minor gaps exist (e.g., no dedicated systematic review export), but the server is generally comprehensive.
Average 4.3/5 across 46 of 46 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 74 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It lists actions but does not state if reads are idempotent, whether session data is persisted, what happens on missing session, or any error conditions. Lacks details on permissions or side effects.
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 moderately sized, with a clear bullet list of actions and a short instructional paragraph. It is front-loaded with the main purpose. No redundant sentences, though it could be slightly more concise.
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 16 parameters and no parameter descriptions in the schema, the description is incomplete. It fails to explain many parameters and does not describe the return structure despite an output schema existing. The facade nature demands more thorough documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 a few parameters (artifact_file, offset, max_chars, artifact_tool, artifact_kind, include_local_paths) but leaves many undocumented (pmid, artifact_id, artifact_uri, session_id, search_index, query_filter, include_history, history_limit, event_limit). The description adds some meaning but is insufficient.
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 states it reads session data via a facade and lists specific actions (pmids, article, summary, list_artifacts, artifact). This clearly defines the tool's scope. However, it does not explicitly differentiate from sibling tools like get_session_summary or get_cached_article, which might overlap.
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 some usage guidance, e.g., using artifact_file with offset/max_chars for paging, and filtering list_artifacts by artifact_tool/artifact_kind. However, it does not specify when to prefer this facade over individual sibling tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, requiring the description to fully disclose behavioral traits. However, it only lists what statistics are covered (type distribution, temporal patterns, etc.) and omits operational details such as auth requirements, rate limits, or side effects. The description does not mention if the analysis is read-only or involves any mutations.
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 moderately concise, starting with a clear summary sentence, followed by a bullet list of outputs, an Args section, Returns, and an example. It is well-structured but could be slightly more concise by removing the explicit 'Args' and 'Returns' labels if already implied by the format.
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 that the tool has only 2 parameters (one required), no enums, and an output schema exists, the description need not detail return values. However, it lacks usage guidelines and behavioral transparency, which are gaps for completeness. It adequately covers the parameter semantics and purpose.
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 coverage is 0%, but the description includes an Args section that explains each parameter: 'Research topic to analyze' for topic and 'Maximum articles to analyze' for max_results. This adds meaningful context beyond the bare schema, compensating well for the lack of schema descriptions.
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 analyzes milestone distribution for a research topic, with a specific verb and resource. It distinguishes from siblings like build_research_timeline and compare_timelines by focusing on analysis rather than construction or comparison.
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 for analyzing milestones but provides no explicit guidance on when to use this tool versus alternatives (e.g., build_research_timeline or compare_timelines). No exclusion criteria or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the basic function and parameter formats. It does not mention authentication, rate limits, or the nature of 'detailed information' returned. The output_format parameter is not explained in the description.
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 concise, with a clear opening sentence, a well-organized list of pmids formats, and a short return statement. Every sentence adds value, and the structure is front-loaded. No unnecessary elaboration.
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?
Given the presence of an output schema and two parameters, the description covers the complex pmids parameter thoroughly but omits explanation of output_format and what 'detailed information' entails. Still, it is sufficient for basic usage.
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?
The schema has 0% description coverage. The description adds significant meaning for the pmids parameter by listing multiple accepted formats (string, list, integer, prefix). However, it does not describe the output_format parameter beyond what the schema provides via enum. This imbalance still adds substantial value overall.
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 verb 'fetch' and resource 'detailed information for one or more PubMed articles.' It specifies that it handles multiple PMIDs, distinguishing it from siblings like get_fulltext (for full text) or get_article_figures (for figures). The purpose is unambiguous.
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 like get_cached_article or get_fulltext. The description implies it is for general article details, but does not state when not to use it or name sibling tools for specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the tool deletes a pipeline and its execution history, but omits critical details such as irreversibility, required permissions, impact on related data, or confirmation steps. This is insufficient for a destructive operation.
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 extremely concise at three lines, front-loaded with the main action. Every sentence is necessary: purpose, parameter argument, and return value. No redundancy or extraneous text.
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 simple one-parameter tool with an output schema, the description covers the essential aspects: action, input, and return. However, it could improve by noting permanence or confirmation behavior, especially given the lack of annotations. Overall, it is nearly complete.
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 includes an Args section that fully explains the single required parameter 'name' as 'Name of the saved pipeline to delete.' Despite the schema coverage signal being 0%, the parameter is clearly documented within the description, adding complete 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 explicitly states 'Delete a saved pipeline configuration and its execution history,' providing a specific verb and resource. The name itself is unambiguous, and it clearly distinguishes from sibling tools like list_pipelines, save_pipeline, and load_pipeline.
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 offers no guidance on when to use this tool versus alternatives, such as manage_pipeline or schedule_pipeline. It does not specify prerequisites or when not to use it, leaving the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 tool returns a list of entities with counts and sections, and explains parameter behaviors (e.g., accepted formats for IDs). However, it does not mention potential limitations (e.g., article accessibility, rate limits) or side effects.
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 a summary line, an Args section, and Returns. It is clear and informative, though slightly long. Every sentence serves a purpose, and the formatting aids readability.
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 no annotation coverage, the description covers the tool's purpose, main parameters, and return type. However, it omits the output_format parameter and does not mention pagination or data volume. The presence of an output schema partially mitigates the need for return format details, but the missing parameter is a gap.
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 0%, so the description must compensate. It adds detailed semantics for pmid, pmcid, and semantic_type, including accepted formats and options. However, it fails to document the output_format parameter, which has an enum (markdown, json, toon) in the schema but is completely omitted from the description.
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 states the tool 'gets text-mined annotations from Europe PMC' and lists specific entity types (genes, diseases, chemicals, organisms), clearly distinguishing it from sibling tools that fetch article details or gene-specific data.
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 mentions it is 'useful for identifying key concepts', implying a usage context, but does not provide explicit guidance on when to use this tool versus alternatives like get_gene_details or fetch_article_details. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool is for searching PubChem (implying read-only) and returns JSON with compound records, but lacks details on error handling, rate limits, or behavior when no results are found.
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 a main sentence, a use cases section, and argument/return descriptions. However, the separator line and repeated 'Args:'/ 'Returns:' formatting add minor redundancy.
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?
For a simple search tool with an output schema, the description provides the essential return structure but does not cover pagination, error scenarios, or edge cases, which is notable given the lack of annotations.
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 0%, so the description must compensate. It explains 'query: Compound name or description' and 'limit: Maximum results (1-50),' adding meaning beyond the schema's bare titles and types, though it omits the default value of 10.
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 'Search PubChem for chemical compounds,' specifying the verb ('Search') and the resource ('PubChem for chemical compounds'), which distinguishes it from sibling tools like 'get_compound_details' that likely retrieve specific compound details.
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 lists use cases (e.g., 'Look up drug/compound information') but does not explicitly guide when to use this tool versus alternatives like 'unified_search' or 'get_compound_literature,' nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It mentions that the tool returns a 'Comparative analysis' but does not specify whether the tool is read-only, what side effects exist, or any authentication or rate limit requirements. This lack of transparency is a notable gap.
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 (description, useful for, args, returns, example). It is concise and avoids redundancy, though the bullet list could be tighter. Every sentence contributes 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?
Given that an output schema exists, the description does not need to detail return values. It provides sufficient context for the two parameters and an example. However, it could mention the type of output (e.g., comparison table) to further aid the agent.
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?
The input schema has 0% description coverage, but the description compensates by explaining the 'topics' parameter as 'Comma-separated topics to compare' with an example, and 'max_events_per_topic' as 'Maximum events per topic'. This adds meaning beyond the schema's basic type info.
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 'Compare research timelines of multiple topics' and provides specific examples like comparing drug development timelines. This verb+resource combination is precise and distinguishes the tool from siblings such as 'build_research_timeline' and 'analyze_timeline_milestones'.
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 includes a 'Useful for' section listing concrete scenarios (e.g., comparing drug development timelines). While it does not explicitly state when not to use the tool or name alternative tools, the context is clear enough for an AI agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the main behavior (extracting figures, returning metadata) and optional features (include_subfigures, include_tables). Does not explicitly state read-only nature or disclose potential limitations (e.g., rate limits, article access restrictions). Since no annotations are present, more transparency would be beneficial.
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?
Well-structured with a concise summary, parameter details, return description, and examples. No redundant information; each sentence adds value. Front-loaded with the core purpose.
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 main functionality, parameter flexibility, and return structure. Lacks explanation for the output_format parameter and any error conditions or limitations (e.g., network requirements). Given the 6 parameters and no annotations, it is near-complete but has minor 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?
Adds meaning for identifier (auto-detect), pmcid (direct ID), pmid (PMC requirement), and boolean parameters (include_subfigures, include_tables). However, output_format is not explained in the description despite being present in the schema. With 0% schema coverage, the description should cover all parameters.
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 gets structured figure metadata and PDF links from a PMC Open Access article, specifying the returned elements (label, caption, image URL). This distinctly separates it from sibling tools like get_fulltext or analyze_figure_for_search.
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?
Provides clear input options (identifier, pmcid, pmid) with prerequisites for pmid (article must be in PMC). Lacks explicit when-not-to-use guidance or comparison to alternatives like get_fulltext.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states it returns compound details (formula, SMILES, properties), which implies a read operation. However, it does not disclose any potential side effects, authentication needs, rate limits, or behavior on invalid CIDs. Given no annotations, the description carries the full burden but is minimal.
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 brief: a one-sentence purpose followed by a clear Args/Returns block. No redundant words, all sentences add value. Front-loaded with the main action.
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 tool is simple with one parameter. The description covers input (cid) and output (JSON with formula, SMILES, properties). It mentions an output schema implicitly. For a straightforward lookup, this is mostly sufficient, though it lacks details on error cases or exact JSON structure. Still, adequate given tool simplicity.
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?
The schema has one parameter 'cid' with only type (string or integer) and title, and 0% schema description coverage. The description adds 'PubChem Compound ID', clarifying what the parameter represents. This adds significant meaning beyond the schema, compensating for the lack of parameter description.
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 'Get detailed information about a compound by PubChem CID', specifying the verb 'get', resource 'compound', and identifier 'PubChem CID'. This clearly distinguishes it from sibling tools like search_compound (for searching by name) and get_compound_literature (for literature), which have different purposes.
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 when to use (when you have a CID and want details), but it does not explicitly mention when not to use or suggest alternatives among the many sibling tools (e.g., search_compound for name-based lookup, get_compound_literature for publications). Adequate but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions using NCBI's curated links and the limit range (1-100), but lacks details on error handling, rate limits, or whether the operation is read-only. The basic safety profile is implied but not explicitly stated.
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 concise: three sentences for the main purpose, followed by brief parameter and return descriptions. No wasted words, and the key information is front-loaded.
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?
Given the tool's simplicity (2 params, output schema exists), the description sufficiently explains inputs, outputs, and behavior. It lacks mention of pagination or potential API limitations but is adequate for a straightforward literature retrieval tool.
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 coverage is 0%, so the description compensates by explaining 'cid' as 'PubChem Compound ID' and 'limit' as 'Maximum PubMed IDs to return (1-100).' This adds significant meaning beyond the schema, though the default value (20) from the schema is not mentioned in the description.
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 'Get PubMed articles linked to a compound,' with a specific verb and resource. It distinguishes from siblings like 'get_gene_literature' (which targets genes) and 'get_compound_details' (which gets compound information, not 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?
The description implies usage for retrieving compound-linked PubMed articles but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_gene_literature) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It lists actions and parameters but omits important details such as permission requirements, side effects of each action, error handling, or irreversibility (e.g., delete is irreversible but not highlighted). The return is described vaguely as 'human-readable responses', which lacks specificity.
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 a high-level overview, a bullet list of actions, and a parameter list. It avoids redundancy but is slightly lengthy. The information is front-loaded with the purpose, and each sentence contributes value. Minor conciseness improvements could be made.
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?
Given the tool's complexity (12 parameters, multiple actions) and the presence of an output schema, the description covers most essential aspects: actions, parameters, and return type. However, it lacks explicit conditional requirements (e.g., which parameters are required for which action) and does not document error states or validation rules, leaving some gaps for an agent.
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 input schema has 0% description coverage, so the description must fully explain each parameter. It does so effectively: each parameter in the Args section includes a brief description and, where applicable, example values (e.g., source: 'saved:weekly_search' or 'file:path/to/pipeline.yaml'). This adds significant meaning beyond the bare 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 'Manage saved pipelines through a single facade' and then enumerates the specific actions (save, list, load, delete, history, schedule). This provides a precise verb+resource definition and distinguishes it from sibling tools that handle individual actions.
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?
While the description implicitly presents itself as a unified interface, it does not explicitly guide when to use this facade versus the individual sibling tools (e.g., save_pipeline, delete_pipeline). There is no 'when-not' or alternative selection advice, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format (JSON with symbol, name, summary, location) but does not discuss side effects, permissions, or rate limits. Given the absence of annotations, it provides basic behavioral context but not deep transparency.
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 concise, with two effective sentences plus clearly labeled Args and Returns sections. Every part serves a purpose with no unnecessary text.
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 tool's single parameter and the existence of an output schema, the description provides complete context for a retrieval tool: what it does, what input it needs, and what output to expect.
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?
The description adds meaningful interpretation to the sole parameter 'gene_id' by specifying it is an 'NCBI Gene ID' and suggesting its source ('from search results or known'). This compensates for the 0% schema description coverage.
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 action ('Get detailed information'), resource ('a gene'), and method ('by NCBI Gene ID'), making it distinct from sibling tools like search_gene and get_gene_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?
The description implies usage context ('from search results or known') but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully discloses the tool's behavior: it is read-only ('without executing the search') and returns a detailed analysis including complexity, intent, PICO elements, recommended sources, and strategies. No hidden side effects are implied.
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 concise and well-structured: a terse first sentence states the purpose, a second sentence provides context, and then it methodically lists the parameter and return values. Every sentence adds value without redundancy.
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?
Given the tool's simplicity (one parameter, output schema exists), the description covers the essential aspects: purpose, usage context, return details. It does not mention error conditions or edge cases, but for a straightforward analysis tool, it is sufficiently complete.
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 adds a minimal but necessary explanation for the 'query' parameter: 'The search query to analyze.' This is sufficient for a single parameter but lacks detail on formatting or constraints, earning a baseline score of 3.
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 function: analyzing a search query without executing it. It explicitly contrasts with unified_search, a sibling tool that executes searches, making the purpose highly specific and distinguishable.
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 a clear use case: 'useful for understanding how unified_search will process your query before actually running it.' This tells the agent when to use this tool (as a preliminary step before unified_search), though it does not list alternatives or when to avoid usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the data source (NCBI curated links) and return format (JSON with PubMed IDs). It also notes the limit parameter range. However, it omits details like authentication or rate limits.
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 very concise, front-loading the purpose in the first line, using efficient formatting for args and returns, and no superfluous text.
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?
Given the tool's simplicity and the presence of an output schema, the description is sufficiently complete, covering input, output, and data source. Minor gaps exist (e.g., no mention of error handling), but overall adequate.
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?
Despite 0% schema coverage, the description explains both parameters: gene_id as NCBI Gene ID and limit with a range (1-100), adding value beyond the schema's type definitions.
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 gets PubMed articles linked to a gene, specifying the resource and action. It distinguishes from siblings like get_compound_literature or get_gene_details by focusing on curated gene-publication links.
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 mentions it uses NCBI's curated links and is 'more precise than keyword searches', implying a use case, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description clearly indicates a read operation (get execution history) and explains it provides diff analysis. It lists parameters and a returns summary. However, it does not mention any side effects, required permissions, rate limits, or error cases, which would make it fully transparent.
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 very concise: a two-line summary followed by structured Args/Returns sections. Every sentence adds value (purpose, diff analysis, parameter explanations, return fields). No redundant or irrelevant information.
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?
Given sibling tools (list_pipelines, manage_pipeline, etc.), the description clearly defines this tool's role: historical execution data with diff analysis. An output schema exists (indicated by context signals), and the description lists key return fields. However, it does not explain how 'diff analysis' determines new/removed articles, which could be helpful for an agent deciding between tools.
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 0%, so the description must compensate. It explicitly describes both parameters: 'name' as the pipeline name and 'limit' with its default value of 5. This adds meaning beyond the type and required fields, though it could clarify if 'limit' is a strict maximum or optional.
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 begins with a clear action and resource: 'Get execution history for a saved pipeline.' It further specifies the unique value of 'diff analysis' (new/removed articles), which distinguishes it from sibling tools like list_pipelines, manage_pipeline, or delete_pipeline.
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 for viewing history with diff analysis, but does not explicitly state when to use this tool versus alternatives. For example, it doesn't mention that list_pipelines only lists names, not history, or that manage_pipeline is for editing. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that scheduling stores diff_mode and notify preferences, and returns confirmation/removal result. However, it doesn't mention overwriting behavior or prerequisites like pipeline existence.
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 uses a clear structured docstring with Args and Returns. Every sentence adds value, no fluff.
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?
With 4 parameters, 1 required, and an output schema, the description covers arguments and return behavior. It does not detail output schema structure or error conditions, but is adequate for a scheduling tool.
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 0%, so description must explain parameters. It explains each parameter: name, cron (with example), diff_mode, notify. This adds 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 states 'Schedule a saved pipeline for periodic execution', which is a specific verb+resource. It clearly distinguishes from siblings like delete_pipeline, list_pipelines, etc.
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 guidance on cron expression format with an example and notes that an empty string removes the schedule. It doesn't explicitly state when to use vs alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes the return format as 'JSON with gene records including symbols, names, locations' and specifies argument details like limit range (1-50). However, it does not disclose potential rate limits or behavior when no results are found, but for a search tool, this is acceptable.
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 front-loaded with the core purpose sentence. It uses a clear structure with 'USE CASES', 'Args', and 'Returns' sections. Every sentence adds value without unnecessary verbosity.
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?
Given that an output schema exists (reducing the need to detail return values), the description adequately covers use cases, parameter explanations, and overall behavior. Minor gaps like pagination or error handling are not critical for a search tool of moderate complexity.
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 0%, so the description must compensate. It adds meaning by explaining query as 'Gene name, symbol, or function keyword', organism with examples ('human', 'Homo sapiens', 'mouse'), and limit as 'Maximum results (1-50)'. This provides useful context beyond the schema's bare types.
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 states 'Search NCBI Gene database for gene information' with a clear verb and resource. Use cases list specific actions like looking up gene function, aliases, and location, which distinguishes it from siblings like get_gene_details (which is for retrieving details of a known gene).
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 a list of use cases that imply when to use the tool, but it does not explicitly compare against alternatives or state when not to use it. For example, it does not mention that get_gene_details should be used for a specific known gene symbol rather than searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It transparently explains each probe's behavior, including IP-awareness, cookie requirements, and environment variables. It does not mention side effects, but as a diagnostic tool, it is largely 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-structured with numbered probes and bullet points for environment variables. It is appropriately detailed for the complexity, but could be slightly more concise without losing clarity.
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 availability of an output schema, the description sufficiently explains the return format (Markdown report with status, classification, advice). All four parameters are explained, and the three probes cover the main functionality. The description is complete for a diagnostic tool with no nested objects.
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?
Schema description coverage is 0%, so the description must compensate. It provides detailed meaning for each parameter (pmid for OpenURL enrichment, doi as required for probes, try_direct/try_ezproxy with defaults and purpose), adding semantic constraints 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 diagnoses institutional fulltext access success/failure, with a specific verb and resource. It lists three probes, distinguishing it from sibling tools like 'test_institutional_access' by focusing on multi-probe diagnosis.
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 when to use (troubleshooting access) and describes each probe's conditions, but does not explicitly contrast with alternatives like 'test_institutional_access' or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the multi-source retrieval order, browser-session fallback, and return format. However, it omits potential rate limits or failure scenarios.
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?
Well-structured with clear sections and examples, but slightly verbose with some redundancy. Front-loaded with purpose, but could be trimmed.
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?
Covers all 10 parameters, multiple source methods, output formats, and provides examples. Comprehensive for the tool's complexity.
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?
Schema has 0% description coverage; the description fully explains each parameter with examples and purpose, adding essential 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 'Enhanced multi-source fulltext retrieval' and lists multiple sources, distinguishing it from siblings like fetch_article_details or get_cached_article. It provides specific verb+resource and examples.
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 explains flexible input and extended_sources but does not explicitly tell when to use this tool versus alternatives. It lacks exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool generates an OpenURL link and returns a link or error message. It does not mention side effects or authentication details beyond the prerequisite, but for a link generator, this is adequate.
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 headers, prerequisites, and examples, making it easy to parse. While slightly verbose, every sentence adds value and the organization compensates for length.
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?
Given the complexity (8 optional parameters, no annotations), the description covers the purpose, prerequisites, parameter usage, and return type. It does not detail the output schema, but since one exists, this is acceptable.
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 0%, so the description must compensate. It lists all 8 parameters with brief explanations and groups them into usage patterns (PMID, DOI, full metadata), adding meaning beyond the bare 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 function: 'Generate institutional access link (OpenURL) for an article.' It uses a specific verb ('generate') and resource ('institutional link/OpenURL'), and is distinct from sibling tools like configure_institutional_access.
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 includes explicit prerequisites (must call configure_institutional_access first) and provides clear usage examples with different parameter combinations. It does not explicitly state when not to use this tool, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adequately explains the read-only nature and parameter effects. It does not discuss auth or rate limits, but these are less critical for a logging tool.
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?
Description is concise with a clear front-loaded purpose. Every sentence adds value, and the Args/Returns format is clean and well-structured.
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 presence of an output schema, the description sufficiently covers purpose, parameters, and usage. No missing information for the tool's complexity.
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 0%, so description must compensate. It lists all four parameters with defaults and brief descriptions. However, 'kind' lacks possible values, and 'history_limit' context is minimal. Adequate but not exhaustive.
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 'activity log' and 'search history summary' for the current session. It uses specific verbs and resources, distinguishing it from siblings like 'get_session_summary'.
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?
Explicitly mentions suitable scenarios: reviewing recent searches, cache changes, and debugging. However, it does not specify when not to use it or provide direct comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool returns summary data without indicating side effects or permissions. While it explains parameters and examples, it lacks explicit confirmation that the tool is read-only, error conditions, or rate limits, which are expected for a data retrieval tool.
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 a purpose statement, Args, Returns, and Examples. It is slightly redundant (purpose and Returns overlap), but the front-loaded key information and clear sections make it easy to parse.
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 tool's low complexity (2 optional parameters) and the presence of an output schema, the description adequately covers parameters, return values, and usage examples. It provides enough context for an agent to correctly invoke the tool without missing critical details.
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's Args section adds significant meaning beyond the input schema: it explains that include_history controls inclusion of full history, history_limit only applies when include_history is True, and provides defaults. This compensates fully for the 0% schema description coverage.
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 a summary of the current session, including cache status and search history, to help the agent understand available data. It distinguishes the tool from siblings like get_session_log or get_session_pmids by focusing on a concise summary rather than raw logs or IDs.
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 implies usage for understanding session state with examples showing typical calls. However, it does not explicitly specify when not to use this tool or mention alternatives like get_session_log for detailed history, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description does not explicitly state that the tool is read-only or has no side effects. Listing is inherently non-destructive, but explicit reassurance would improve transparency.
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 concise and front-loaded with the main purpose. Every sentence adds value: the one-line purpose, two parameter explanations, and a returns line. No redundant information.
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?
Given two optional parameters and an output schema (context indicates its existence), the description covers parameter behavior and expected return table. However, it does not specify default behavior (e.g., lists all pipelines if no filters) or mention pagination limits.
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 schema has 0% description coverage, but the description fully explains each parameter: tag for filtering by tag, scope for filtering by scope with valid values ('workspace', 'global', ''), and the effect of empty values ('show all'). This compensates completely.
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 'List all saved pipeline configurations.' The verb 'list' and resource 'saved pipeline configurations' are specific. It distinguishes from sibling tools like manage_pipeline or save_pipeline by focusing on listing.
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 clear filtering guidance with tag and scope parameters, explaining when to use each. However, it does not explicitly compare with alternative sibling tools (e.g., get_pipeline_history) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the return format (JSON with variant records including significance and conditions) and the limit range (1-50). This is sufficient for a read-only search tool, though it could mention pagination or error handling.
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 concise with a clear structure: title, use cases, arguments, and returns. Every sentence adds value, and the purpose is front-loaded.
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 simple tool with two parameters and an output schema, the description covers purpose, parameters, return, and use cases. It differentiates from siblings via 'ClinVar', though omits details about error responses or database scope.
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?
Schema description coverage is 0%, so the description must compensate. It explains query as 'Gene name, variant, or disease condition' and limit as 'Maximum results (1-50)', adding meaningful context beyond the schema's type and default.
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 'Search ClinVar for clinical variants,' specifying a specific verb and resource. It distinguishes from sibling tools like search_gene or search_compound by focusing on ClinVar, a distinct database for clinical variants.
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 lists relevant use cases (e.g., look up clinical significance, find variants associated with diseases) but does not explicitly contrast with siblings or provide exclusion criteria. It implies use for clinical variant information but lacks direct guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the OpenURL mechanism, the effect of enabling/disabling, and the result (status message). It does not contradict any annotations. It adds behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and headings, aiding readability. However, it is quite long with ASCII art and repeated formatting, which could be more concise. The main purpose is front-loaded.
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 four parameters (some optional) and the existence of an output schema (indicated by 'Returns: Configuration status message'), the description covers configuration options, preset lists, URL discovery, and the test parameter. It is complete and leaves no obvious gaps.
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: resolver_url (with URL format examples), preset (with list of presets), enable (default true), and test (compatibility flag, recommending alternative). This adds substantial meaning beyond the bare 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 configures institutional OpenURL link resolver for full-text access. It uses specific verb 'configure' and resource 'institutional access', and distinguishes from siblings like test_institutional_access and get_institutional_link.
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 three explicit usage options (preset, custom URL, disable) with examples and available presets. It also directs users to test_institutional_access for explicit testing. While it doesn't explicitly state when not to use, the alternatives are clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses bidirectional conversion, automatic ICD version detection, return format (JSON with result and PubMed query), and the constraint of providing only one parameter. It could mention error handling but covers key behaviors.
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 headings, examples, and explicit args. It is slightly lengthy but each section adds value. Good front-loading of purpose and clear formatting.
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?
Given the tool's complexity (bidirectional, two parameters) and that an output schema exists, the description covers inputs, behavior, and output format. It lacks error scenarios but is largely complete for a conversion tool.
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?
Schema description coverage is 0%, but the description adds extensive meaning: explains ICD-9/10 format, MeSH term examples, mutual exclusivity, and automatic version detection. It fully compensates for the lack of schema descriptions.
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 'Convert between ICD codes and MeSH terms (bidirectional)' with specific verb and resource. It distinguishes from siblings which are search and analysis tools, not conversion tools.
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 explains when to use 'code' vs 'mesh_term' with examples, and states they are mutually exclusive. It provides clear context but does not mention when not to use or alternative tools, which is acceptable for a specialized converter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the tool is a read operation from cache, non-destructive, and saves API quota. However, it does not specify behavior on cache miss (e.g., returns null or error), nor does it mention session dependency or any side effects. The description is adequate but not fully transparent.
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 extremely concise: two short sentences plus a parameter and return note. It front-loads the primary action and provides clear documentation without unnecessary words.
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 simple cache lookup tool with one parameter and an output schema (not shown), the description is mostly complete. It explains the benefit and usage context. It lacks explicit mention of cache miss behavior, but given the output schema likely defines the return type, this is a minor gap.
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?
The single parameter 'pmid' has 0% schema description coverage. The description adds meaning by stating 'pmid: PubMed ID', clarifying the parameter's purpose beyond the schema type. Though brief, it compensates for the schema gap.
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 '從 session 快取取得文章詳情' (get article details from session cache) and contrasts with fetch_article_details, defining the specific verb and resource. It distinguishes this tool from siblings by mentioning it is faster and does not consume NCBI API quota.
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 states when to use this tool: when you want faster retrieval without consuming NCBI API quota compared to fetch_article_details. It names the alternative tool and implies precedence over fetch_article_details for cached data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not mention whether the tool is read-only, idempotent, or has any side effects. It focuses on parameters and return format but lacks behavioral traits beyond that.
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-structured with a clear purpose, problem context, argument explanation, return description, and example use. Every sentence adds value, and it is appropriately sized with no redundancy.
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 description covers all needed information for using this tool: purpose, when to use, parameter details, expected return (JSON list and search info), and examples. An output schema exists (though not shown), but the description is sufficient for correct invocation.
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?
Schema description coverage is 0%, but the description adds significant meaning: it explains the search_index semantics (-1, -2, 0, 1...) and query_filter for filtering, and provides examples. This fully compensates for lack of schema documentation.
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 a list of PMIDs stored in the session, solving agent memory overload. It is specific about what resource (session PMIDs) and action (get) it performs. Among siblings, no other tool directly retrieves session PMIDs, so it is well-differentiated.
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 explains when to use this tool: when the agent's memory is full or to avoid storing many PMIDs, and can retrieve from session anytime. However, it does not explicitly state when not to use or provide alternatives among siblings, though none directly compete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions that it returns a list of presets with URLs. It does not disclose any behavioral traits like read-only, caching, or side effects. Given the low annotation burden, a 3 is appropriate as it adds minimal behavioral context.
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 brief and front-loaded with the purpose. The formatted section adds visual structure but is not necessary. Overall, it is concise and clear.
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 simplicity of the tool (zero params, list output) and the presence of an output schema, the description is complete. It describes the purpose, usage, and return value adequately.
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?
There are zero parameters, and schema coverage is 100%. Baseline for zero parameters is 4. The description adds no parameter info, but none is needed.
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 lists available institutional link resolver presets, with a specific verb-list-and-resource. It distinguishes this tool from sibling configure_institutional_access by explaining the relationship.
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?
Explicitly tells when to use this tool: to get presets, and gives clear guidance on how to use the output with configure_institutional_access(preset="name"). No missing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the two-phase call pattern, that question_type is inferred heuristically, and that p_query/i_query etc. are used for search while preserving labels. Mentions return includes validation, schema, query plan, and pipeline YAML.
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?
Well-structured with a clear summary sentence, a workflow paragraph, and an Args block. Could be slightly more concise but 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?
Given 13 parameters and a multi-step workflow, the description covers the purpose, workflow, parameters, and return value. Output schema exists (not shown) but description mentions JSON structure, making it sufficiently complete.
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?
Schema description coverage is 0%, but description adds detailed explanations for each parameter in the Args section, e.g., p_query: 'Optional expanded PubMed-ready query fragments...'. This compensates fully for the lack of schema descriptions.
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 it validates agent-provided PICO elements and returns a runnable search plan. It specifies the tool's role in the PICO extraction and search pipeline, distinguishing it from sibling tools like generate_search_queries and unified_search.
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?
Explicitly describes the two-phase usage: first call with only description to get schema, then with structured elements. States that the agent, not the server, extracts P/E/C/O. Does not explicitly mention when not to use, but usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full behavioral burden. It describes the return format (JSON verification report with parsed fields and matching) and mentions a manual-review workflow for unresolved cases. It does not specify rate limits or authentication needs, but as a verification tool, the details are adequate.
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 front-loaded with the primary purpose and includes structured sections for scope and parameters. It is slightly verbose with version details that may not be essential, but remains well-organized and easy to parse.
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?
Given the presence of an output schema, the description adequately covers inputs, purpose, and return format. It may lack error handling details or processing limits, but overall provides sufficient context for an agent to invoke the tool 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?
Schema coverage is 0%, but the description's 'Args' section provides clear, meaningful descriptions for all three parameters (e.g., 'Plain-text references, ideally one per line' for reference_text). This fully compensates for the schema's lack of descriptions.
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 'Verify a plain-text reference list against PubMed evidence,' specifying the verb (verify), resource (reference list), and target (PubMed). It distinguishes from siblings like 'get_article_references' and 'find_citing_articles' by focusing on verification of a list rather than fetching individual citations.
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 clear context by delineating first and second version scopes, implying appropriate use for plain-text list verification. However, it lacks explicit when-not-to-use guidance or direct comparisons to sibling tools, which would raise it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses depth-related API call volume (depth=3 ~100+ calls), explains output formats and directions, and notes the return format. It does not mention rate limits or authentication, but overall transparency is good.
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 quite detailed and uses effective formatting (emojis, bullets, examples) to enhance readability. While every sentence adds value, it could be slightly more concise without losing clarity, but the structure is good.
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 tool's 6 parameters, no annotations, and an assumed output schema, the description covers nearly all aspects: parameters, output format details, return value (JSON with metadata and statistics), and examples. It is comprehensive and prepares the agent well for invocation.
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?
Schema coverage is 0%, so the description must explain all parameters. It does so thoroughly: pmid (single, example), depth (1-3 with level descriptions), direction (three options), limit_per_level (default 5), include_details (default True), and output_format (eight options with use cases). This exceeds the typical parameter documentation.
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 explicitly states the tool builds a citation tree/network from a single article, distinguishing it from siblings like find_citing_articles or get_article_references. It uses specific verbs and resources, making the purpose unmistakable.
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 clear usage guidance, including the important constraint that only one PMID is accepted at a time and suggesting separate calls for multiple papers. It does not explicitly list when not to use the tool or fully contrast with siblings, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It details two modes, milestone detection, output formats, and parameter effects. It does not discuss side effects or constraints, but it is comprehensive for a read-only tool.
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 lengthy but well-structured with sections, bullet points, and code examples. It is front-loaded with the main purpose and modes. Minor redundancy could be trimmed, but overall it's efficient.
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 tool's complexity (8 parameters, no annotations, output schema present), the description is very complete. It covers modes, milestones, output formats, and provides multiple examples. It addresses all user needs.
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 all 8 parameters, including valid values, defaults, and examples. It adds significant meaning beyond the schema, such as the special value 'last' for pmids.
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 builds a research timeline for a topic or specific PMIDs, distinguishing two modes of operation. It uses specific verbs and resources, and the purpose is unambiguous.
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 clear guidance on when to use each mode (by topic or by PMIDs) and includes examples. However, it does not explicitly state when not to use this tool or compare it to siblings like compare_timelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes directionality, use cases, and provides example. Does not mention potential limitations (e.g., API rate limits) but overall clear and helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but somewhat verbose with emojis and ASCII art. Information is front-loaded in the first paragraph. Could be more concise without losing clarity.
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?
With 2 parameters, no annotations, and an output schema, description adequately covers purpose, usage, parameters, and example workflow. Return details are implied but output schema exists.
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?
Adds significant meaning beyond bare input schema: specifies accepted formats for pmid, valid range for limit, and default value. Schema itself has no descriptions (0% coverage), so description fully compensates.
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?
Clearly states it gets the references/bibliography of a PubMed article. Explicitly contrasts with find_citing_articles (forward vs backward). Verb+resource is specific.
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?
Provides explicit when-to-use (backward citation search) and when-not-to-use (forward search via find_citing_articles). Includes example workflow demonstrating typical usage with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details return fields and parameter behavior but does not explicitly state read-only nature or side effects. However, it implies a query operation (get metrics) and describes output, scoring high but missing explicit safety cues.
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 thorough and well-structured with a summary line, bulleted return fields, and parameter explanations. While slightly long, every sentence adds value. It could be more concise but remains clear and organized.
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 tool's complexity (6 params, 1 required) and the presence of an output schema, the description is complete: it explains return fields, sorting, filtering, and all parameter options. An agent can confidently invoke this tool with the provided information.
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?
Schema coverage is 0%, so description fully compensates by detailing all parameters: pmids formats, sort_by options with explanations, and filter thresholds (min_citations, min_rcr, min_percentile). Even output_format is mentioned via enum in schema. No parameter information is missing.
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 metrics from NIH iCite, listing specific metrics like citation_count, RCR, and nih_percentile. This distinguishes it from sibling tools like find_citing_articles or get_article_details, which have different focuses.
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 explains sorting and filtering capabilities but does not explicitly state when to use this tool versus alternatives (e.g., fetch_article_details). The clear purpose and parameter details provide implicit context, but no exclusions or when-not guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully covers behavior: load for review/editing, returns YAML+metadata. No destructive actions implied. Could mention if loading affects state, but fine.
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 informative. Three sections: purpose, sources, subsequent operations. No fluff.
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?
Given output schema exists, return values are adequately described. Parameters fully explained. Sibling differentiation present. Could mention if loading modifies anything, but minor.
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?
Input schema has 0% description coverage; description fully compensates by explaining source parameter with examples and syntax (saved:, file:). Adds crucial meaning.
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 specifies verb 'load' and resource 'pipeline configuration' for review/editing. Differentiates from siblings like delete_pipeline, save_pipeline, list_pipelines.
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?
Provides context on when to use (loading from saved name or local file) and subsequent actions (execute or save). No explicit exclusions but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that only reachability is tested, not actual access. It explains what the test checks and the limitations. However, it does not mention permissions, rate limits, or side effects, which would be desirable for complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose with decorative ASCII art and extensive test instructions that could be condensed. While it is well-structured and front-loaded, it contains redundant details that could be trimmed without losing value.
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 low complexity (1 parameter, no required fields, with output schema), the description is comprehensive. It covers tool purpose, test scope, limitations, usage examples, and return values. The presence of an output schema does not reduce the need for behavioral context, and the description provides it adequately.
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?
The schema coverage is 0%, but the description explicitly explains the 'pmid' parameter with its default value and purpose. This compensates well for the lack of schema documentation, adding clear 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 it tests the institutional link resolver configuration, checking configuration, reachability, and response validity. It distinguishes from sibling tools like 'configure_institutional_access' and 'diagnose_institutional_access' by focusing on testing.
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 gives explicit guidance on when to use the tool (to test link resolver configuration) and provides alternatives like using the 'test_free' preset. It also explains what the test does not guarantee (full-text access), setting appropriate expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description takes full responsibility. It explains source options (official vs local), format availability, and output format. However, it omits details about error handling, rate limits, or idempotency, which would enhance transparency.
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-structured with sections, tables, and examples. It is front-loaded with the purpose and recommended source. Every sentence adds value, and the length is justified by the tool's complexity.
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 presence of an output schema, the description doesn't need to detail return values. It fully covers input parameters, format selection, source options, and provides examples. The description is complete for the tool's complexity.
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 thoroughly. It explains pmids with multiple accepted formats, format with per-source options, include_abstract default, and source with two options. Examples further clarify usage.
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 'Export citations to reference manager formats.' and lists specific formats (EndNote, Zotero, Mendeley, BibTeX). It distinguishes itself from sibling citation tools by focusing on exporting, with detailed format and source guidance.
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 'When to Use' section explicitly lists use cases, and the format selection guide provides context. However, it doesn't explicitly state when not to use or how it differs from alternatives like fetch_article_details or get_article_references, missing clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description adequately discloses key behaviors: upsert semantics (overwrites if exists), storage scopes (workspace/global/auto), and config format (YAML/JSON). It omits error handling or authentication needs, but covers the most critical aspects.
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-structured with a main sentence, a supporting paragraph, an Args list, and a Returns note. Every sentence adds value without redundancy, making it efficient and easy to parse.
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?
For a save tool with 5 parameters (2 required) and no annotations, the description covers purpose, usage, parameter details, and return value. It provides sufficient context for correct invocation, including upsert and scope behavior. No major gaps.
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 excellently by detailing each parameter: name constraints (max 64 chars, allowed characters, upsert), config format, tags as comma-separated, description purpose, and scope options with default. This provides full 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 saves a pipeline configuration for later reuse, with a specific verb and resource. It distinguishes itself from siblings like load_pipeline and delete_pipeline by emphasizing storage and reuse.
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 explains when to use the tool (to save for later reuse) and gives an example of loading via unified_search. However, it doesn't explicitly exclude alternatives like manage_pipeline or schedule_pipeline for similar tasks, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description takes on the full burden of behavioral disclosure. It explains that the tool uses algorithm-based similarity and returns similar papers not based on citations. It would benefit from mentioning any potential limitations or rate limits, but overall it provides good transparency about the underlying mechanism.
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 headings and ASCII art, but it is somewhat verbose. The front-loaded purpose and workflow sections are efficient, but the extensive formatting may be overly elaborate for the information conveyed.
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 tool's simplicity (2 parameters, output schema exists), the description is complete. It covers purpose, usage, parameter details, and example workflow, and provides sufficient context for effective invocation.
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 schema description coverage is 0%, but the description compensates by explaining the pmid parameter's acceptable formats (e.g., '12345678', 'PMID:12345678', 12345678) and the limit parameter's range (1-50) and default value (5). This adds significant value 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 that the tool finds articles related to a given PubMed article using PubMed's 'Related Articles' feature. It distinguishes itself from siblings by detailing that it is algorithm-based similarity, not citation-based, and includes a workflow section highlighting the differences among the three related tools.
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 when-to-use guidance, including a workflow example and a comparison with sibling tools (find_citing_articles and get_article_references). It explains that this tool is for discovering similar research based on topics, MeSH terms, and authors, not citations, which helps in selecting the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses sources (Open-i, Europe PMC), language limitation, filtering capabilities, example calls, and return format. This transparency exceeds expectations.
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 long but well-structured with clear sections (purpose, critical warning, sources, examples, args). It earns its length given the tool complexity, but could be slightly more concise.
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 13 parameters, 1 required, and an output schema, the description covers all necessary aspects: all parameters with values, language constraint, sources, examples, and return information. It is complete.
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?
Schema description coverage is 0%, so the description must compensate. It does so by exhaustively listing each parameter's possible values, meanings, and defaults with examples. This adds immense value beyond the raw 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 searches biomedical images across Open-i and Europe PMC, returning image URLs with metadata. This distinguishes it from sibling tools like search_gene or search_compound, which are for other data types.
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 detailed usage guidance including explicit language requirements, parameter options, and examples. However, it does not explicitly state when not to use this tool or suggest alternative siblings, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It details the entire workflow: query analysis, auto-source selection, parallel search, deduplication, ranking, OA enrichment, ICD expansion, and auto-relaxation. It also explains behaviors like runtime options and pipeline execution.
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 very long but well-structured with clear sections, icons, and examples. It front-loads the core purpose and then dives into detailed parameter docs. While every sentence earns its place, it could be marginally trimmed without loss of clarity.
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 tool's high complexity (10 parameters, nested pipeline option), the description is complete. It covers input, behavior, output format, and edge cases (e.g., ICD expansion, auto-relaxation). An output schema exists, so return value details are not required, and the description adequately summarizes expected outputs.
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 input schema has 0% description coverage, so the description must compensate. It does so comprehensively: for every parameter (e.g., sources, ranking, filters, options, pipeline) it provides detailed explanations, examples, enumerations, and formatting rules, far exceeding what the schema alone conveys.
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 as a 'Single entry point for multi-source academic search' that automatically analyzes queries and selects best sources. It distinguishes from siblings by being the unified, automated option, while siblings like 'analyze_search_query' or 'search_compound' are more specialized.
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 positions this as the default search tool ('No need to choose between...') and provides numerous examples showing simple and advanced usage. However, it does not explicitly state when _not_ to use it or name specific sibling alternatives that might be better for narrow tasks (e.g., searching only genes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It fully discloses the experimental nature, the workflow (return image, then agent must analyze and search), the required English terms, and the expected agent actions. 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 sections and emoji, but slightly verbose. It includes redundant instructions (e.g., repeated reminders to search automatically) and an extensive use cases list that could be shortened.
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 output schema (not shown) and the detailed parameter descriptions, the description is highly complete. It covers input, output, workflow, rules, use cases, search types, and examples. No gaps.
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?
Schema description coverage is 0%, but the description includes an 'Args:' section that explains each parameter (image, url, context, search_type) with examples. This adds 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 'Analyze a scientific figure or image for literature search' and distinguishes from sibling search tools by specifying that after analysis, the agent should call search_biomedical_images or unified_search. It provides specific verb and resource.
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 workflow steps, rules (e.g., English search, automatic searching), search types, and use cases. It tells the agent exactly when to use this tool and to proceed without user confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully reveals behavior: it performs a forward citation search using PubMed Central data, returns a list of citing articles, and is read-only. No contradictions or hidden traits.
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 sections, emojis, and examples, making it scannable and informative. It could be slightly more concise, but every section serves a purpose.
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 description covers all necessary context: it explains the direction of citation search, use cases, parameter details, and provides an example. With an output schema present for return values, no further details are needed.
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 value beyond the input schema: it specifies acceptable pmid formats (e.g., '12345678', 'PMID:12345678') and explains the limit range (1-100) and default (10). This compensates for the 0% schema description coverage.
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 finds articles that cite a given PubMed article, using specific verbs and resource. It distinguishes from sibling tools like get_article_references (backward search) and find_related_articles (topic-based), ensuring the agent selects the correct tool.
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 lists use cases (e.g., track research impact, find follow-up studies) and complementary tools, providing clear guidance on when to use this tool versus alternatives. An example further clarifies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behaviors like spelling correction via NCBI ESpell, MeSH term lookup, synonym expansion, and query analysis showing PubMed's interpretation. It also describes the return structure (JSON with fields like corrected_topic, keywords, mesh_terms, all_synonyms, suggested_queries with estimated_count and pubmed_translation). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with headers, modes, steps, and features. It is front-loaded with the core purpose and uses clear formatting. While some detail might be excessive (e.g., full workflow steps), it is justified given the tool's complexity and integration with other tools.
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 tool's complexity (4 parameters, output schema, many siblings), the description is highly complete. It covers what the tool does, how to use it in two modes, parameter details, return value structure (listing keys), and integration with follow-up tools. The presence of an output schema is mentioned, but the description already explains the return fields.
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?
Schema description coverage is 0%, but the description includes an 'Args:' section that explains each parameter (topic, strategy, check_spelling, include_suggestions) and their effects (e.g., strategy affects suggested_queries, check_spelling for spelling correction). This adds significant meaning beyond the schema alone.
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: 'Gather search intelligence for a topic - returns RAW MATERIALS for Agent to decide.' It distinguishes itself from sibling tools like unified_search and analyze_search_query by emphasizing that it provides building blocks, not finished queries. The two usage modes (keyword and PICO) further clarify its role.
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 when-to-use guidance with detailed step-by-step workflows for both keyword and PICO modes. It contrasts with sibling tools by stating that the agent decides how to use the raw materials, and it references subsequent steps (analyze_search_query, unified_search). No alternative tools are mentioned, but the usage context is thoroughly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: directory resolution priority, overwrite control, index creation, and return value including written and skipped files. It also mentions wiki_validation for unresolved-link checks, covering important behavioral details.
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-structured with sections (When to Use, Directory Resolution, Args, Returns, Examples). It is efficient, front-loaded with purpose, and every sentence provides value without redundancy.
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 purpose, usage, parameters, return values, and examples. It is comprehensive given the complexity and lack of annotations. Minor gaps like error handling or edge cases are not covered, but overall it is very complete.
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?
Schema coverage is 0%, so the description must explain parameters. It does so comprehensively: pmids (accepts 'last', list, etc.), output_dir (optional), note_format (defaults to wiki, lists options), and template_file (placeholders). 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 it saves searched articles as guided local wiki/Foam/Markdown notes, specifying the resource (articles) and verb (save). It distinguishes from siblings by mentioning 'structured alternative to generic write_file calls' and focuses on Foam-compatible wikilinks and MedPaper-like reference notes.
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 'When to Use' section explicitly states to use after unified_search, provides a structured alternative to write_file, and describes the purpose of creating wiki notes. It also indicates when to use (after search) and provides context for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pubmed-search-mcp MCP server](https://glama.ai/mcp/servers/u9401066/pubmed-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/u9401066/pubmed-search-mcp)

Score Badge

Copy to your README.md:

[![pubmed-search-mcp MCP server](https://glama.ai/mcp/servers/u9401066/pubmed-search-mcp/badges/score.svg)](https://glama.ai/mcp/servers/u9401066/pubmed-search-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/u9401066/pubmed-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server