Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BacDive MCP Server Find Escherichia coli strains and show their culture conditions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
BacDive (Bacterial Diversity Metadatabase) is an online database developed and maintained by the German Collection of Microorganisms and Cell Cultures (DSMZ). The >80,000 bacterial and archaeal strains are catalogued in BacDive with detailed information covering physiology, morphology, taxonomy, culture conditions, metabolism, enzymology activities, antibiotic resistance, sequences, and many more.
This project is an MCP (Model Context Protocol) server that enables AI large language models (such as Claude) to directly query and retrieve data from the BacDive database. Through this MCP server, the AI assistants can:
🔍 Search for strains by species or genus name
📋 Retrieve full strain details by BacDive ID
🧫 Search for culture media by name or ID
🧬 Search for 16S rRNA or genome sequences
📖 Perform free-text searches across the entire taxon database
Related MCP server: scopus-mcp
Feature | Description |
Strain Search | Search strains by species name (e.g., Escherichia coli) or genus name |
Full-text Search | Search taxa by any keyword (e.g., "thermophilic", "spore-forming", "nitrogen-fixing") |
Strain Details | Retrieve full strain information by BacDive ID (taxonomy, morphology, culture conditions, metabolism, enzymology, resistance, safety, etc.) |
DSM Number Search | Search by DSMZ strain number (e.g., DSM 3) |
Culture Medium Search | Search culture media by name or retrieve full composition by ID |
16S rRNA Search | Search 16S rRNA gene sequences by species/genus |
Genome Search | Search genome sequences by species/genus |
Browse All | Paginated browsing of all taxa in BacDive |
Health Check | Check BacDive API connectivity |
TypeScript implementation with type safety
Uses Node.js native https module —zero external HTTP dependencies
Communicates with MCP clients via standard size transport
Compatible with any MCP client (Claude Desktop, Cursor, etc.)
Node.js >= 18.0.0
npm or yarn or pnpm (any one)
# Clone or download this project locally
cd BacDive-MCP
# Install dependencies
npm install
# Compile TypeScript
npm run buildAfter compilation, the runnable file will be at dist/index.js.
npm run build
npm link
# Now you can run it globally
bacdive-mcpAdd the BacDive MCP server to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"bacdive-mcp": {
"command": "node",
"args": [
"C:/your/path/to/BacDive-MCP/dist/index.js"
]
}
}
}Tip: Replace
C:/your/path/to/BacDive-MCP/dist/index.jswith your actual project path.
Add to Cursor's MCP settings:
{
"mcpServers": {
"bacdive-mcp": {
"command": "node",
"args": [
"C:/your/path/to/BacDive-MCP/dist/index.js"
]
}
}
}Any MCP-compatible client can connect to this server via stdeo. The server startup command is:
node dist/index.js# Build
npm run build
# Start the server (communicates via stdin/stdout)
npm startThis MCP server provides the following 10 tools:
bacdive_search_strain — Strain SearchSearch for strains by species and/or genus name.
Parameters:
Parameter | Type | Required | Description |
| string | one of two | Full or partial species name (e.g., |
| string | one of two | Full or partial genus name (e.g., |
| number | no | Page number, default 1 |
Example call:
{
"species": "Escherichia coli",
"page": 1
}bacdive_search_taxon — Full-text SearchSearch across the entire taxon database with free text.
Parameters:
Parameter | Type | Required | Description |
| string | yes | Search query (e.g., |
| number | no | Page number, default 1 |
bacdive_get_strain_by_id — Get Strain DetailsRetrieve full strain information by BacDive ID.
Parameters:
Parameter | Type | Required | Description |
| number | yes | BacDive strain ID (e.g., |
Returned content includes:
General information (DSMZ strain number, accession, dates, etc.)
Name & taxonomic classification (species, genus, family, order, class, phylum, domain, full name, LPSN, synonyms, etc.)
Morphology
Culture and growth conditions
Physiology and metabolism
Enzyme activities
Antibiotic resistance
Safety information
Applications
References
Sequence information (16S rRNA gene, genome)
External links
bacdive_search_by_dsm_number — Search by DSM NumberSearch for a strain by its DSMZ strain number.
Parameters:
Parameter | Type | Required | Description |
| string | yes | DSMZ strain number (e.g., |
bacdive_browse_taxa — Browse All TaxaBrowse all taxa in the BacDive database with pagination.
Parameters:
Parameter | Type | Required | Description |
| number | no | Page number, default 1 |
bacdive_search_culture_medium — Search Culture MediaSearch for culture media by name.
Parameters:
Parameter | Type | Required | Description |
| string | yes | Full or partial medium name (e.g., |
| number | no | Page number, default 1 |
bacdive_get_culture_medium_by_id — Get Culture Medium DetailsRetrieve full culture medium information by DSMZ medium ID.
Parameters:
Parameter | Type | Required | Description |
| number | yes | DSMZ medium ID (e.g., |
bacdive_search_16s — Search 16S rRNA SequencesSearch for 16S rRNA gene sequences by species or genus name.
Parameters:
Parameter | Type | Required | Description |
| string | one of two | Species name |
| string | one of two | Genus name |
| number | no | Page number, default 1 |
bacdive_search_genome — Search GenomesSearch for genome sequences by species or genus name.
Parameters:
Parameter | Type | Required | Description |
| string | one of two | Species name |
| string | one of two | Genus name |
| number | no | Page number, default 1 |
bacdive_ping — Health CheckCheck BacDive API connectivity.
Parameters: None
Here are some natural language conversation examples when using Claude Desktop:
User: Help me search for E. coli (Escherichia coli) in the BacDive database.
AI Assistant: (Calls the
bacdive_search_straintool and returns matching results)
User: For the strain with BacDive ID 2, give me its complete culture conditions and metabolism info.
AI Assistant: (Calls
bacdive_get_strain_by_idand extracts culture conditions and metabolism data)
User: I need to culture a Bacillus subtilis strain. Help me find the Nutrient medium recipe.
AI Assistant: (Calls
bacdive_search_culture_mediumand returns the medium recipe)
User: Find thermophilic bacteria in BacDive.
AI Assistant: (Calls
bacdive_search_taxonwith query "thermophilic")
BacDive-MCP/
├── src/
│ ├── index.ts # Entry point, starts MCP server
│ ├── server.ts # MCP server core, tool definitions and handlers
│ └── bacdive-client.ts # BacDive API client
├── examples/
│ └── claude_desktop_config.json # Claude Desktop config example
├── package.json # Project configuration and dependencies
├── tsconfig.json # TypeScript compilation config
├── .env.example # Environment variables example
├── .gitignore
├── README.md # English documentation (this file)
├── README_CN.md # Chinese documentation
└── LICENSE # MIT License# Install dependencies
npm install
# Watch mode compilation (optional)
# Use tsc --watch
# Build
npm run build
# Run
npm start
# Type check (no output files)
npm run lintAdd a new tool definition in the TOOLS array in src/server.ts
Add a corresponding case branch in the handleToolCall function
Add the corresponding API client method in src/bacdive-client.ts (if needed)
Rebuild and run
bacdive-client.ts: Wraps BacDive REST API HTTP calls with type-safe methods. Uses Node.js built-in https module — no external dependencies needed.
server.ts: Defines MCP tool metadata (name, description, input schema) and handlers. Routes tool calls to the appropriate BacDiveClient methods.
index.ts: Entry point — creates the client, server, and stdio transport, then starts the service.
BacDive REST API documentation:
Homepage: https://bacdive.dsmz.de/
API base path: https://api.bacdive.dsmz.de/api/v1/
Main endpoints:
GET /taxon/ — Taxon search
GET /strain/{id}/ — Strain details
GET /culturemedium/ — Culture medium search
GET /culturemedium/{id}/ — Culture medium details
GET /sequence_16s/ — 16S rRNA search
GET /genome/ — Genome search
BacDive (https://bacdive.dsmz.de/) is a bacterial diversity metadatabase maintained by DSMZ, containing detailed descriptions of over 80,000 strains covering taxonomy, morphology, physiology, ecology, molecular biology, and more. The database is publicly accessible and is an important resource for microbiological research.
Disclaimer: This project is an independent, unofficial MCP server wrapper for the BacDive API. All BacDive data and the BacDive API are owned and operated by DSMZ. For official information, please visit https://bacdive.dsmz.de/.
Browse all taxa in the BacDive database with pagination. This is useful for systematically exploring the database or getting an overview of available strains. Each page contains up to 50 taxa.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose pagination and a concrete page-size ceiling ('up to 50 taxa'), which is useful, but it omits return structure, ordering, and any read-only/auth context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with purpose and free of filler; each sentence adds a distinct fact (purpose, usage, page size).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter browse tool, the description covers purpose, usage, and pagination adequately. However, with no output schema and no annotations, it never describes what a returned taxon page contains or the ordering, leaving a meaningful return-value gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single page parameter, including default and minimum, so the baseline is 3. The description adds the page-size fact ('up to 50 taxa'), which slightly enriches pagination semantics but does not document the parameter itself beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Browse all taxa in the BacDive database') with scope (all taxa, pagination). It implies a contrast with sibling search tools like bacdive_search_taxon but never names an alternative, so an agent gets no explicit routing cue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as useful for 'systematically exploring the database or getting an overview of available strains', giving clear context for when to choose it. It stops short of naming alternatives or stating when not to use it, so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed information about a specific culture medium from BacDive using its numeric DSMZ medium ID. Returns the full medium composition, growth conditions, and citation.
| Name | Required | Description | Default |
|---|---|---|---|
| medium_id | Yes | The numeric DSMZ medium ID (e.g. 1, 5, 196). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses what is returned (full composition, growth conditions, citation), which is valuable since there is no output schema, but it says nothing about error handling for bad IDs, rate limits, or authentication needs. Adequate but incomplete for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the identity of the resource and its lookup key are front-loaded, followed by the return payload. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description covers the essentials: what it fetches, by what key, and what is returned. The only gap is the absence of any error or failure-mode guidance, which keeps it short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single required parameter is documented in the schema with its type, minimum, and examples. The description restates 'numeric DSMZ medium ID' but adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (retrieve) and resource (culture medium) and identifies the lookup key as the numeric DSMZ medium ID, which implicitly separates it from the sibling search tool. It does not explicitly name bacdive_search_culture_medium as the alternative, so the differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage condition is implied: use this when you already hold a numeric DSMZ medium ID, versus searching when you don't. There is no explicit 'use X instead when Y' routing and no statement of prerequisites or behavior on invalid/nonexistent IDs, so the guidance remains at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full detailed information about a specific strain from BacDive using its numeric BacDive ID. This returns comprehensive data including: general information, name and taxonomic classification, morphology, culture and growth conditions, physiology and metabolism, enzyme activities, antibiotic resistance, safety information, applications, references, sequence information (16S rRNA gene, genome), and external links.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The numeric BacDive ID of the strain (e.g. 2 for Bacillus subtilis subsp. subtilis str. 168). You can find this ID from search results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the breadth of the returned record (taxonomy, morphology, physiology, sequence data, external links), which is genuinely useful since there is no output schema, but it says nothing about permissions, rate limits, or what happens when an ID does not exist. 'Retrieve' implies a safe read, but that is inference, not disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource. The second sentence is a long enumeration, but since no output schema exists, that list earns its place by telling the agent what the call will return.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema and no annotations, the description supplies the two things an agent most needs: the lookup key and the shape of the response. The only real gap is error behavior for an invalid or missing ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself documents the single parameter with a concrete example ('2 for Bacillus subtilis subsp. subtilis str. 168'). The description only restates that the ID is numeric and BacDive-specific, adding no syntax or range detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve full detailed information about a specific strain') and pins the lookup key ('numeric BacDive ID'), which separates it from the search_* siblings that take query terms rather than an ID. It stops short of naming a sibling or stating the search-then-fetch workflow, so differentiation is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using its numeric BacDive ID' hints that this is a follow-up to a search, but the description never states when to use this tool versus bacdive_search_strain or bacdive_search_by_dsm_number, nor any exclusions. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the connectivity and availability of the BacDive API. Returns a boolean indicating whether the BacDive API is currently reachable. Use this to diagnose connection issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses the observable behavior an agent needs: a boolean success/reachability result and the diagnostic intent. It does not mention timeout, latency, or auth requirements, which are minor gaps for a zero-parameter health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what it does, then the return type, then the intended use. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description compensates by stating the boolean return value and its meaning. For a zero-param connectivity check, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema offers nothing to interpret; per the baseline for zero-param tools, a 4 applies. The description correctly implies no inputs are required to perform the check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource pair (check connectivity/availability of the BacDive API) and explicitly names the return value. Every sibling tool is a data-retrieval operation (search/get/browse), so a diagnostic ping is unambiguous without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the use case: 'Use this to diagnose connection issues.' That tells the agent when to reach for this tool rather than a search/get sibling. It stops short of stating when not to use it, but the diagnostic framing is clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for 16S rRNA gene sequences in the BacDive database by species or genus name. 16S rRNA gene sequences are the gold standard for bacterial phylogenetic identification and taxonomy.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| genus | No | Genus name (e.g. 'Bacillus'). Optional if species is provided. | |
| species | No | Species name (e.g. 'Escherichia coli'). Optional if genus is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Search' weakly implies a read-only operation, but nothing is said about pagination limits, whether results are raw sequences or strain-linked records, result caps, or rate limits. The second sentence is educational framing rather than behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence with no waste. The second sentence about phylogenetic identification is padding that does not help an agent invoke the tool correctly, so the definition is not maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter search with fully documented schema fields, purpose and inputs are adequately covered. However, with no output schema and no annotations, the description should still say what a result looks like and how paging behaves; those gaps leave the agent guessing about the return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description confirms the species/genus name axis, which matches the schema's own field descriptions and examples, but adds no syntax, format, or matching-semantics detail beyond what structured data already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search for 16S rRNA gene sequences in the BacDive database') plus the input axis (species or genus name). The 16S rRNA resource is distinctive enough that an agent can separate it from siblings like bacdive_search_genome or bacdive_search_taxon, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the search keys but gives no when-to-use guidance, no exclusions, and no routing against the other nine bacdive_search_* tools. The phylogenetic 'gold standard' sentence is domain rationale, not an invocation condition, so the agent must infer when 16S is preferable to genome or strain search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a strain in BacDive by its DSMZ strain number (e.g. 'DSM 3', 'DSM 10'). DSMZ numbers are the accession identifiers used by the German Collection of Microorganisms and Cell Cultures. Returns the matching taxon entry.
| Name | Required | Description | Default |
|---|---|---|---|
| dsm_number | Yes | The DSMZ strain number to search for (e.g. 'DSM 3', '3', 'DSM 10'). The 'DSM ' prefix is optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully defines what a DSMZ number is and discloses the return shape ('matching taxon entry'), but omits match semantics (exact vs. fuzzy), not-found behavior, and any permission/rate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, followed by a useful definition of DSMZ numbers and the return type. Three short sentences with minimal waste, though the identifier-definition sentence is somewhat expendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search with no output schema, the description is adequate: it defines the input identifier and states the return. It stops short of covering not-found behavior or routing versus sibling search tools, which a complete definition would address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single parameter with the same examples ('DSM 3', 'DSM 10', optional prefix). The description's examples duplicate the schema rather than adding syntax or edge-case meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (search) and resource (strain) qualified by the identifier type (DSMZ strain number), so an agent knows exactly what this returns. It lacks explicit differentiation from the sibling bacdive_search_strain, leaving the boundary ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no alternative named, despite multiple overlapping search siblings (bacdive_search_strain, bacdive_search_taxon). The agent must infer when this is preferable to a general strain search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for culture media in the BacDive database by medium name. Returns details about culture media including composition, growth conditions, and citation. Useful when you need to find how to cultivate specific microorganisms.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| medium_name | Yes | Full or partial culture medium name to search for (e.g. 'Nutrient', 'LB', 'Trypticase Soy'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully describes what is returned (composition, growth conditions, citation), which is more than the schema offers, but says nothing about pagination behavior, result caps, matching semantics (partial vs exact), or any auth constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action and the search key. Slight redundancy in repeating 'culture media' across sentences, but no filler worth cutting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search with two fully documented parameters and no output schema, the description covers purpose, return content, and intended use. Only pagination/matching behavior is unaddressed, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters are documented with examples ('Nutrient', 'LB', 'Trypticase Soy') and a pagination default. The description only echoes 'by medium name', adding no syntax or matching detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (search culture media) and the BacDive database, plus the search key (medium name). It implicitly contrasts with bacdive_get_culture_medium_by_id (lookup by ID), but never names that sibling, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Useful when you need to find how to cultivate specific microorganisms" gives a use context, but there is no explicit when-to-use-vs-alternative guidance and no mention of when to prefer get_culture_medium_by_id. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for genome sequences in the BacDive database by species or genus name. Returns genome sequence accessions and associated strain information.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| genus | No | Genus name. Optional if species is provided. | |
| species | No | Species name. Optional if genus is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose the return payload (genome sequence accessions plus strain information), which is genuinely useful. However, it says nothing about pagination semantics (page is in schema but behavior is undocumented), result caps, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero padding; the search capability is front-loaded and the return value follows. Structurally clean, though it could be compressed to a single sentence without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, and the description covers return content and query keys but omits pagination behavior and any guidance on how to choose this tool over its eight siblings. Adequate but with clear gaps for a multi-parameter search tool in a crowded namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents species, genus, and page, and the description's 'by species or genus name' merely restates the parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (genome sequences in the BacDive database) plus the query keys (species or genus name). It implicitly separates itself from siblings like search_strain and search_16s, but never names an alternative, so differentiation is only inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what can be searched but gives no when-to-use guidance, no when-not-to-use, and no routing to the many sibling lookup tools (search_strain, search_taxon, get_strain_by_id, etc.). The agent must guess which BacDive search tool fits its intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for bacterial or archaeal strains in the BacDive database by species name, genus name, or both. Returns a paginated list of matching taxa with their taxon IDs, species, genus, family, order, class, phylum, and domain. Use this when looking up strains by their scientific name.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). Each page contains up to 50 results. | |
| genus | No | Full or partial genus name to search for (e.g. 'Bacillus', 'Lactobacillus'). Optional if species is provided. | |
| species | No | Full or partial species name to search for (e.g. 'Escherichia coli', 'coli'). Optional if genus is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the paginated nature and the shape of returned fields, which is genuinely useful, but says nothing about authentication needs, rate limits, result caps, or behavior when both or neither name is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no filler; the purpose and return shape come first and the usage hint last. Slightly padded by the full field enumeration, though that enumeration is doing real work given the absent output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by enumerating returned fields and noting pagination. It is close to complete for a simple search tool, missing only disambiguation from sibling search tools and any safety/permission context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (page, genus, species) are already documented with examples and defaults. The description restates the species/genus combination but adds no syntax or matching semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (bacterial/archaeal strains in BacDive) and the key input dimensions (species, genus, or both). However it does not differentiate itself from close siblings like bacdive_search_taxon or bacdive_browse_taxa, which an agent must disambiguate on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence 'Use this when looking up strains by their scientific name' gives implied usage context, but there is no explicit when-not guidance and no mention of alternatives (e.g. search by DSM number or by ID) despite several competing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a free-text search across the BacDive taxon database. This is useful for searching by physiological traits, morphological characteristics, or any other keywords (e.g. 'thermophilic', 'spore-forming', 'nitrogen-fixing'). Returns a paginated list of matching taxa.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1). | |
| query | Yes | Free-text search query (e.g. 'thermophilic', 'lactobacillus acidophilus', 'Gram-positive cocci'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the operation type (free-text search, implying a read) and the return shape ('paginated list of matching taxa'). It omits any mention of result ranking, limits, or authentication, but for a simple public search it covers the essentials an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a clean front-loaded action, then usage context, then return behavior, and no obvious padding. The 'This is useful for' phrasing is mildly filler, keeping it just short of ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with no output schema and no annotations, the description supplies the query semantics, illustrative examples, and the return format (paginated taxa list), which is enough to call it correctly. Minor gaps remain around result limits and ranking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both 'query' and 'page'. The description's free-text examples largely duplicate the schema's own examples and add no new syntax or formatting detail, making this the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('free-text search across the BacDive taxon database') and the type of query it accepts. It is distinguishable from non-search siblings, but it does not differentiate itself from other search siblings like bacdive_search_strain or bacdive_search_by_dsm_number, so the agent must infer taxon-level vs strain-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context with examples ('thermophilic', 'spore-forming', 'nitrogen-fixing') covering traits and morphology, which tells the agent when this search is appropriate. However, it names no alternatives or exclusions, so the agent gets no help choosing between this and sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0bacdive_browse_taxabacdive_get_culture_medium_by_idbacdive_get_strain_by_idbacdive_pingbacdive_search_16sbacdive_search_by_dsm_numberbacdive_search_culture_mediumbacdive_search_genomebacdive_search_strainbacdive_search_taxonScored across 10 tools
Most tools are cleanly separated by resource and access path (ID lookup vs name search vs browse). However, bacdive_search_strain (by scientific name) and bacdive_search_taxon (free-text) both return taxa lists and could be confused, and search_strain/search_16s/search_genome all take species/genus names, differing only in returned content. Descriptions mitigate this well enough that selection is usually clear.
Every tool follows a consistent bacdive_ prefix plus verb_noun pattern (search_strain, get_strain_by_id, search_culture_medium, browse_taxa). The distinction between search_* and get_*_by_id is applied predictably across resources.
Ten tools is well-scoped for a read-only microbial database covering strains, taxa, media, sequences, and connectivity. Each tool clearly earns its place with no redundancy.
Strong lifecycle coverage: search and ID-based retrieval for strains and media, sequence lookups, browsing, and a ping. Minor gap: there is a bacdive_get_strain_by_id and get_culture_medium_by_id but no get_taxon_by_id, so taxon IDs surfaced by browse/search cannot be directly dereferenced—though strain detail largely compensates.
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
FTIR spectral search and material identification for AI agents via MCP.
Free search across ~35,000 agent tools (x402 bazaar + MCP registry) by plain-language need.
