nucleotide_archive_mcp

Server Quality Checklist

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

Latest release: v0.0.7
Disambiguation4/5
Tools are mostly distinct, with some overlap between metadata retrieval tools like get_available_fields and list_library_types, and between get_study_details and get_study_publications. However, clear descriptions clarify when to use each, reducing ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_rna_studies, get_study_details). Deviations like find_studies_by_publication still follow a predictable verb_noun_by_phrase structure.
Tool Count5/5
With 11 tools, the set is well-scoped for accessing the European Nucleotide Archive. Each tool serves a distinct purpose in the workflow: discovery, search, metadata retrieval, and download.
Completeness4/5
The tools cover the essential workflow from discovery to download. Minor gaps exist, such as the absence of direct date-based search and the find_studies_by_publication tool being a documented dead end, but these are acceptable for a read-only archive interface.
Average 4.4/5 across 11 of 11 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 27, 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

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 details the return structure but does not explicitly state behavioral traits like safety (read-only), side effects, authentication needs, or rate limits. The return description hints at no destructive behavior, but this is not confirmed.
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 (usage tips, returns). It is informative and avoids unnecessary fluff, though the returns section repeats information that may be in the output schema. Slightly more concise could be achieved.
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 no annotations and the presence of output schema, the description covers inputs, usage, and outputs well. It mentions prerequisite (call after search) and provides detailed return structure. Lacks error handling details and authentication info, but is fairly 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?
Schema coverage is 100%, so baseline is 3. The description does not add new meaning to parameters beyond the schema, though the return section mentions include_md5 affecting checksums. Overall, it does not significantly enhance parameter understanding.
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 FTP download URLs for sequencing data files in a study. It specifies the verb (get), resource (FTP download URLs), and scope (study). It implicitly distinguishes from siblings by mentioning usage after search_rna_studies and passing to generate_download_script.
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 says 'Call after search_rna_studies()' and mentions alternatives: 'can be used with wget/curl or passed to generate_download_script()'. While it doesn't explicitly list when not to use it, the guidance is clear and contextual.
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 discloses that the tool optionally saves a script to file (making it executable with chmod 755) and includes MD5 verification commands. It also details the return dictionary. Missing are explicit mentions of overwrite behavior, permissions, or error handling, but overall it is sufficiently transparent for a script generation 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 clear header, Usage Tips, and Returns section. It is concise but comprehensive, front-loading the purpose. Slightly could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema coverage is 100% and an output schema exists (though not shown), the description covers purpose, usage workflow, and return values. It could mention idempotency or specific error conditions, but it is largely complete for a script generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema's descriptions for each parameter; it focuses on usage and returns. No additional parameter semantics are provided.
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 opens with a specific verb+resource: 'Generate executable bash script to download all study data files.' This clearly distinguishes it from siblings like get_download_urls (URLs) and search_rna_studies (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?
The Usage Tips section explicitly states 'After identifying interesting studies, generate a download script' and provides a typical workflow: search_rna_studies() → get_study_details() → generate_download_script(). This gives clear context for when to use it, though it does not explicitly list when not to use it or alternative tools.
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. It describes the return structure but does not explicitly mention that the tool is read-only or has no side effects. Additional transparency about safety or constraints would improve this.
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, front-loaded with the main purpose, and concise. Every sentence adds value without unnecessary repetition.
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 (2 parameters, detailed output), the description comprehensively covers purpose, usage, and return structure. No obvious gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are already in the schema. The description adds context about using the results for custom queries, but does not add significant semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get available search and return fields for an ENA result type.' This is a specific verb and resource, and it distinguishes from sibling tools like build_custom_query which uses these fields.
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 usage tips that explicitly mention using this before build_custom_query, providing context for when to use it. However, it does not state when not to use it or list alternative tools, so it's slightly incomplete.
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 details the return structure but does not disclose any side effects, authentication needs, or rate limits. However, for a read-only 'get' operation, the transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: description, usage tips, returns. Every sentence adds value, and it is front-loaded with the 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?
Given the single parameter, no annotations, and detailed return description, the tool definition is complete for its purpose. The description covers all necessary aspects.
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?
Input schema has 100% description coverage for the single parameter 'study_accession'. The description adds no additional semantics beyond the schema's description and examples.
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 'Get comprehensive metadata for a specific ENA study including publications.' It specifies the verb, resource, and scope, distinguishing it from siblings like 'get_study_publications' which only returns publications.
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 explicit usage tip: 'Call after search_rna_studies() to verify a study matches your research needs before downloading.' It also mentions checking publications array for PubMed IDs, giving clear context for when 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?
With no annotations, the description provides a detailed return structure covering all fields including author details, citation counts, and open access status. It implies read-only behavior by stating it 'gets' data from external sources. No destructive effects are mentioned, which is appropriate.
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 brief introductory sentence, a 'Usage Tips' section, and a detailed 'Returns' section. While fairly long, the detailed output documentation is necessary given no separate output schema. The information is front-loaded and each part serves a 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?
The description covers the input parameter, usage context (after search_rna_studies), and a comprehensive return structure. It lacks explicit error handling details (though 'error' field is mentioned). Overall, it is quite complete for a tool with one parameter and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'study_accession' is well-documented in the input schema with description and examples. The tool description does not add additional semantics beyond what the schema already provides. Schema coverage is 100%, so baseline is 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 verb 'Get', the resource 'detailed publication information for a study', and the sources 'ENA and Europe PMC'. It differentiates from siblings like get_study_details by saying it enriches basic info with complete bibliographic data.
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 says to call after search_rna_studies() and that it enriches get_study_details(). This provides clear context for when to use the tool versus alternatives, though it does not state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description details the return dictionary structure and indicates the tool constructs a query (non-destructive). It could be more explicit about side effects but is clear overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sections (Usage Tips and Returns) plus a one-liner, no fluff, front-loaded with key info. 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 the output schema is described and sibling tools are complex, the description covers purpose, prerequisites, return structure, and use case. Minor gap: no mention of error handling details beyond the error field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with examples; the description adds the usage tip about get_available_fields, which indirectly helps with field_conditions, but doesn't elaborate further on parameter meanings 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 builds a custom ENA query from field conditions, distinguishing it from search_rna_studies by offering precise filtering.
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 provides when to use: 'for precise filtering beyond what search_rna_studies() offers', and suggests calling get_available_fields first, guiding the agent on prerequisites.
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 the tool's behavior: it returns an error message with recommended workflow, count always 0, studies empty. No hidden surprises.
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 headers and bullet points, but could be slightly more concise. Every sentence adds value, but the returns section is somewhat redundant with schema.
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 simple tool with one parameter and an output schema, the description fully covers what to expect, including error handling and alternative workflow. No 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?
Schema coverage is 100% with description and examples for the single parameter. Description adds context about API limitation but does not significantly augment the parameter's 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 finds ENA studies by PubMed ID, then immediately notes the API limitation and provides an alternative workflow. It distinguishes itself from sibling tools like search_studies_by_keywords.
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 not to use this tool and provides an alternative: use search_studies_by_keywords() with publication terms, then get_study_details(). This is perfect 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 provided, the description fully describes the return structure (dictionary with count, result_types, recommended_for_rna_studies, error). It implies a read-only query but does not explicitly state it is non-destructive. Good disclosure overall.
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 reasonably concise with clear sections (description, Usage Tips, Returns). It is front-loaded with the main purpose. Some verbosity in section headers is acceptable.
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?
Despite no parameters, the tool's purpose is fully explained, and the return structure is detailed, complementing the output schema. The recommendation for RNA studies adds valuable context.
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 zero parameters, so the description correctly omits parameter details. Baseline for 0 params is 4.
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 all available result types (data categories) in ENA.' It specifies a specific verb ('get'), resource ('result types'), and scope ('all available'). This distinguishes it from sibling tools like search 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 'Usage Tips' section explicitly says: 'Use to discover what types of data you can search for in the European Nucleotide Archive. Most users will use read_study or study for RNA-seq searches.' This provides clear usage context and mentions alternatives.
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 fully explains default behavior (searches across all organisms unless specified) and gives search tips. It does not mention destructive actions (irrelevant for search) but adequately covers behavioral traits. The return structure is described. A score of 4 reflects good transparency without explicit safety or rate-limit details, which are not essential here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when to use, default behavior, search tips, return format). It is somewhat verbose but each part adds value. Front-loading is effective. Slight reduction in redundancy would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 0 required, high schema coverage, and an output schema), the description is complete. It covers all essential aspects: purpose, usage context, behavioral details, parameter guidance, and return values. An agent can correctly invoke this tool based on the description alone.
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 100%, so baseline is 3. The description adds value by explaining parameter roles (e.g., disease/tissue matched against study_title), clarifying the technology parameter vs library strategies, and providing search tips. This enhances understanding beyond the 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's purpose: 'Search for RNA sequencing studies by disease, tissue, and organism.' It specifies the main parameters and distinguishes itself from the sibling tool search_studies_by_keywords, which is used for broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'When to use this tool' section, stating it is the primary search tool when you know disease/condition or tissue/cell-type, and directs to use search_studies_by_keywords() for broader searches by biological processes or methodology. This clearly differentiates usage from alternative tools.
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?
Without annotations, the description fully discloses key behaviors: it searches both study titles and sample descriptions, splits multi-word keywords into AND conditions, may return studies with only one sample matching, and notes broader results compared to disease/tissue filters. This gives agents 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections ('When to use', 'Important notes', 'Search tips') and a defined returns format. Every sentence is informative and earns its place. 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?
Given the tool's complexity (5 parameters, 1 required, no enums, output schema present), the description is fully complete: it explains behavior, usage tips, parameter nuances, and the return structure. The output schema is described even though it's not required, adding clarity.
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 100%, so baseline is 3. The description adds value by explaining how multi-word keywords are handled (split into individual words that must all match), which is not in the schema. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Search for studies using flexible keyword matching across titles and descriptions') and distinguishes it from sibling tool search_rna_studies, making the purpose and differentiation explicit.
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 guidance ('Use this for broad exploratory searches when search_rna_studies() is too restrictive'), lists specific use cases, includes important notes on keyword splitting and search tips, and contrasts with alternatives.
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?
Fully describes the return value structure (dict with five keys) and implies read-only behavior. No contradiction with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections, concise yet complete. Every sentence adds 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?
Complete for a zero-parameter tool: covers purpose, usage, output structure, and integration with sibling tool search_rna_studies.
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?
No parameters, so description adds value by detailing the output schema and usage hints. Compensates fully for lack of 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?
Clearly states it lists all available library strategies and sources for ENA searches, with specific verb 'List' and resource. Distinguishes from siblings by mentioning use in search_rna_studies.
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 advises to call this before search_rna_studies to discover available types for filtering, and gives direct usage tips.
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:

[![nucleotide_archive_mcp MCP server](https://glama.ai/mcp/servers/biocontext-ai/nucleotide_archive_mcp/badges/card.svg)](https://glama.ai/mcp/servers/biocontext-ai/nucleotide_archive_mcp)

Score Badge

Copy to your README.md:

[![nucleotide_archive_mcp MCP server](https://glama.ai/mcp/servers/biocontext-ai/nucleotide_archive_mcp/badges/score.svg)](https://glama.ai/mcp/servers/biocontext-ai/nucleotide_archive_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/biocontext-ai/nucleotide_archive_mcp'

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