Skip to main content
Glama
biocontext-ai

BioContextAI Knowledgebase MCP

Official

bc_search_ontology_terms

Search biomedical ontologies to find standardized terms for genes, proteins, diseases, and chemicals. Use this tool to retrieve verified terminology from multiple biological databases.

Instructions

Search for terms across multiple ontologies in OLS. Use get_available_ontologies() first to discover ontologies.

Returns: dict: Terms array, terms_by_ontology grouped results, total_results, ontologies_found list or error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
search_termYesTerm to search for
ontologiesNoComma-separated ontology IDs (e.g., 'efo,go,chebi'). Leave empty for all. Use get_available_ontologies() to see options
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 'search_ontology_terms' tool (likely 'bc_search_ontology_terms' under BC MCP server). Implements search across OLS ontologies using the EBI OLS API, processes results into structured terms and groups by ontology.
    @core_mcp.tool()
    def search_ontology_terms(
        search_term: Annotated[str, Field(description="Term to search for")],
        ontologies: Annotated[
            str,
            Field(
                description="Comma-separated ontology IDs (e.g., 'efo,go,chebi'). Leave empty for all. Use get_available_ontologies() to see options"
            ),
        ] = "",
        size: Annotated[
            int,
            Field(description="Maximum number of results to return"),
        ] = 20,
        exact_match: Annotated[
            bool,
            Field(description="Whether to perform exact match search"),
        ] = False,
    ) -> Dict[str, Any]:
        """Search for terms across multiple ontologies in OLS. Use get_available_ontologies() first to discover ontologies.
    
        Returns:
            dict: Terms array, terms_by_ontology grouped results, total_results, ontologies_found list or error message.
        """
        if not search_term:
            return {"error": "search_term must be provided"}
    
        url = "https://www.ebi.ac.uk/ols4/api/v2/entities"
    
        params = {
            "search": search_term,
            "size": str(size),
            "lang": "en",
            "exactMatch": str(exact_match).lower(),
            "includeObsoleteEntities": "false",
        }
    
        # Add ontology filter if specified
        if ontologies.strip():
            # Convert comma-separated string to individual ontologyId parameters
            ontology_list = [ont.strip() for ont in ontologies.split(",") if ont.strip()]
            if ontology_list:
                params["ontologyId"] = ",".join(ontology_list)
    
        try:
            response = requests.get(url, params=params)
            response.raise_for_status()
    
            data = response.json()
    
            if not data.get("elements"):
                return {"error": "No terms found"}
    
            # Extract terms with comprehensive information
            terms = [
                {
                    "id": element.get("curie", "").replace(":", "_"),
                    "curie": element.get("curie", ""),
                    "label": element.get("label", ""),
                    "definition": element.get("definition", ""),
                    "synonyms": element.get("synonym", []),
                    "ontology_name": element.get("ontologyName", ""),
                    "ontology_prefix": element.get("ontologyPrefix", ""),
                    "is_defining_ontology": element.get("isDefiningOntology", False),
                    "is_obsolete": element.get("isObsolete", False),
                    "has_hierarchical_children": element.get("hasHierarchicalChildren", False),
                    "has_hierarchical_parents": element.get("hasHierarchicalParents", False),
                    "num_descendants": element.get("numDescendants", 0),
                    "appears_in": element.get("appearsIn", []),
                }
                for element in data["elements"]
            ]
    
            # Group results by ontology for better organization
            results_by_ontology: Dict[str, List[Dict[str, Any]]] = {}
            for term in terms:
                ontology = term["ontology_name"] or term["ontology_prefix"] or "unknown"
                if ontology not in results_by_ontology:
                    results_by_ontology[ontology] = []
                results_by_ontology[ontology].append(term)
    
            return {
                "terms": terms,
                "terms_by_ontology": results_by_ontology,
                "total_results": len(terms),
                "ontologies_found": list(results_by_ontology.keys()),
            }
    
        except requests.exceptions.RequestException as e:
            return {"error": f"Failed to search ontology terms: {e!s}"}
  • Imports the search_ontology_terms tool function for exposure in the OLS module.
    from ._search_ontology_terms import search_ontology_terms
  • Defines the core_mcp FastMCP server instance named 'BC', where tools like search_ontology_terms are registered via @core_mcp.tool() decorator. Tool names may be prefixed with 'bc_' due to the 'BC' server identifier.
    core_mcp = FastMCP(  # type: ignore
        "BC",
        instructions="Provides access to biomedical knowledge bases.",
    )
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite tool and describes the return structure (terms array, grouped results, etc.), which adds useful context. However, it doesn't cover important behavioral aspects like rate limits, authentication needs, error conditions beyond 'error message,' or whether this is a read-only operation.

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 appropriately sized with three sentences: purpose statement, prerequisite guidance, and return value description. Each sentence earns its place, and the information is front-loaded with the core purpose first. It could be slightly more concise by integrating the return format more smoothly.

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

Completeness4/5

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

Given that an output schema exists (though not shown here), the description doesn't need to fully explain return values. It provides the purpose, prerequisite guidance, and a high-level overview of returns. For a search tool with good schema coverage and output schema, this is reasonably complete, though it could benefit from more behavioral context given the lack of annotations.

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

Parameters3/5

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

The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Search for terms across multiple ontologies in OLS.' It specifies the verb ('Search') and resource ('terms across multiple ontologies'), but doesn't explicitly differentiate from sibling tools like bc_get_cell_ontology_terms or bc_get_chebi_terms_by_chemical, which appear to be more specific ontology queries.

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

Usage Guidelines4/5

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

The description provides clear context for usage: 'Use get_available_ontologies() first to discover ontologies.' This gives a specific prerequisite and references another tool. However, it doesn't explicitly state when NOT to use this tool or provide alternatives among siblings.

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