nmdc-mcp

Official

by microbiomedata

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: fetching GFF by PFAM domains, retrieving collection IDs, biosamples by study, collection names/stats, data objects by PFAM, entities by ID with/without projection, samples by annotation/ecosystem/elevation/lat-lon, study DOI details, study for biosample, and searching studies by DOI. Even similar functions like entity retrieval are differentiated by batch vs single and projection vs full.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, primarily starting with 'get_' or 'fetch_', with clear and descriptive nouns. The only variation is 'search_studies_by_doi_criteria', but it still maintains the pattern. No mixing of camelCase or inconsistent verb styles.
Tool Count4/5
16 tools is slightly above the typical 3-15 range, but it is well-scoped for the NMDC database query domain. Each tool serves a specific purpose without redundancy, and the count is reasonable given the variety of query needs (by ID, by annotation, by location, etc.).
Completeness4/5
The tool set covers a comprehensive range of query operations for the NMDC database: listing collections, retrieving entities by ID, searching biosamples by multiple criteria (study, ecosystem, elevation, location, PFAM domains), and accessing study DOIs. Minor gaps include lack of direct query for data objects by other attributes, but for a read-only query interface, this is nearly complete.
Average 3.3/5 across 16 of 16 tools scored. Lowest: 2.7/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 August 12, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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 carries the full burden for behavioral disclosure. It only states the tool 'finds' and 'returns' data, implying a read operation, but does not mention idempotency, side effects, authentication needs, or rate limits. For a zero-annotation tool, more behavioral context is needed.
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 concise at three sentences, but the second sentence ('Returns structured data...') is somewhat redundant with the first, and the third ('Perfect for...') adds little. It could be more direct.
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 two parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output structure, how results are ordered, or how 'biosample_limit' works. It also fails to contrast with the sibling tool dealing with PFAM domains, leaving an agent uncertain about selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but does not. It does not explain the format or expected values for 'pfam_domain_ids' (e.g., Pfam IDs? names?) nor clarify 'biosample_limit' (e.g., per domain or total). The phrase 'specific PFAM protein domains' is too vague.
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 clearly states it finds biosamples with specific PFAM domains and returns structured data about biosamples, activities, and data objects. It uses a specific verb 'find' and names the resource, but does not explicitly distinguish from the sibling tool 'fetch_and_filter_gff_by_pfam_domains'.
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 the tool ('find biosamples with specific PFAM domains', 'Perfect for finding samples with particular functional capabilities') but lacks explicit guidance on when not to use it or alternatives.
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, the description carries the full burden. It only states that it returns study information and metadata, but does not describe what happens if the biosample is not found, error behavior, or any side effects. For a simple lookup, this is borderline adequate but lacks depth.
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 short with two sentences, no redundant information. However, it is so brief that it sacrifices completeness. It could include more details without being verbose.
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 simplicity (1 param, no output schema, no annotations), the description should still cover common questions like return format, error handling, or typical use. It fails to provide enough context for confident tool invocation.
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?
The single parameter 'biosample_id' is only defined as a required string in the schema. The description does not add any additional meaning (e.g., format, examples, or constraints), and schema description coverage is 0%, so it fails to compensate.
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 clearly states the verb 'find' and the resource 'study associated with a specific biosample'. It is specific enough to differentiate from sibling tools that fetch biosamples or studies separately, though it does not explicitly distinguish itself.
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 guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., must have a biosample_id) or when not to use it. Sibling tools like 'get_biosamples_for_study' suggest alternative use cases, but no comparison is made.
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 cover behavioral aspects. It fails to disclose that the max_records parameter limits results, contradicting the phrase 'all biosamples'. Also lacks details on pagination, ordering, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading its primary purpose. However, it lacks structured formatting that could improve scanability.
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 absence of an output schema, the description only vaguely mentions 'metadata'. The tool's behavior regarding the max_records limit is not aligned with the claim of returning 'all biosamples', making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 no meaning to the parameters. For example, it doesn't explain what study_id format is expected or how max_records affects the result.
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 clearly states the tool's purpose: to find biosamples associated with a specific study, and specifies the output type (list of IDs and metadata). However, it does not explicitly differentiate from sibling tools like get_study_for_biosample, though the reverse relationship is implicit.
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 use when you have a study ID and need related biosamples, but lacks explicit when-not-to-use guidance or mention of alternative tools for reverse lookup.
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 provided, so description bears full burden. It discloses the tool retrieves entities but omits critical behavioral traits: return format, error handling, authentication needs, rate limits, or whether it is a read-only 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?
Single sentence that directly states purpose. No unnecessary words, front-loads the action and entity scope. Highly efficient for a simple tool.
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?
For a one-parameter tool with no output schema and no annotations, the description is too sparse. It lacks context on output behavior, error responses, and when this tool is appropriate relative to siblings.
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 coverage is 0%, but description adds no parameter-specific details. It mentions the tool works with various entity types but does not clarify the expected format or constraints of entity_id beyond the schema type 'string'.
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 clearly states the tool retrieves an NMDC entity by ID and lists examples (biosamples, studies, data objects). However, it does not distinguish from siblings like get_entity_by_id_with_projection which adds projection capabilities.
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 guidance on when to use this tool versus alternatives. No mention of prerequisites, limitations (e.g., fetch size), or when to prefer other tools from the sibling list.
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 implies a read-only operation ('find biosamples') but says nothing about authorization, rate limits, side effects, or return structure. This is insufficient for safe invocation.
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 two sentences with no superfluous text. It front-loads the core action and gives concrete examples. Could add parameter details without becoming verbose.
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 four parameters, no annotations, no output schema, and many sibling tools, the description is too sparse. It lacks details on filtering behavior, valid values, output format, and pagination (max_records). The agent would likely need additional external knowledge to use this tool correctly.
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 names three ecosystem-related parameters (category, type, subtype) and provides vague examples but does not explain valid values, format, or how they combine. The max_records parameter is omitted entirely.
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 clearly states the tool retrieves biosamples by ecosystem type, category, or subtype, and provides examples (soil, marine, host-associated). It distinguishes from sibling tools that operate on other criteria like annotations or coordinates, but does not explicitly contrast.
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 the tool ('perfect for studying particular environments') but provides no guidance on when not to use it or how it compares to alternatives like get_samples_by_annotation or get_biosamples_for_study.
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 fully disclose behavioral traits. It only states the basic function and does not mention edge cases (invalid coordinates), boundary handling, performance, pagination, or response format. This is insufficient for an agent to understand side effects or limitations.
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 a single concise sentence with no wasted words. It is front-loaded with the key action and context, achieving maximum efficiency.
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's simplicity (4 params, no output schema), the description is still incomplete. It does not explain return format, error handling, or any constraints on coordinate values (e.g., valid ranges for latitude/longitude). An agent cannot rely on this alone to invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the description adds no meaning beyond the parameter names. It does not explain what each coordinate represents (e.g., lower_lat is southern boundary, upper_lat is northern), nor does it clarify units or constraints. This leaves the agent to infer from parameter names 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 finds biosamples within a geographic bounding box, specifying the verb 'find', resource 'biosamples', and scope 'within a specific geographic bounding box defined by latitude and longitude coordinates'. This distinguishes it from sibling tools like get_samples_in_elevation_range.
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 only says 'Use this tool to find biosamples' but provides no guidance on when to use it vs alternatives (e.g., get_samples_by_annotation, get_samples_in_elevation_range). No prerequisites or exclusions are mentioned, so it lacks context for decision-making.
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 should disclose behavioral traits. It mentions searching but doesn't state whether the tool is read-only, how results are combined (AND/OR), or any side effects. The safety or mutation behavior is unclear.
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 sentences, front-loaded with an action verb ('Use this tool to search'). Every word serves a purpose, no redundancy. Excellent conciseness.
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 zero schema coverage, no output schema, and no annotations, the description is too sparse. It omits return format, pagination, error handling, and behavior with multiple criteria or empty results. A search tool should provide more context for effective use.
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 description coverage is 0%, so the description must compensate. It partially explains three parameters (doi_provider, doi_category, doi_value_contains) but vaguely ('DOI value patterns' is ambiguous). max_results is not mentioned. Baseline 3 is appropriate as it adds meaning but not enough to fully cover the gap.
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 clearly states the tool searches for studies by DOI criteria (provider, category, DOI value patterns). It specifies the resource ('studies') and the filtering dimensions. However, it does not differentiate from sibling tools like get_study_doi_details, which focuses on single study DOIs.
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 says 'Use this tool to search...' and 'Perfect for finding...' but provides no guidance on when not to use it or how it compares to alternatives like get_study_doi_details or other search tools. No explicit conditions or exclusions are stated.
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 compensate. It mentions batching but does not disclose return format, pagination behavior, or any side effects. The agent lacks key behavioral insight beyond the basic operation.
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 two sentences, front-loaded with the primary purpose. It is efficient but could slightly expand on parameter expectations without becoming verbose.
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 three unannotated parameters and no output schema, the description does not cover what collections are acceptable, the range of batch_size, or the impact of max_batches. The tool's behavior is underspecified for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the parameters 'collection', 'batch_size', and 'max_batches'. It merely restates their names without explaining valid values, defaults, or usage context.
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 lists of IDs') and resource ('NMDC collections') with batching detail. It distinguishes from siblings like get_collection_names and get_collection_stats which serve 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 usage for 'sampling or systematic analysis of large datasets' but does not explicitly compare to other tools or provide when-not-to-use guidance. It leaves the agent to infer context without clear 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 provided, and the description does not disclose behavioral traits beyond the purpose. It does not state that it's read-only, error behavior, or any constraints. The description carries the full burden but fails to add 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?
One concise sentence that front-loads the action. No redundant or unnecessary 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 the simplicity of the tool (one parameter, no output schema), the description reasonably covers the output by listing included DOIs. Lacks mention of output structure but sufficient for a straightforward lookup.
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?
The single parameter 'study_id' is not explained in the description; format, constraints, or examples are missing. With 0% schema description coverage, the description should compensate but does not.
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?
Description clearly states it gets detailed DOI information for a study, specifying three types (publication, dataset, award). It identifies the resource and output, but does not explicitly differentiate from the sibling tool 'search_studies_by_doi_criteria'.
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 guidance on when to use this tool versus alternatives, no when-not or prerequisites mentioned. Only a basic instruction 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 must carry the full behavioral disclosure. It only states 'find biosamples' with no mention of side effects, output format, or other behavioral traits, leaving significant gaps.
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 concise with two sentences, front-loading the imperative. It is efficient but could benefit from slightly more structure.
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?
The tool has no output schema, so the description should indicate return type and behavior. It lacks details on output, pagination, or default behavior, making it incomplete for an agent.
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 add meaning. It mentions 'elevation range' but does not explain the parameters' units, allowed values, or how they are used, providing only minimal context.
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 biosamples collected within a specific elevation range, using a specific verb and resource. This distinguishes it from sibling tools like get_samples_within_lat_lon_bounding_box and get_samples_by_ecosystem.
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 'perfect for studying altitude-related microbial communities,' providing a use case context, but it does not explicitly state when to use this tool versus alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden of behavioral disclosure. It only states 'retrieve' (read operation) but omits essential traits like pagination (implied by 'max_page_size' parameter but not explained), error handling for invalid IDs, or rate limits. This is insufficient for an agent to invoke safely.
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 sentences with no extraneous information. The purpose is front-loaded, and every word adds value. Excellent structure for quick agent consumption.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It omits crucial context like pagination behavior, response format, error scenarios, and prerequisites (e.g., valid IDs). An agent would lack sufficient information to use this tool correctly.
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%, requiring the description to compensate. It adds minimal value: 'specific fields' hints at 'projection', 'IDs' at 'entity_ids', 'batch' at multiple IDs. But it fails to explain 'collection' or 'max_page_size', leaving their meaning and usage unclear.
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 specific fields from multiple NMDC entities by IDs, with batch and filtering capabilities. It effectively distinguishes from sibling tools like 'get_entity_by_id' and 'get_entity_by_id_with_projection' by emphasizing batch operations and field filtering.
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?
Description explicitly says 'Use this tool for batch operations' and 'retrieve specific fields', providing clear context for when to use. However, it lacks explicit exclusionary guidance or mention of alternatives, which would help disambiguate from similar sibling tools.
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 cover behavior. It only mentions 'retrieve' and 'more efficient' but does not disclose error handling, rate limits, or what happens if entity_id is invalid.
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 sentences, front-loaded with purpose, efficient wording, no redundancy.
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 complexity of three parameters (especially the flexible projection parameter) and no output schema, the description is insufficient. It lacks guidance on projection format, output expectations, and error conditions.
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?
The description does not explain any of the three parameters individually. With schema description coverage at 0%, the burden on the description is high, yet it only refers to 'certain fields' for projection.
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 retrieves specific fields from an NMDC entity by ID, distinguishing it from siblings like get_entity_by_id (full entity) and get_entities_by_ids_with_projection (multiple entities).
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?
Indicates efficiency when only certain fields are needed, implying when to use it over the full entity tool. However, it does not explicitly state when not to use or mention alternatives by name.
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 indicates the tool is read-only by stating it 'gets' statistics and 'helps understand', but does not disclose specific behavioral traits like authentication or rate limits. It is adequate but not detailed.
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 sentences with no wasted words. The main action is front-loaded in the first sentence. Perfectly concise for the tool's simplicity.
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?
No output schema exists, so the description should explain return values. It mentions 'document counts' and 'size and scope', but is vague about other statistics. Sufficient for a simple tool but not fully detailed.
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 no parameters, and schema description coverage is trivially 100%. Per the baseline rule, zero parameters yields a score of 4. The description adds no param info beyond the schema, 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 gets statistics about NMDC collections including document counts, with a specific verb 'get' and resource 'collection statistics'. It distinctively differs from sibling tools that fetch specific entities 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this tool to get statistics' but does not provide guidance on when to use alternatives or when not to use it. Usage is implied but lacks explicit context for selection among sibling 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?
Without annotations, the description must disclose behavior. It states it returns a list of collection names with examples, which is adequate for a read-only query. It does not cover ordering or uniqueness, but the simplicity mitigates 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 two sentences with no wasted words. It is front-loaded with purpose and provides a concrete example of expected output.
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 no parameters or output schema. The description covers what the tool does and what it returns, sufficient for an agent to use it correctly. Minor gaps (e.g., no mention of sorting) are acceptable given the tool's trivial nature.
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 no parameters, so schema coverage is 100%. Baseline is 4; the description adds value by clarifying the output format (list of names) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: discovering available data types in the NMDC database by returning collection names. It distinguishes from siblings like get_all_collection_ids (IDs vs names) and get_collection_stats (stats vs names).
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 explicitly says 'Use this tool to discover what types of data are available', which implies when to use. However, it does not mention when not to use or provide alternatives (e.g., get_all_collection_ids for IDs), limiting 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?
Describes default behavior ('downloads the entire GFF file by default') and parameter effect (sample_bytes limits download). No annotations exist, so the description carries the burden. It lacks details on side effects, error conditions, or mutability, but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a third for a parameter nuance. Front-loaded with purpose, no wasted 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?
Given no output schema, few annotations, and four parameters with no schema descriptions, the description provides a clear usage narrative and parameter guidance. Missing return value structure, but the purpose is well explained.
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?
With 0% schema coverage, the description adds significant meaning: explains data_object_id comes from previous search, pfam_domain_ids are the domains, max_rows default, and sample_bytes for limiting download. This compensates 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's purpose: to analyze GFF files for PFAM domains and show genomic locations. It also specifies a usage order (after get_samples_by_annotation), distinguishing it from siblings that may return data objects without genomic context.
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 (after get_samples_by_annotation) and when to use the sample_bytes parameter ('Only use sample_bytes parameter if you specifically need to limit download size').
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 compensates well by stating it returns 'COMPLETE biosample records including all data objects (GFF files, protein files, etc.) with their IDs and URLs.' It also explains required ID formats. However, it lacks details on default behavior when max_records is null and does not mention offset handling.
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-front-loaded with the primary purpose, and each subsequent sentence adds value (usage guidelines, parameter behavior, chaining with other tools). It could be slightly shorter by combining some sentences, 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 no output schema, the description explains the return structure (complete records with data objects). It covers the main use case and mentions chaining with a sibling tool. Missing details on pagination (offset and limit behavior) are minor, but the description is largely complete for an 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?
Schema coverage is 0%, so the description adds meaning for 'gene_function_ids' (required formats) and 'max_records' (use instead of limit). It also clarifies not to use 'limit'. However, it does not explain 'offset' and 'limit' defaults, leaving some gaps.
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 biosamples with specific functional annotations, specifying the resource ('biosamples') and verb ('find'). It distinguishes from siblings like 'get_samples_by_ecosystem' and 'get_biosamples_for_study' by focusing on functional annotations.
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 usage guidance: 'ALWAYS set max_records to match the user's request', advises against using 'limit', gives required formats for identifiers, and directs when to follow up with 'fetch_and_filter_gff_by_pfam_domains' for genomic locations.
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:

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

Score Badge

Copy to your README.md:

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

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