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
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: biobtree_entry retrieves detailed information for a single identifier, biobtree_map maps identifiers between databases, and biobtree_search searches across databases. There is no overlap in functionality; an agent can easily differentiate them based on their descriptions and intended use cases.
All tool names follow a consistent pattern: 'biobtree_' prefix followed by a descriptive action word (entry, map, search). This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions.
With only 3 tools, the server feels thin for its apparent domain of biological data integration and exploration. While the tools cover core functions (retrieve, map, search), more specialized operations (e.g., filtering, aggregation, or advanced analytics) might be missing, limiting the scope for complex agent workflows.
The tool set provides a solid foundation for biological data exploration: retrieval, mapping, and search. However, there are minor gaps, such as lack of explicit update or delete operations (though not critical for this read-heavy domain) and no dedicated tools for filtering or aggregating results beyond what's embedded in map and search. The extensive documentation and edge lists help mitigate these gaps.
Available Tools
4 toolsbiobtree_atlasAInspect
Curated Sugi Atlas knowledge for genes, diseases, and drugs (built from biobtree's own data).
SYNTAX: biobtree_atlas(entities=["TP53","imatinib"])
CALL THIS FIRST for a gene/disease/drug question (what it is, its biology, disease/drug/clinical context) - returns a concise, citable digest to ground your answer. Cite the returned canonical_url.
Pass the entity name(s) from the question; covered entities return content + citation, uncovered ones are listed in not_covered.
Default returns a compact digest (Summary + Identifiers). Each result lists the page's
sections(top-level and sub-sections); pass section="Disease & clinical" (use a name fromsections) for one zone, or full=true for the entire page (large). For big sections, query one entity at a time; full=true and large sections across several entities may be trimmed to fit.For entities not covered, or for specific ID mappings / cross-references / filters, use biobtree_map / biobtree_entry instead.
RETURNS: per entity {type, canonical_url, content, sections} + not_covered list
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | Return the entire page (large; may exceed output limits - avoid for multiple entities) | |
| section | No | Return one section instead of the digest; use a name from the result's `sections` (e.g. 'Disease & clinical') | |
| entities | Yes | Gene symbols / disease names / drug names from the question |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes default compact digest, that full=true may be trimmed, and that large sections should use single entities. No annotations provided, but description covers key behaviors. Could mention if results are cached or any 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?
Well-structured with purpose, syntax, usage notes, and return format. Front-loaded. A few sentences could be tightened, but overall efficient.
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?
Explains return per entity (type, canonical_url, content, sections, not_covered). Lacks detail on content format or error handling. Given no output schema, completeness is good but not exhaustive.
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%, but description adds context: entities from question, full=true for entire page (large), section from result's sections. Enhances understanding of parameter usage beyond 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?
Clearly states it retrieves curated knowledge for genes, diseases, drugs, and specifies it returns a concise, citable digest. Distinguishes from siblings by mentioning alternatives for ID mappings and filters.
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 says 'CALL THIS FIRST' for relevant questions and directs to 'biobtree_map / biobtree_entry instead' when entities are not covered or for specific mappings. Includes syntax example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biobtree_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)
hgnc>>clingen_gene_validity (ClinGen evidence tier), >>hgnc>>clingen_dosage (haploinsufficiency), >>hgnc>>clingen_variant>>clinvar (ACMG, then dbsnp)
CANCER / CELL LINE:
hgnc>>intogen (cancer driver gene?), >>hgnc>>civic (clinical variant interpretations)
uniprot>>cellosaurus (cell lines for a protein/gene)
hgnc>>depmap (CRISPR essentiality / target tractability), >>hgnc>>entrez>>depmap_dependency>>cellosaurus (which lines depend on the gene)
GENE FUNCTION / LITERATURE:
entrez>>generif (cited one-line functional claims; >>generif>>pubmed for citations)
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, civic, intogen, hpa, hpa_antibody, pharmgkb_var_annotation, chembl_mechanism, ncrna_disease, ncrna_interaction, ncrna_drug, alliance_disease hgnc: ensembl, uniprot, entrez, gencc, pharmgkb_gene, msigdb, clinvar, mim, refseq, alphafold, collectri, gwas, hpo, cellphonedb, civic, intogen, cellosaurus, clingen_gene_validity, clingen_dosage, clingen_variant, depmap, hpa, pharmgkb_var_annotation, chembl_mechanism, ncrna_disease, ncrna_interaction, ncrna_drug, alliance_disease entrez: ensembl, uniprot, refseq, go, biogrid, pubchem_activity, ctd_gene_interaction, dbsnp, civic, intogen, clingen_dosage, generif, depmap, depmap_dependency, hpa, pharmgkb_var_annotation refseq: ensembl, entrez, taxonomy, ccds, uniprot, mirdb mirdb: refseq transcript: ensembl, exon, ufeature, alphamissense uniprot: ensembl, alphafold, interpro, pfam, 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, alphamissense, cellosaurus, hpa, chembl_mechanism, ncrna_interaction alphafold: uniprot interpro: uniprot, go, interproparent, interprochild chembl_molecule: mesh, chembl_activity, chembl_target, pubchem, chebi, clinical_trials, chembl_moleculeparent, chembl_moleculechild, chembl_mechanism, ncrna_drug # parent=anhydrous/parent form, child=salt forms chembl_activity: chembl_molecule, chembl_assay, bao chembl_assay: chembl_activity, chembl_target, chembl_document, bao chembl_target: chembl_assay, uniprot, chembl_molecule, chembl_mechanism chembl_mechanism: chembl_molecule, chembl_target, uniprot, hgnc, ensembl # curated drug mechanism-of-action (incl. RNA therapeutics): drug >> chembl_mechanism, target/gene >> chembl_mechanism pubchem: chembl_molecule, chebi, hmdb, pubchem_activity, pubmed, patent_compound, bindingdb, ctd, pharmgkb, ncrna_drug pubchem_activity: pubchem, ensembl, uniprot chebi: pubchem, rhea, intact swisslipids: uniprot, go, chebi, uberon, cl lipidmaps: chebi, pubchem dbsnp: entrez, clinvar, pharmgkb_variant, alphamissense, spliceai, pharmgkb_var_annotation clinvar: hgnc, mondo, hpo, dbsnp, orphanet, civic_variant, cellosaurus, clingen_variant 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, civic, intogen, cellosaurus, doid, mim, ncit, umls, medgen, gard, sctid, icd9, icd10cm, icd10who, icd11, nando, meddra, nord, uberon, ncrna_disease # disease cross-refs + disease_has_location anatomy, from the Mondo OBO doid: mondo, alliance_disease, doidparent, doidchild # Disease Ontology (now a full ontology w/ hierarchy); reach MONDO + its disease graph via the mondo<->doid bridge alliance_disease: hgnc, mgi, rgd, zfin, sgd, wormbase, flybase, xenbase, doid, pubmed # cross-species + human gene->disease (Alliance of Genome Resources); gene >> alliance_disease >> doid, or doid >> alliance_disease >> mgi/rgd/... for model-organism genes gencc: mondo, hpo, hgnc, ensembl clingen_gene_validity: hgnc, entrez, ensembl, mondo # ClinGen gene-disease validity tier (Definitive..Refuted) + MOI clingen_dosage: entrez, hgnc, ensembl, mondo, mim, pubmed # ClinGen haploinsufficiency/triplosensitivity per gene clingen_variant: clinvar, hgnc, entrez, ensembl, mondo, pubmed # ClinGen VCEP ACMG variant pathogenicity (clinvar bridges to dbsnp) 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 # pharmgkb = reverse drug→clinical edge (drug >> pharmgkb >> pharmgkb_clinical) pharmgkb_guideline: hgnc, pharmgkb pharmgkb_pathway: hgnc, pharmgkb pharmgkb_var_annotation: hgnc, entrez, ensembl, dbsnp, pubmed # per-publication variant-annotation evidence (finding sentence, PMID, significance, study stats) beneath pharmgkb_clinical; reach via gene or rsID 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 hpa: ensembl, uniprot, hgnc, entrez, go, uberon, hpa_expression, hpa_pathology, hpa_antibody # Human Protein Atlas gene card: subcellular location (→go), specificity calls, top tissues hpa_expression: hpa, uberon, cellosaurus # per (gene,tissue/cell-line) RNA nTPM + IHC staining; reach genes-in-a-tissue via uberon >> hpa_expression hpa_pathology: hpa # per (gene,cancer) prognostic survival association hpa_antibody: hpa, ensembl # HPA validation antibody (reliability, antigen) rnacentral: uniprot, ensembl, intact, hgnc, refseq, ena, go # go = Rfam-projected GO annotations; rfam_id/rfam_description are attrs on the entry ncrna_disease: hgnc, ensembl, mondo, efo, pubmed # curated ncRNA->disease (LncRNADisease + HMDD); reach from the ncRNA gene ncrna_interaction: hgnc, ensembl, uniprot, pubmed # experimentally-supported ncRNA->protein interactions (NPInter) ncrna_drug: hgnc, ensembl, chembl_molecule, pubchem, pubmed # ncRNA drug-resistance / drug-target (ncRNADrug) reactome: ensembl, uniprot, chebi, go, reactomeparent, reactomechild rhea: chebi, uniprot, go go: ensembl, uniprot, reactome, msigdb, swisslipids, bgee, interpro, goparent, gochild, hpa, rnacentral hpo: clinvar, gencc, mondo, msigdb, orphanet, mim, hmdb, hgnc, hpoparent, hpochild, upheno efo: gwas, mondo, cellxgene, efoparent, efochild, ncrna_disease upheno: hpo, mp, zp, xpo, wbphenotype, fypo, uphenoparent, uphenochild # cross-species phenotype hub. A GENE's model-organism phenotypes are reached THROUGH hpo (genes are NOT linked directly to mp/upheno): >>hgnc>>hpo>>upheno>>mp (mouse), >>hgnc>>hpo>>upheno>>zp (zebrafish), ...>>xpo/wbphenotype/fypo. So gene->human HP phenotypes -> their cross-species equivalents. mp: upheno, mpparent, mpchild # Mammalian Phenotype Ontology (mouse/rat). Reach from a gene via >>hgnc>>hpo>>upheno>>mp (NOT >>hgnc>>mp). zp: upheno, zpparent, zpchild # Zebrafish Phenotype Ontology. Reach from a gene via >>hgnc>>hpo>>upheno>>zp. xpo: upheno, xpoparent, xpochild # Xenopus Phenotype Ontology wbphenotype: upheno, wbphenotypeparent, wbphenotypechild # C. elegans Phenotype Ontology fypo: upheno, fypoparent, fypochild # Fission Yeast Phenotype Ontology uberon: bgee, cellxgene, cellxgene_celltype, swisslipids, uberonparent, uberonchild, hpa, hpa_expression 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 civic: entrez, ensembl, civic_variant, civic_evidence, civic_assertion # clinical interpretation of cancer variants civic_variant: civic, clinvar, civic_evidence, civic_assertion civic_evidence: civic_variant, civic, mondo, chembl_molecule, pubmed, clinical_trials civic_assertion: civic_variant, civic, mondo, chembl_molecule intogen: hgnc, entrez, ensembl, mondo, pubmed # cancer driver genes cellosaurus: taxonomy, uniprot, hgnc, mondo, orphanet, clinvar, dbsnp, uberon, cl, chebi, doi, patent, pubmed, depmap_dependency, hpa_expression # cell lines (CVCL) generif: entrez, pubmed # NCBI cited per-gene functional claims (RAG grounding) depmap: entrez, hgnc, ensembl # CRISPR gene essentiality aggregate (cancer dependency / target tractability) depmap_dependency: entrez, cellosaurus # per cell-line gene dependency (effect < -0.5)
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?
No annotations are provided, but the description discloses the mapping behavior, return values, and important constraints (chain syntax, ID types). It does not cover error handling or data freshness but is otherwise transparent.
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 description is very long and detailed; while the structure with sections helps, it could be more concise. Many sentences list edges that could be referenced externally.
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?
Given the tool's complexity and lack of output schema, the description is exceptionally complete, covering syntax, rules, examples, warnings, and discovery approaches.
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% but descriptions are minimal; the tool description adds immense value with syntax rules, ID type mapping, filter operators, and numerous examples, greatly enriching parameter understanding.
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?
The description clearly states the tool maps identifiers between databases using chains. It provides extensive syntax and examples, making the purpose unmistakable.
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 explicitly guides when to use this tool, including syntax rules, ID type mapping, warning for high xref_count, and alternatives like biobtree_entry for exploring connections.
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!