Skip to main content
Glama
geneontology

Noctua MCP Server

Official
by geneontology

remove_fact

Remove a specific fact from a GO-CAM model by specifying the exact subject, predicate, and object.

Instructions

Remove a fact from a GO-CAM model.

You must specify the exact triple (subject, predicate, object) to remove.

Args: model_id: The GO-CAM model identifier subject_id: Subject of the fact object_id: Object of the fact predicate_id: Predicate of the fact

Returns: Barista API response

Examples: # Remove an enabled_by relationship remove_fact( "gomodel:12345", "gomodel:12345/mf_123", "gomodel:12345/gp_456", "RO:0002333" )

# Remove a causal relationship
remove_fact(
    "gomodel:12345",
    "gomodel:12345/activity1",
    "gomodel:12345/activity2",
    "RO:0002413"  # provides input for
)

# Remove occurs_in relationship
remove_fact(
    "gomodel:12345",
    "gomodel:12345/mf_123",
    "gomodel:12345/cc_789",
    "BFO:0000066"  # occurs_in
)

# Remove using variable references (within same batch)
remove_fact("gomodel:12345", "mf1", "gp1", "RO:0002333")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
subject_idYes
object_idYes
predicate_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The remove_fact tool handler function. It takes model_id, subject_id, object_id, and predicate_id, calls client.remove_fact(), and returns success/failure with validation error handling.
    @mcp.tool()
    async def remove_fact(
        model_id: str,
        subject_id: str,
        object_id: str,
        predicate_id: str
    ) -> Dict[str, Any]:
        """
        Remove a fact from a GO-CAM model.
    
        You must specify the exact triple (subject, predicate, object) to remove.
    
        Args:
            model_id: The GO-CAM model identifier
            subject_id: Subject of the fact
            object_id: Object of the fact
            predicate_id: Predicate of the fact
    
        Returns:
            Barista API response
    
        Examples:
            # Remove an enabled_by relationship
            remove_fact(
                "gomodel:12345",
                "gomodel:12345/mf_123",
                "gomodel:12345/gp_456",
                "RO:0002333"
            )
    
            # Remove a causal relationship
            remove_fact(
                "gomodel:12345",
                "gomodel:12345/activity1",
                "gomodel:12345/activity2",
                "RO:0002413"  # provides input for
            )
    
            # Remove occurs_in relationship
            remove_fact(
                "gomodel:12345",
                "gomodel:12345/mf_123",
                "gomodel:12345/cc_789",
                "BFO:0000066"  # occurs_in
            )
    
            # Remove using variable references (within same batch)
            remove_fact("gomodel:12345", "mf1", "gp1", "RO:0002333")
        """
        client = get_client()
        resp = client.remove_fact(model_id, subject_id, object_id, predicate_id)
    
        if resp.validation_failed:
            return {
                "success": False,
                "error": "Validation failed",
                "reason": resp.validation_reason,
                "rolled_back": True,
                "fact": {
                    "subject": subject_id,
                    "predicate": predicate_id,
                    "object": object_id
                },
                "model_id": model_id
            }
    
        if resp.error:
            return {
                "success": False,
                "error": resp.error,
                "fact": {
                    "subject": subject_id,
                    "predicate": predicate_id,
                    "object": object_id
                },
                "model_id": model_id
            }
    
        # Return minimal success response
        return {
            "success": True,
            "removed": True
        }
  • The tool is registered via the @mcp.tool() decorator on line 750, which registers remove_fact with the FastMCP server instance.
    @mcp.tool()
  • The get_client() helper function that creates/lazily initializes the BaristaClient instance used by remove_fact to call client.remove_fact().
    def get_client() -> BaristaClient:
        """Get or create the Barista client instance."""
        global _client
        if _client is None:
            _client = BaristaClient()
        return _client
  • Input schema for remove_fact: model_id (str), subject_id (str), object_id (str), predicate_id (str) defined via FastMCP type annotations.
    async def remove_fact(
        model_id: str,
        subject_id: str,
        object_id: str,
        predicate_id: str
Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It only states the action, the need for an exact triple, and returns a Barista API response. It does not disclose side effects, error handling, or authorization needs.

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

Conciseness5/5

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

The description is concise, well-structured with Args, Returns, and multiple examples. Every section adds value without redundancy.

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?

Covers the core operation, parameters, and examples thoroughly. Has an output schema (though not detailed here) which helps with return values. Slight gap: no mention of error conditions or handling of non-existent facts.

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?

Despite 0% schema description coverage, the description lists all four parameters in the Args section with brief explanations and uses examples to illustrate usage. This adds meaningful context beyond the raw schema.

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?

Clearly states the action ('Remove a fact from a GO-CAM model') with a specific verb and resource. Distinguishes from siblings like add_fact or remove_individual.

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?

Explicitly requires the exact triple (subject, predicate, object) and provides examples for different fact types. Does not explicitly state when not to use it but context from examples and siblings is clear.

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