Skip to main content
Glama
ber-data

bertron-mcp

by ber-data
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

bertron-mcp

A Model Context Protocol (MCP) server providing access to the BERtron API, which aggregates genomic and environmental data from multiple Biological and Environmental Research (BER) data sources including EMSL, ESS-DIVE, JGI, MONET, and NMDC.

Quick Start

Install and run directly from GitHub

# Run directly without installing
uvx --from git+https://github.com/ber-data/bertron-mcp.git bertron-mcp

# Or install first, then run
uvx --from git+https://github.com/ber-data/bertron-mcp.git bertron-mcp --version

Related MCP server: BioMCP

Features

  • 🔍 Geospatial Search: Find entities within a specified radius of geographic coordinates

  • 💊 Health Check: Verify BERtron API connectivity and database status

  • 🌍 Multi-Source Data: Access data from major BER research facilities

  • 🔌 MCP Integration: Seamless integration with Claude, Goose, and other MCP-compatible AI tools

Requirements

Installation

From Source (Development)

git clone https://github.com/ber-data/bertron-mcp.git
cd bertron-mcp
make dev

From PyPI (Coming Soon)

pip install bertron-mcp

Available Tools

geosearch

Search for entities within a specified distance of geographic coordinates.

Parameters:

  • latitude (float): Latitude coordinate (-90.0 to 90.0)

  • longitude (float): Longitude coordinate (-180.0 to 180.0)

  • search_radius_km (float, optional): Search radius in kilometers (default: 1.0)

Returns: QueryResponse with entities, count, and metadata

bbox_search

Search for entities within a rectangular geographic bounding box.

Parameters:

  • southwest_lat (float): Southwest corner latitude (-90.0 to 90.0)

  • southwest_lng (float): Southwest corner longitude (-180.0 to 180.0)

  • northeast_lat (float): Northeast corner latitude (-90.0 to 90.0)

  • northeast_lng (float): Northeast corner longitude (-180.0 to 180.0)

Returns: QueryResponse with entities within the bounding box

entity_lookup

Retrieve detailed information for a specific entity by its unique ID.

Parameters:

  • entity_id (string): Unique identifier of the entity (e.g., "nmdc:bsm-12-abc123")

Returns: Entity object with complete metadata

advanced_query

Execute complex MongoDB queries with filtering, projection, and sorting.

Parameters:

  • filter_dict (dict, optional): MongoDB filter criteria (e.g., {"entity_type": "sample"})

  • projection (dict, optional): Fields to include/exclude (e.g., {"name": 1, "coordinates": 1})

  • skip (int, optional): Number of documents to skip for pagination (default: 0)

  • limit (int, optional): Maximum number of documents to return (default: 100)

  • sort (dict, optional): Sort criteria (e.g., {"name": 1} for ascending)

Returns: QueryResponse with matching entities

search_by_source

Find entities from a specific BER data source.

Parameters:

  • source (string): BER data source name (EMSL, ESS-DIVE, JGI, NMDC, MONET)

Returns: QueryResponse with entities from the specified source

search_by_type

Find entities of a specific entity type.

Parameters:

  • entity_type (string): Entity type (biodata, sample, sequence, taxon, jgi_biosample)

Returns: QueryResponse with entities of the specified type

search_by_name

Search for entities by name using regex pattern matching.

Parameters:

  • name_pattern (string): Name pattern to search for (supports regex)

  • case_sensitive (bool, optional): Whether search should be case sensitive (default: False)

Returns: QueryResponse with entities matching the name pattern

health_check

Check the health status of the BERtron API.

Parameters: None

Returns: Dictionary with web_server and database boolean status

API Limits and Constraints

To prevent overwhelming responses and protect system resources, the following limits are enforced:

Default Limits

  • Default result limit: 100 items per query

  • Maximum result limit: 1,000 items per query

  • Maximum pagination offset: 50,000 items

Constraint Reporting

When limits are applied, tools automatically report constraints in the response metadata:

{
  "entities": [...],
  "count": 1000,
  "metadata": {
    "constraints_applied": {
      "requested_limit": 5000,
      "actual_limit": 1000,
      "reason": "Exceeded maximum limit of 1000"
    }
  }
}

Tools with Limit Parameters

The following tools accept optional limit parameters:

  • search_by_source(source, limit=100)

  • search_by_type(entity_type, limit=100)

  • search_by_name(name_pattern, case_sensitive=False, limit=100)

  • advanced_query(filter_dict=None, limit=100, skip=0, ...)

Safety Features

  • advanced_query requires filter criteria to prevent accidental full database dumps

  • All limits are enforced server-side with automatic constraint reporting

  • Deep pagination (skip > 50,000) is blocked to prevent performance issues

Setup

Development

Install dependencies for development:

make dev

Testing

Run the complete test suite:

make all

Test specific components:

# API integration tests
make test-integration

# MCP protocol tests  
make test-mcp
make test-mcp-extended

# Test with Claude CLI
make test-claude-mcp

# Version check
make test-version

MCP Integration

Claude Desktop Configuration

Option 1: From GitHub (Recommended) Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "bertron-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/ber-data/bertron-mcp.git", "bertron-mcp"]
    }
  }
}

Option 2: Local Development Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "bertron-mcp": {
      "command": "uv",
      "args": ["run", "python", "src/bertron_mcp/main.py"],
      "cwd": "/path/to/bertron-mcp"
    }
  }
}

Claude Code MCP Setup

From GitHub:

claude mcp add bertron-mcp "uvx --from git+https://github.com/ber-data/bertron-mcp.git bertron-mcp"

Local development:

claude mcp add -s project bertron-mcp uv run python src/bertron_mcp/main.py

Production (after publishing to PyPI):

claude mcp add -s project bertron-mcp uvx bertron-mcp

Goose Setup

From GitHub:

goose session --with-extension "uvx --from git+https://github.com/ber-data/bertron-mcp.git bertron-mcp"

Local development:

goose session --with-extension "uv run python src/bertron_mcp/main.py"

Usage Examples

Using with Claude

Search for genomic samples near Orlando, FL within 100km radius:
> Use the bertron-mcp to search for entities near latitude 28.5383, longitude -81.3792 within 100km

Search for entities in a bounding box covering Yellowstone National Park:
> Use bbox_search to find entities between southwest corner (44.0, -125.0) and northeast corner (49.0, -110.0)

Find all NMDC sample entities:
> Search for all sample entities from the NMDC data source

Look up detailed information for a specific entity:
> Use entity_lookup to get details for entity ID "nmdc:bsm-12-abc123"

Direct MCP Protocol

# Test geosearch tool
echo '{"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "geosearch", "arguments": {"latitude": 28.5383, "longitude": -81.3792, "search_radius_km": 100.0}}, "id": 1}' | uv run python src/bertron_mcp/main.py

# Test bounding box search
echo '{"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "bbox_search", "arguments": {"southwest_lat": 44.0, "southwest_lng": -125.0, "northeast_lat": 49.0, "northeast_lng": -110.0}}, "id": 2}' | uv run python src/bertron_mcp/main.py

# Test search by data source
echo '{"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "search_by_source", "arguments": {"source": "NMDC"}}, "id": 3}' | uv run python src/bertron_mcp/main.py

# Test advanced query with filtering
echo '{"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "advanced_query", "arguments": {"filter_dict": {"entity_type": "sample"}, "limit": 10}}, "id": 4}' | uv run python src/bertron_mcp/main.py

Development

Code Quality

# Format and lint code
make format
make lint

# Type checking
make mypy

# Dependency analysis
make deptry

Building and Publishing

# Build package
make build

# Full release workflow
make release

Data Sources

BERtron aggregates data from:

  • EMSL - Environmental Molecular Sciences Laboratory

  • ESS-DIVE - ESS Data and Information for Virtual Ecosystems

  • JGI - Joint Genome Institute

  • MONET - Molecular Observation Network

  • NMDC - National Microbiome Data Collaborative

Contributing

  1. Fork the repository

  2. Create a feature branch: git checkout -b feature/your-feature

  3. Make changes and add tests

  4. Run the test suite: make all

  5. Commit your changes: git commit -m "Add your feature"

  6. Push to the branch: git push origin feature/your-feature

  7. Submit a pull request

License

BSD-3-Clause

Available Tools

8 tools
advanced_queryAdvanced Database QueryB

Execute sophisticated searches with custom filters, field selection, pagination, and sorting options

ParametersJSON Schema
NameRequiredDescriptionDefault
filter_dictNo
projectionNo
skipNo
limitNo
sortNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
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 implies a read-only query operation but does not explicitly state that it is non-destructive, nor does it mention rate limits, authentication needs, or other behavioral traits. It adds minimal value beyond the name.

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 sentence that efficiently enumerates key capabilities without extraneous words. It is front-loaded and fits within a standard length.

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?

While an output schema exists (reducing need to describe returns), the description lacks details on parameter usage, constraints, or error conditions. Given the tool has five parameters with no schema descriptions, more information would improve completeness. It is minimally adequate.

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 five parameters have no inline descriptions. The description lists 'custom filters, field selection, pagination, and sorting options,' which loosely map to filter_dict, projection, skip/limit, and sort respectively, providing some semantic link. However, it does not explain parameter formats or constraints, leaving gaps.

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 performs sophisticated searches with custom filters, field selection, pagination, and sorting, indicating a general-purpose query tool. However, it does not explicitly differentiate itself from sibling tools like search_by_name or bbox_search, which could lead to ambiguity.

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 scenarios or prerequisites, leaving the agent to infer usage without explicit direction.

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

entity_lookupSample Details LookupA

Get comprehensive metadata for a specific biological sample or dataset using its unique identifier

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'Get' implying a read-only operation, but does not disclose any behavioral traits such as authentication requirements, rate limits, error handling for invalid IDs, or output characteristics beyond the existence of an output schema. This is insufficient for a tool with zero annotation coverage.

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 sentence that is concise and front-loaded with the key action and resource. No filler or redundant information.

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 the low complexity (one required parameter, output schema exists), the description covers the basic purpose and usage. However, it lacks details on error scenarios (e.g., invalid ID), what 'comprehensive metadata' includes, and any behavioral context (like rate limits or authentication), making it minimally complete but with gaps.

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 input schema has one parameter 'entity_id' with 0% schema description coverage. The description only mentions 'using its unique identifier', which adds no meaning beyond the parameter name. The description does not compensate by explaining format, constraints, or valid values, leaving the agent to guess.

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 'comprehensive metadata for a specific biological sample or dataset', and the method 'using its unique identifier'. It distinguishes from sibling search tools like search_by_name or search_by_type, which do not use a unique identifier.

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 clearly implies usage when a unique identifier is available and comprehensive metadata is needed. The context of sibling tools (search, query) provides implicit when-not-to-use guidance, but there is no explicit exclusion or alternative mentioned. This is clear context without exclusions.

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

geosearchGeographic Sample SearchC

Find genomic and environmental samples near any location on Earth using latitude/longitude coordinates

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes
longitudeYes
search_radius_kmNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

With empty annotations, the description carries full burden for disclosing behavioral traits. It does not mention side effects, rate limits, authentication, pagination, or result limitations, leaving significant unknowns.

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 a single sentence, which is concise but lacks structure. It could be improved with bullet points or clearer separation of purpose from usage details. It is not overly verbose but misses opportunities for clarity.

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 3 parameters and an output schema, the description is too sparse. It does not explain expected inputs, output structure, or limitations. It fails to provide a complete picture for the 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.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should explain what each parameter means and how to use them. However, it only reiterates the tool's purpose without detailing the inputs (e.g., coordinate format, radius range), adding no value beyond the schema.

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: finding genomic/environmental samples near any location using coordinates. It is informative but does not explicitly differentiate from sibling tools like bbox_search, which might also perform geographic searches.

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. The description lacks any context about preferred scenarios, prerequisites, or exclusions, making it difficult for an agent to decide when to select this tool.

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

health_checkAPI Health StatusA

Verify that the BERtron API and database are online and responding correctly

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden of transparency. It clearly states the tool checks online status and correct response, which is sufficient for a simple health check. No side effects are expected.

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 sentence with no unnecessary words. It is front-loaded and 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?

For a simple no-parameter tool with an output schema, the description is mostly complete. It could mention what the output looks like, but that is presumably covered by the output schema.

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 description coverage is 100% (trivially). The description adds meaning by explaining the tool's purpose beyond the empty schema, earning a baseline of 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 uses a specific verb ('Verify') and clearly identifies the resource ('BERtron API and database'). It is unambiguous and distinguishes well from sibling tools which focus on data queries.

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 checking system status, but does not explicitly state when to use this tool versus alternatives (e.g., before starting queries). 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.

search_by_nameText Search by Name/DescriptionC

Search through sample names, project titles, and descriptions using text patterns and keywords

ParametersJSON Schema
NameRequiredDescriptionDefault
name_patternYes
case_sensitiveNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
entitiesYes
countYes
query_typeNo
metadataNo

TDQS

C2.6/5.0
Behavior2/5

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

Annotations are empty, so description carries full burden. It mentions text pattern matching but does not explain default values for case_sensitive and limit, or behavior like wildcards, pagination, or ordering.

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?

A single sentence, concise and to the point. Could be slightly improved by adding parameter context 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?

With 3 parameters and no annotations, the description lacks details on pattern syntax, default behavior, and output format. Incomplete for effective use.

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 has 0% parameter description coverage. Description does not explain any parameter beyond the general concept of text patterns; case_sensitive and limit are not addressed.

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 searches across sample names, project titles, and descriptions using text patterns. The name and title support this, but it does not differentiate from sibling search tools like search_by_source or search_by_type.

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 like advanced_query or search_by_source. No instructions on prerequisites or limitations.

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

search_by_sourceSearch by Research FacilityB

Find samples and datasets from specific DOE research facilities (EMSL, ESS-DIVE, JGI, NMDC, MONET)

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYes
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

No annotations exist, so description must carry the burden of behavioral traits. It does not disclose any side effects, auth needs, rate limits, or behavior when source is invalid. It only lists example facilities without confirming they are exhaustive.

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 sentence that directly states the tool's purpose. It is concise and front-loads the action, with no redundant information.

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 the tool has two simple parameters and an output schema, the description is somewhat complete but lacks details on valid source values and limit usage. It would benefit from clarifying the exact input format for source.

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 description adds partial meaning by listing example facility codes for the source parameter, but does not clarify if these are the only valid values or explain the limit parameter. Schema coverage is 0%, so the description partially compensates but is insufficient.

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 the tool finds samples and datasets from specific DOE research facilities, listing examples (EMSL, ESS-DIVE, etc.). It distinguishes from siblings like search_by_name and bbox_search by focusing on source/facility.

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. It does not mention that it should be used when the user knows the facility name or that other tools handle different criteria.

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

search_by_typeSearch by Data TypeA

Find specific types of biological or environmental data (samples, sequences, biodata, taxa)

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_typeYes
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description fails to disclose behavioral traits such as whether the operation is read-only, pagination behavior, or error handling. It only states the basic function, missing details that help an agent anticipate side effects or constraints.

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, clear sentence with no filler. Every word adds value, and the core information is presented upfront, making it easy for an agent to parse quickly.

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?

The description is adequate given the output schema (which documents return values) and low parameter count. However, it lacks details on pagination, valid entity types, and does not reference sibling tools to guide selection, leaving some 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?

The schema has 0% description coverage, but the description adds meaning to 'entity_type' by listing example values (samples, sequences, biodata, taxa). However, 'limit' is not explained, and the description does not clarify that entity_type may be an enumeration or free text, leaving ambiguity.

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 find specific types of biological or environmental data, listing examples like samples, sequences, biodata, and taxa. This distinguishes it from siblings like search_by_name or search_by_source, which filter by other criteria.

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 the tool is for searching by type but provides no explicit guidance on when to use it versus alternatives (e.g., advanced_query, bbox_search). It does not mention when not to use it or specify any prerequisites, leaving the agent to infer usage from context.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation3/5

The specific search tools (bbox_search, geosearch, search_by_name, etc.) each target distinct criteria, but the generic advanced_query tool overlaps with all of them, creating potential confusion for tool selection.

Naming Consistency2/5

Tool names use a mix of patterns: adjective_noun (advanced_query), abbreviation_noun (bbox_search), noun_verb (entity_lookup, health_check), and verb_preposition_noun (search_by_name, etc.), with no consistent convention.

Tool Count5/5

8 tools is an appropriate scope for a query-focused data server; not too many or too few.

Completeness4/5

The server covers a wide range of query methods (text, location, facility, type) and includes a health check, but lacks tools for discovering available sources or types without a specific query, and does not include any write operations.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • BioMCP

    yeyuan98
    A
    license
    A
    quality
    A
    maintenance
    A high-performance MCP server that gives LLMs access to 25 biomedical tools federated across 50+ upstream APIs for genes, variants, drugs, diseases, literature, clinical trials, and structural biology.
    41
    2,054
    2
    Apache 2.0

  • genefoundry

    berntpopp
    A
    license
    Not graded
    quality
    A
    maintenance
    Federates 13 gene-related MCP backends (gnomAD, GTEx, etc.) behind a single Streamable HTTP endpoint with collision-free namespacing and search-based tool discovery.
    2
    MIT

  • geopera-mcp

    geo-pera
    A
    license
    C
    quality
    C
    maintenance
    MCP server for the Geopera geospatial data platform that enables AI agents to discover imagery, place and manage orders, and run analytics using the same API as other Geopera clients.
    100
    MIT

Latest Blog Posts

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/ber-data/bertron-mcp'

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