Skip to main content
Glama
geneontology

Noctua MCP Server

Official
by geneontology

get_model

Retrieve complete GO-CAM model data including individuals, facts, and annotations using a model identifier to access biological knowledge representation.

Instructions

Retrieve the full JSON representation of a GO-CAM model.

Args: model_id: The GO-CAM model identifier

Returns: Full model data including individuals and facts

Examples: # Get a production model model = get_model("gomodel:5fce9b7300001215") # Returns complete model with: # - data.id: model ID # - data.individuals: list of all individuals # - data.facts: list of all relationships # - data.annotations: model-level annotations

# Extract specific information
model = get_model("gomodel:12345")
individuals = model["data"]["individuals"]
facts = model["data"]["facts"]

# Find all molecular functions
mfs = [i for i in individuals
       if any("GO:0003674" in str(e.id) for e in i.type if hasattr(e, 'id'))]

# Find all enabled_by relationships (facts are Pydantic objects)
enabled_by = [f for f in facts if f.property == "RO:0002333"]

# Check model state
state = model["data"].get("state")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The primary handler function for the 'get_model' MCP tool. Decorated with @mcp.tool() for automatic registration with FastMCP. Retrieves the GO-CAM model data via BaristaClient.get_model() and formats the response with success status, model data (individuals, facts, annotations, state), and raw response.
    async def get_model(model_id: str) -> Dict[str, Any]:
        """
        Retrieve the full JSON representation of a GO-CAM model.
    
        Args:
            model_id: The GO-CAM model identifier
    
        Returns:
            Full model data including individuals and facts
    
        Examples:
            # Get a production model
            model = get_model("gomodel:5fce9b7300001215")
            # Returns complete model with:
            # - data.id: model ID
            # - data.individuals: list of all individuals
            # - data.facts: list of all relationships
            # - data.annotations: model-level annotations
    
            # Extract specific information
            model = get_model("gomodel:12345")
            individuals = model["data"]["individuals"]
            facts = model["data"]["facts"]
    
            # Find all molecular functions
            mfs = [i for i in individuals
                   if any("GO:0003674" in str(e.id) for e in i.type if hasattr(e, 'id'))]
    
            # Find all enabled_by relationships (facts are Pydantic objects)
            enabled_by = [f for f in facts if f.property == "RO:0002333"]
    
            # Check model state
            state = model["data"].get("state")
        """
        client = get_client()
        resp = client.get_model(model_id)
    
        if resp.error:
            return {
                "success": False,
                "error": resp.error,
                "model_id": model_id
            }
    
        # Return structured response with model data
        return {
            "success": True,
            "model_id": model_id,
            "data": {
                "individuals": resp.individuals,
                "facts": resp.facts,
                "annotations": resp.annotations if hasattr(resp, 'annotations') else [],
                "state": resp.model_state if hasattr(resp, 'model_state') else None
            },
            "raw": resp.raw  # Include raw for backward compatibility
        }
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. It discloses that it retrieves data (a read operation) and includes examples of return structure, but doesn't mention potential behavioral traits like error handling, rate limits, authentication needs, or whether it's idempotent. It adds some context about the return format but lacks comprehensive behavioral details.

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

Conciseness3/5

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

The description is front-loaded with the core purpose, but includes extensive examples that, while helpful, make it lengthy. Some example details (e.g., specific code for extracting molecular functions) might be excessive for a tool description, reducing conciseness. However, the structure is logical with clear sections.

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 the tool's moderate complexity (single parameter, read operation), no annotations, but an output schema exists, the description is fairly complete. It covers purpose, parameter semantics, and return structure through examples, though it could benefit from more behavioral context like error cases or prerequisites.

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

Parameters4/5

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

The description adds meaning beyond the input schema by explaining that 'model_id' is a 'GO-CAM model identifier' and providing example values like 'gomodel:5fce9b7300001215'. With schema description coverage at 0% and only one parameter, this compensates well, though it could specify format constraints more explicitly.

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

Purpose5/5

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

The description clearly states the verb 'retrieve' and the resource 'full JSON representation of a GO-CAM model', making the purpose specific. It distinguishes this tool from siblings like 'model_summary' (which likely provides a summary rather than full data) and 'search_models' (which likely returns a list rather than detailed data).

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 implies usage context by specifying it retrieves 'full JSON representation' and includes examples showing extraction of detailed data, suggesting it's for when complete model information is needed. However, it doesn't explicitly state when to use this vs. alternatives like 'model_summary' or 'get_model_variables', missing explicit exclusions or comparisons.

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/geneontology/noctua-mcp'

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