Skip to main content
Glama
geneontology

Noctua MCP Server

Official
by geneontology

add_evidence_to_fact

Add evidence to an existing GO-CAM fact by specifying an ECO code, source references, and optional with/from identifiers.

Instructions

Add evidence to an existing fact in a GO-CAM model.

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 eco_id: Evidence code (e.g., "ECO:0000353") sources: List of source references (e.g., ["PMID:12345"]) with_from: Optional list of with/from references

Returns: Barista API response

Examples: # Add experimental evidence from a paper add_evidence_to_fact( "gomodel:12345", "mf1", "gp1", "RO:0002333", "ECO:0000353", # physical interaction evidence ["PMID:12345678"] )

# Add multiple sources
add_evidence_to_fact(
    "gomodel:12345", "mf1", "gp1", "RO:0002333",
    "ECO:0000314",  # direct assay evidence
    ["PMID:12345678", "PMID:87654321", "doi:10.1234/example"]
)

# Add evidence with with/from (e.g., for IPI)
add_evidence_to_fact(
    "gomodel:12345", "mf1", "gp1", "RO:0002333",
    "ECO:0000353",  # IPI
    ["PMID:12345678"],  
    ["UniProtKB:Q9Y6K9", "UniProtKB:P38398"]  # interacting partners
)

# Common evidence codes:
# ECO:0000314 - direct assay evidence
# ECO:0000353 - physical interaction evidence (IPI)
# ECO:0000315 - mutant phenotype evidence (IMP)
# ECO:0000316 - genetic interaction evidence (IGI)
# ECO:0000318 - biological aspect of ancestor evidence (IBA)
# ECO:0000269 - experimental evidence

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
subject_idYes
object_idYes
predicate_idYes
eco_idYes
sourcesYes
with_fromNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions the tool adds evidence (mutation) and returns a Barista API response, but lacks details on side effects, idempotency, or permissions. The return value is vague.

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?

Well-structured with clear sections (short description, Args, Returns, Examples, Common codes). The examples add value, but the list of common codes is somewhat lengthy. Overall, efficient but slightly verbose.

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 7 parameters, no annotations, and an output schema that isn't detailed, the description covers the core functionality well with examples and common codes. Lacks edge cases or error handling, but adequate for most uses.

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 0%, so description must compensate. It lists all parameters in Args with brief descriptions and provides concrete examples showing their usage. However, individual parameter details (e.g., formats, constraints) are minimal.

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 action ('Add evidence to an existing fact') and the resource (GO-CAM model), distinguishing it from sibling tools like 'add_fact' which likely adds a fact itself.

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?

Examples cover common use cases (single/multiple sources, with/from), and common evidence codes are listed. However, no explicit guidance on when not to use this tool (e.g., if fact doesn't exist) or alternatives beyond what is implicitly suggested.

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