BioBTree
Server Details
A unified biomedical graph database that integrates 50+ primary data sources — genes, proteins, compounds, diseases, pathways, and clinical data — into a single queryable graph with billions of cross-reference edges. Its native MCP server gives LLMs direct access to structured, authoritative biomedical data, complementing their reasoning with reliable identifiers and up-to-date database content.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
3 toolsbiobtree_entryAInspect
Get full details for one identifier.
SYNTAX: biobtree_entry(identifier="ID", dataset="dataset_name")
USE FOR:
See all attributes of an entry
Discover filterable fields
Get detailed info (sequences, scores, descriptions)
DISCOVER CONNECTIONS: xrefs show what datasets link to this entry
WORKFLOW: Get entry → see xrefs → check EDGES for where they lead → follow relevant paths
RETURNS: All attributes + xref counts to connected datasets
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | The dataset containing the entry | |
| identifier | Yes | The identifier to look up |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Compensates well by disclosing RETURNS structure ('All attributes + xref counts'), explaining the xref/connection graph model, and noting EDGES traversal behavior. Lacks explicit read-only declaration or error handling details.
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?
Perfectly structured with SYNTAX, USE FOR, WORKFLOW, and RETURNS headers. Bold emphasis on 'DISCOVER CONNECTIONS' draws attention to key differentiator. Zero wasted words; every sentence advances understanding of tool capabilities or usage patterns.
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?
Fully compensates for missing output schema by explicitly documenting return structure (attributes + xref counts). Explains the biological database connection model (xrefs, EDGES) necessary to understand results. Complete for a 2-parameter lookup tool with complex relational data.
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?
With 100% schema coverage, baseline is 3. The SYNTAX example adds practical usage context beyond raw schema definitions, showing how to construct the call. Could further clarify valid dataset values or identifier formats, but the example provides meaningful semantic value.
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?
Excellent specificity with 'Get full details for one identifier' (verb + resource + scope). The USE FOR section clearly positions this as a detailed lookup tool versus siblings (biobtree_search for finding, biobtree_map for converting), emphasizing unique capabilities like xref discovery and connection traversal.
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?
Strong workflow guidance ('Get entry → see xrefs → check EDGES') and detailed USE FOR scenarios. Implies this follows a search/discovery step but doesn't explicitly state 'use biobtree_search first to find identifiers' 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.
biobtree_mapAInspect
Map identifiers between databases.
SYNTAX: biobtree_map(terms="ID", chain=">>source>>target")
Chain MUST start with ">>"
Source MUST match input ID type
ID TYPE → SOURCE:
ENSG* → >>ensembl
P*/Q*/O* → >>uniprot
CHEMBL* → >>chembl_molecule
GO:* → >>go
MONDO:* → >>mondo
HP:* → >>hpo
HGNC:* or gene symbols → >>hgnc
SOME DRUG EXPLORATION PATHS:
chembl_molecule>>chembl_target>>uniprot (drug targets)
pubchem>>pubchem_activity>>uniprot (bioactivity)
gtopdb_ligand>>gtopdb_interaction>>gtopdb>>uniprot (curated pharmacology with affinity data)
ensembl>>reactome>>chebi (pathway chemicals - when no direct targets)
Discover more via entry xrefs + EDGES
WARNING - GO terms with high xref_count (>100):
Don't map GO → proteins → drugs (too many results)
Instead: search drug class for condition → verify targets this GO term
DISEASE GENE PATTERNS:
mondo>>gencc>>hgnc (curated)
mondo>>clinvar>>hgnc (variant-based)
DISEASE → DRUG PATTERNS:
mesh>>chembl_molecule (MeSH disease/condition → drugs with indications)
mondo>>clinical_trials>>chembl_molecule (disease → trial drugs)
DISCOVERY APPROACH:
Use biobtree_entry to see xrefs (what's connected)
Use EDGES above to see where each dataset leads
Build chains based on what connections exist for YOUR entity
RETURNS: mapped identifiers with dataset and name
EDGES (what connects to what): ensembl: uniprot, go, transcript, exon, ortholog, paralog, hgnc, entrez, refseq, bgee, gwas, gencc, antibody, scxa hgnc: ensembl, uniprot, entrez, gencc, pharmgkb_gene, msigdb, clinvar, mim, refseq, alphafold, collectri, gwas, dbsnp, hpo, cellphonedb entrez: ensembl, uniprot, refseq, go, biogrid, pubchem_activity, ctd_gene_interaction refseq: ensembl, entrez, taxonomy, ccds, uniprot, mirdb mirdb: refseq transcript: ensembl, exon, ufeature uniprot: ensembl, alphafold, interpro, pdb, ufeature, intact, string, string_interaction, biogrid, biogrid_interaction, chembl_target, go, reactome, rhea, swisslipids, bindingdb, antibody, pubchem_activity, cellphonedb, jaspar, signor, diamond_similarity, esm2_similarity alphafold: uniprot interpro: uniprot, go, interproparent, interprochild chembl_molecule: mesh, chembl_activity, chembl_target, pubchem, chebi, clinical_trials chembl_activity: chembl_molecule, chembl_assay, bao chembl_assay: chembl_activity, chembl_target, chembl_document, bao chembl_target: chembl_assay, uniprot, chembl_molecule pubchem: chembl_molecule, chebi, hmdb, pubchem_activity, pubmed, patent_compound, bindingdb, ctd, pharmgkb pubchem_activity: pubchem, ensembl, uniprot chebi: pubchem, rhea, intact swisslipids: uniprot, go, chebi, uberon, cl lipidmaps: chebi, pubchem dbsnp: hgnc, clinvar, pharmgkb_variant, alphamissense, spliceai clinvar: hgnc, mondo, hpo, dbsnp, orphanet alphamissense: uniprot, transcript gwas: gwas_study, efo, dbsnp, hgnc, mondo gwas_study: gwas, efo, mondo mondo: gencc, clinvar, efo, mesh, hpo, clinical_trials, antibody, cellxgene, cellxgene_celltype, orphanet, mondoparent, mondochild, gwas, gwas_study gencc: mondo, hpo, hgnc, ensembl clinical_trials: mondo, chembl_molecule pharmgkb: hgnc, dbsnp, mesh, pharmgkb_gene, pharmgkb_variant, pharmgkb_clinical, pharmgkb_guideline, pharmgkb_pathway pharmgkb_variant: pharmgkb_clinical, hgnc, mesh, dbsnp pharmgkb_gene: hgnc, entrez, ensembl, pharmgkb pharmgkb_clinical: dbsnp, hgnc, mesh, pharmgkb_variant pharmgkb_guideline: hgnc, pharmgkb pharmgkb_pathway: hgnc, pharmgkb ctd: mesh, ctd_gene_interaction, ctd_disease_association, pubchem ctd_gene_interaction: ctd, entrez, taxonomy, pubmed ctd_disease_association: ctd, mesh, mim, pubmed intact: uniprot, chebi, rnacentral string: uniprot, string_interaction string_interaction: string, uniprot biogrid: entrez, uniprot, refseq, taxonomy bgee: ensembl, uberon, cl, taxonomy, bgee_evidence bgee_evidence: bgee, uberon, cl cellxgene: cl, uberon, mondo, efo, taxonomy cellxgene_celltype: cl, uberon, mondo scxa: cl, uberon, taxonomy, ensembl, scxa_gene_experiment scxa_expression: ensembl, scxa, scxa_gene_experiment scxa_gene_experiment: ensembl, scxa, scxa_expression, cl rnacentral: uniprot, ensembl, intact, hgnc, refseq, ena reactome: ensembl, uniprot, chebi, go, reactomeparent, reactomechild rhea: chebi, uniprot, go go: ensembl, uniprot, reactome, msigdb, swisslipids, bgee, interpro, goparent, gochild hpo: clinvar, gencc, mondo, msigdb, orphanet, mim, hmdb, hgnc, hpoparent, hpochild efo: gwas, mondo, cellxgene, efoparent, efochild uberon: bgee, cellxgene, cellxgene_celltype, swisslipids, uberonparent, uberonchild cl: bgee, cellxgene, cellxgene_celltype, scxa, scxa_gene_experiment, clparent, clchild taxonomy: ensembl, uniprot, bgee, biogrid, ctd_gene_interaction, taxparent, taxchild mesh: pharmgkb, ctd, ctd_disease_association, pubchem, mondo, chembl_molecule, meshparent, meshchild eco: ecoparent, ecochild antibody: ensembl, uniprot, mondo, pdb msigdb: hgnc, entrez, go, hpo orphanet: hpo, uniprot, mondo, hgnc, clinvar, mim, mesh mim: clinvar, hpo, mondo, uniprot, ctd_disease_association hmdb: pubchem, hpo, chebi, uniprot collectri: hgnc # transcription factor → target gene interactions esm2_similarity: uniprot # protein structural similarity diamond_similarity: uniprot # protein sequence similarity cellphonedb: uniprot, ensembl, hgnc, pubmed # ligand-receptor pairs for cell-cell communication spliceai: hgnc pdb: uniprot, go, interpro, pfam, taxonomy, pubmed fantom5_promoter: ensembl, hgnc, entrez, uniprot, uberon, cl fantom5_enhancer: ensembl, uberon, cl fantom5_gene: ensembl, hgnc, entrez jaspar: uniprot, pubmed, taxonomy encode_ccre: taxonomy bao: chembl_activity, chembl_assay, baoparent, baochild brenda: uniprot, pubmed, brenda_kinetics, brenda_inhibitor brenda_kinetics: brenda brenda_inhibitor: brenda gtopdb: uniprot, hgnc, gtopdb_ligand, gtopdb_interaction # drug targets (GPCRs, ion channels, enzymes) gtopdb_ligand: pubchem, chebi, chembl_molecule, gtopdb_interaction # ligands/drugs with binding data gtopdb_interaction: gtopdb, gtopdb_ligand, pubmed # target-ligand binding with affinity values
FILTER SYNTAX: >>dataset[field operator value]
OPERATORS: == equals >>dataset[field=="value"] != not equals >>dataset[field!="value"]
greater than >>dataset[field>value]
< less than >>dataset[field<value]
= greater or equal >>dataset[field>=value] <= less or equal >>dataset[field<=value] contains string match >>dataset[field.contains("value")]
LOGICAL OPERATORS: && AND >>dataset[field1>5 && field2<10] || OR >>dataset[field=="A" || field=="B"] ! NOT >>dataset[!field] or >>dataset[!(field=="value")]
TYPE RULES:
FLOAT: use decimal point (70.0 not 70)
INT: no decimal (2 not 2.0)
STRING: quote values ("Pathogenic", "PHASE3")
BOOL: true/false (no quotes)
EXAMPLES:
chembl_molecule[highestDevelopmentPhase==4] # approved drugs chembl_molecule[highestDevelopmentPhase>=3] # Phase 3+ clinical_trials[phase=="PHASE3"] go[type=="biological_process"] clinvar[germline_classification=="Pathogenic"] reactome[name.contains("signaling")] gtopdb[type=="gpcr"] # GPCR targets gtopdb[type=="ion_channel"] # ion channel targets gtopdb_ligand[approved==true] # approved drugs only gtopdb_interaction[endogenous==true] # endogenous ligand interactions
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination token | |
| chain | Yes | Mapping chain (e.g., >>ensembl>>uniprot) | |
| terms | Yes | Comma-separated identifiers to map |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden. Discloses return format ('mapped identifiers with dataset and name'), traversal limitations (xref count warnings), and complex filter syntax behaviors. Minor gap: no explicit statement about read-only nature or error handling patterns.
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?
Exceptionally well-structured with clear headers (SYNTAX, ID TYPE → SOURCE, WARNING, EXAMPLES). While lengthy, every section serves agent decision-making. Front-loaded with critical syntax rules before extensive edge documentation. Minor verbosity in edge list is justified by necessity for valid chain construction.
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 complex graph traversal tool with 3 parameters and no output schema, description achieves remarkable completeness: documents query language, valid node connections, biological use case patterns (disease→drug, drug→targets), and filter syntax. No significant gaps given the tool's complexity.
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?
Despite 100% schema coverage, adds massive domain-specific context: valid chain constructions (>>source>>target), ID type regex patterns (P*/Q*/O* → uniprot), filter operators (==, contains, &&/||), and the complete EDGES graph showing valid dataset connections—far exceeding schema descriptions.
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?
Opens with explicit verb and resource ('Map identifiers between databases'). Clearly distinguishes from siblings biobtree_entry and biobtree_search by emphasizing identifier conversion chains vs. entry lookup or search.
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?
Provides extensive when-to-use guidance including explicit syntax rules ('Chain MUST start with >>'), ID type pattern matching (ENSG* → >>ensembl), and recommended exploration paths ('Use biobtree_entry to see xrefs'). Includes specific warnings about high xref_count GO terms to prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biobtree_searchAInspect
Search 70+ biological databases.
SYNTAX: biobtree_search(terms="entity")
BEFORE SEARCHING - Use your training knowledge to plan:
What type of entity is this? (disease, process, drug, gene, protein)
What is the query asking for? (drugs, genes, function, etc.)
What equivalent terms might give better results? (e.g., "temperature homeostasis" is a process → related condition is "fever")
Choose best entry point for query type (disease terms for drug queries)
WORKFLOW:
Search WITHOUT dataset filter first (discover where entity exists)
Use IDs from results with biobtree_map
QUERY PATTERNS (choose based on question):
"DRUG FOR DISEASE/CONDITION X":
Prefer disease terms (mesh/mondo/efo) over GO terms for drug queries
If search only returns GO term, search for the related CONDITION instead (e.g., "temperature homeostasis" → search "fever" instead)
Search disease → mondo → clinical_trials → chembl_molecule
OR search drug class directly (e.g., "antipyretic", "NSAID", "antibiotic")
Verify mechanism for top 2-3 drugs only (don't enumerate all proteins!)
"DRUG TARGETS" (use BOTH paths for complete picture):
chembl: >>chembl_molecule>>chembl_target>>uniprot (mechanism-level)
pubchem: >>pubchem>>pubchem_activity>>uniprot (protein-level, often 50+ targets)
Filter approved: >>chembl_molecule[highestDevelopmentPhase==4]
"DISEASE GENES":
Search disease → mondo/hpo → gencc/clinvar/orphanet → hgnc
"PROTEIN FUNCTION":
Search protein → uniprot → go/reactome
"MECHANISM QUERIES" (drug-disease):
Use biobtree_entry to see what's connected (xrefs)
Check EDGES to see where each xref leads
Follow connections relevant to your question
Build chain: Drug → Target → [connections] → Disease
RETURNS: id | dataset | name | xref_count
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination token | |
| terms | Yes | Comma-separated identifiers to search | |
| dataset | No | Filter to specific dataset (omit for discovery) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return format ('id | dataset | name | xref_count'), explains discovery mode behavior (omit dataset parameter), and clarifies pagination via 'page' parameter context. Deducting one point as it lacks rate limit, auth, or error behavior details expected for a multi-database search 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?
Well-structured with clear headers (SYNTAX, WORKFLOW, QUERY PATTERNS, RETURNS) that front-load critical information. While lengthy, the verbosity is justified by the complexity of 70+ databases and query pattern variations. Minor deduction for potential information density issues during quick scanning.
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?
No output schema exists, and description compensates by explicitly documenting return fields. Given the tool's complexity (70+ databases, multiple entity types) and sibling dependencies, the description provides comprehensive coverage of the discovery-to-mapping workflow and query pattern permutations necessary for successful invocation.
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 has 100% coverage (baseline 3). Description adds significant semantic value: explains 'dataset' filter should be omitted for discovery, provides concrete query planning examples for the 'terms' parameter (e.g., 'temperature homeostasis' → 'fever'), and contextualizes pagination within the workflow pattern.
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?
Opens with specific verb ('Search') and scope ('70+ biological databases'). Clearly distinguishes from siblings biobtree_map and biobtree_entry by specifying 'Use IDs from results with biobtree_map' and 'Use biobtree_entry to see what's connected', establishing the correct workflow sequence.
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?
Exceptional guidance including explicit 'BEFORE SEARCHING' planning steps, 'WORKFLOW' section mandating unfiltered search first for discovery, and detailed 'QUERY PATTERNS' for specific question types (drug-disease, drug targets, disease genes). Explicitly names sibling tools as alternatives for different workflow stages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail — every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control — enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management — store and rotate API keys and OAuth tokens in one place
Change alerts — get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption — public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics — see which tools are being used most, helping you prioritize development and documentation
Direct user feedback — users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!