Skip to main content
Glama
biocontext-ai

BioContextAI Knowledgebase MCP

Official

bc_get_chebi_terms_by_chemical

Retrieve ChEBI chemical database entries by searching with chemical or drug names to access standardized biological compound information.

Instructions

Search OLS for ChEBI (Chemical Entities of Biological Interest) terms for a chemical or drug name.

Returns: dict: ChEBI terms with chebi_terms array containing id, label, description, synonyms or error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chemical_nameYesChemical or drug name to search for (e.g., 'aspirin', 'glucose')
sizeNoMaximum number of results to return
exact_matchNoWhether to perform exact match search

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The handler function for the 'bc_get_chebi_terms_by_chemical' tool. It queries the OLS API for ChEBI terms by chemical name, filters for CHEBI: prefixed terms, and returns structured data or error.
    from typing import Annotated, Any, Dict
    
    import requests
    from pydantic import Field
    
    from biocontext_kb.core._server import core_mcp
    
    
    @core_mcp.tool()
    def get_chebi_terms_by_chemical(
        chemical_name: Annotated[
            str, Field(description="Chemical or drug name to search for (e.g., 'aspirin', 'glucose')")
        ],
        size: Annotated[
            int,
            Field(description="Maximum number of results to return"),
        ] = 10,
        exact_match: Annotated[
            bool,
            Field(description="Whether to perform exact match search"),
        ] = False,
    ) -> Dict[str, Any]:
        """Search OLS for ChEBI (Chemical Entities of Biological Interest) terms for a chemical or drug name.
    
        Returns:
            dict: ChEBI terms with chebi_terms array containing id, label, description, synonyms or error message.
        """
        if not chemical_name:
            return {"error": "chemical_name must be provided"}
    
        url = "https://www.ebi.ac.uk/ols4/api/v2/entities"
    
        params = {
            "search": chemical_name,
            "size": str(size),
            "lang": "en",
            "exactMatch": str(exact_match).lower(),
            "includeObsoleteEntities": "false",
            "ontologyId": "chebi",
        }
    
        def starts_with_chebi_prefix(curie: str) -> bool:
            """Check if the curie starts with CHEBI prefix."""
            return curie.startswith("CHEBI:")
    
        try:
            response = requests.get(url, params=params)
            response.raise_for_status()
    
            data = response.json()
    
            # Check that at least one item is in elements with CHEBI prefix
            if not data.get("elements") or not any(
                starts_with_chebi_prefix(str(element.get("curie", ""))) for element in data["elements"]
            ):
                return {"error": "No ChEBI terms found"}
    
            # Extract ChEBI terms and their information
            chebi_terms = [
                {
                    "id": element["curie"].replace(":", "_"),
                    "label": element["label"],
                    "description": element.get("description", ""),
                    "ontology_name": element.get("ontologyName", ""),
                    "synonyms": element.get("synonyms", []),
                }
                for element in data["elements"]
                if starts_with_chebi_prefix(str(element.get("curie", "")))
            ]
            return {"chebi_terms": chebi_terms}
    
        except requests.exceptions.RequestException as e:
            return {"error": f"Failed to fetch ChEBI terms: {e!s}"}
  • Defines the core_mcp FastMCP instance with name 'BC', which prefixes tool names with 'bc_' and is used by @core_mcp.tool() decorator to register the tool.
    from fastmcp import FastMCP
    
    core_mcp = FastMCP(  # type: ignore
        "BC",
        instructions="Provides access to biomedical knowledge bases.",
    )
  • Imports the get_chebi_terms_by_chemical function, which triggers the @tool decorator registration when the module is imported.
    from ._get_available_ontologies import get_available_ontologies
    from ._get_cell_ontology_terms import get_cell_ontology_terms
    from ._get_chebi_terms_by_chemical import get_chebi_terms_by_chemical
    from ._get_efo_id_by_disease_name import get_efo_id_by_disease_name
    from ._get_go_terms_by_gene import get_go_terms_by_gene
    from ._get_term_details import get_term_details
    from ._get_term_hierarchical_children import get_term_hierarchical_children
    from ._search_ontology_terms import search_ontology_terms
    
    __all__ = [
        "get_available_ontologies",
        "get_cell_ontology_terms",
        "get_chebi_terms_by_chemical",
        "get_efo_id_by_disease_name",
        "get_go_terms_by_gene",
        "get_term_details",
        "get_term_hierarchical_children",
        "search_ontology_terms",
    ]
  • Imports the core_mcp (containing the registered OLS tools) into the main BioContextAI MCP application.
    for mcp in [core_mcp, *(await get_openapi_mcps())]:
        await mcp_app.import_server(
            mcp,
            slugify(mcp.name),
        )
  • Pydantic-based input schema with Annotated Fields defining parameters for the tool.
    def get_chebi_terms_by_chemical(
        chemical_name: Annotated[
            str, Field(description="Chemical or drug name to search for (e.g., 'aspirin', 'glucose')")
        ],
        size: Annotated[
            int,
            Field(description="Maximum number of results to return"),
        ] = 10,
        exact_match: Annotated[
            bool,
            Field(description="Whether to perform exact match search"),
        ] = False,
    ) -> Dict[str, Any]:
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the return format (dict with chebi_terms array) but lacks critical behavioral details: whether this is a read-only operation, potential rate limits, authentication requirements, error handling beyond 'error message', or what OLS (Ontology Lookup Service) specifically entails. For a search tool with no annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in two sentences: one stating the purpose and one describing the return format. No wasted words, though it could be slightly more front-loaded by integrating the return information into the main purpose statement. Every sentence earns its place by providing distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (implied by 'Returns: dict'), the description doesn't need to detail return values. However, for a search tool with no annotations and multiple parameters, the description should provide more behavioral context about search scope, limitations, or typical use cases. It's minimally adequate but leaves gaps in understanding when and how to effectively use this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, providing good documentation for all three parameters. The description adds no parameter-specific information beyond what's in the schema. It mentions searching by 'chemical or drug name' which aligns with the chemical_name parameter but doesn't provide additional context about search behavior, ranking, or result format details. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches OLS for ChEBI terms using a chemical/drug name, with a specific verb ('search') and resource ('ChEBI terms'). It distinguishes from siblings by focusing on chemical entities rather than proteins, drugs, or other biological data. However, it doesn't explicitly differentiate from 'bc_search_ontology_terms' which might have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for chemical/drug data (e.g., bc_get_drug_by_application_number, bc_search_drugs_fda), there's no indication of when ChEBI ontology search is preferred over other drug information sources. Only basic context is implied by mentioning 'chemical or drug name'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/biocontext-ai/knowledgebase-mcp'

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