Skip to main content
Glama
biocontext-ai

BioContextAI Knowledgebase MCP

Official

bc_get_term_hierarchical_children

Retrieve hierarchical child terms from biomedical ontologies to understand term relationships and structure in knowledge bases.

Instructions

Get hierarchical children of an ontology term from OLS. Includes subclasses and hierarchical properties.

Returns: dict: Parent term, hierarchical_children array with id/label/definition, total_children, page_info or error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
term_idYesTerm ID in CURIE format (e.g., 'EFO:0000001', 'GO:0008150')
ontology_idYesOntology ID (e.g., 'efo', 'go', 'chebi')
sizeNoMaximum number of children to return

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The core implementation of the 'get_term_hierarchical_children' tool handler, decorated with @core_mcp.tool(). This function queries the OLS API for hierarchical children of a given ontology term. The tool is part of the 'BC' FastMCP server, which is imported with prefix 'bc', resulting in the tool name 'bc_get_term_hierarchical_children'. Includes input schema via Pydantic Annotated fields.
    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_term_hierarchical_children(
        term_id: Annotated[str, Field(description="Term ID in CURIE format (e.g., 'EFO:0000001', 'GO:0008150')")],
        ontology_id: Annotated[str, Field(description="Ontology ID (e.g., 'efo', 'go', 'chebi')")],
        size: Annotated[
            int,
            Field(description="Maximum number of children to return"),
        ] = 20,
    ) -> Dict[str, Any]:
        """Get hierarchical children of an ontology term from OLS. Includes subclasses and hierarchical properties.
    
        Returns:
            dict: Parent term, hierarchical_children array with id/label/definition, total_children, page_info or error message.
        """
        if not term_id:
            return {"error": "term_id must be provided"}
        if not ontology_id:
            return {"error": "ontology_id must be provided"}
    
        # Double URL encode the term IRI
        import urllib.parse
    
        term_iri = f"http://purl.obolibrary.org/obo/{term_id.replace(':', '_')}"
        encoded_iri = urllib.parse.quote(urllib.parse.quote(term_iri, safe=""), safe="")
    
        url = f"https://www.ebi.ac.uk/ols4/api/v2/ontologies/{ontology_id}/classes/{encoded_iri}/hierarchicalChildren"
    
        params = {
            "size": str(size),
            "page": "0",
        }
    
        try:
            response = requests.get(url, params=params)
            response.raise_for_status()
    
            data = response.json()
    
            if not data.get("elements"):
                return {"error": "No hierarchical children found"}
    
            # Extract children information
            children = [
                {
                    "id": element.get("curie", "").replace(":", "_"),
                    "curie": element.get("curie", ""),
                    "label": element.get("label", ""),
                    "definition": element.get("definition", ""),
                    "ontology_name": element.get("ontologyName", ""),
                    "has_hierarchical_children": element.get("hasHierarchicalChildren", False),
                    "num_descendants": element.get("numDescendants", 0),
                }
                for element in data["elements"]
            ]
    
            return {
                "parent_term": term_id,
                "hierarchical_children": children,
                "total_children": data.get("totalElements", len(children)),
                "page_info": {
                    "page": data.get("page", 0),
                    "total_pages": data.get("totalPages", 1),
                    "num_elements": data.get("numElements", len(children)),
                },
            }
    
        except requests.exceptions.RequestException as e:
            return {"error": f"Failed to fetch hierarchical children: {e!s}"}
  • Defines the 'core_mcp' FastMCP server instance named 'BC', to which tools like get_term_hierarchical_children are registered via @core_mcp.tool() decorators. This server is later imported into the main app with slugify('BC') = 'bc' prefix.
    from fastmcp import FastMCP
    
    core_mcp = FastMCP(  # type: ignore
        "BC",
        instructions="Provides access to biomedical knowledge bases.",
    )
  • Imports the 'core_mcp' server (containing the tool) into the main 'BioContextAI' MCP app using import_server with slugified prefix 'bc', effectively registering all core tools with 'bc_' prefix, including 'bc_get_term_hierarchical_children'.
    for mcp in [core_mcp, *(await get_openapi_mcps())]:
        await mcp_app.import_server(
            mcp,
            slugify(mcp.name),
        )
    logger.info("MCP server setup complete.")
  • Input schema defined using Pydantic's Annotated and Field for the tool parameters: term_id (str), ontology_id (str), size (int, default 20). Output is Dict[str, Any].
    def get_term_hierarchical_children(
        term_id: Annotated[str, Field(description="Term ID in CURIE format (e.g., 'EFO:0000001', 'GO:0008150')")],
        ontology_id: Annotated[str, Field(description="Ontology ID (e.g., 'efo', 'go', 'chebi')")],
        size: Annotated[
            int,
            Field(description="Maximum number of children to return"),
        ] = 20,
    ) -> Dict[str, Any]:
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format (dict with specific fields) and pagination via 'size' parameter, which is helpful. However, it doesn't address rate limits, authentication requirements, error conditions beyond a generic 'error message', or whether this is a read-only operation (implied but not stated).

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 scope, another detailing the return format. It's front-loaded with the core functionality. Minor improvement could be merging the return details more seamlessly, but it's highly concise with zero wasted words.

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 100% schema coverage and an output schema (implied by 'Returns: dict...'), the description provides adequate context. It covers the tool's purpose, return structure, and pagination behavior. For a read operation with good schema support, this is reasonably complete, though adding behavioral constraints would enhance it.

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 clear documentation for all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, but the schema already fully describes term_id format, ontology_id examples, and size default/purpose. 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 action ('Get hierarchical children') and resource ('ontology term from OLS'), specifying it includes both subclasses and hierarchical properties. It distinguishes from siblings like 'bc_get_term_details' by focusing on children retrieval rather than term metadata. However, it doesn't explicitly contrast with 'bc_search_ontology_terms' which might also retrieve related terms.

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?

No guidance is provided on when to use this tool versus alternatives like 'bc_get_term_details' for basic term information or 'bc_search_ontology_terms' for broader searches. The description mentions what it returns but doesn't specify use cases, prerequisites, or exclusions for this hierarchical children query.

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