NEXUS AGI

Store fact

store_fact

Store a semantic fact: a (subject, predicate, value) statement about an entity that holds independently of when it was observed. For events use store_episode.

Fact confidence decays over time unless the fact is reaffirmed, except
for facts classified as 'evento'. The response includes
`contradicciones`: existing facts with the same subject and predicate but
a different value. Nothing is deleted or superseded automatically; mark
the incorrect one with `supersede_memory`.

Args:
    entity_id: UUID of the entity the fact is about.
    predicate: Free-form predicate, e.g. 'is_a', 'has_role',
        'located_in', 'depends_on'. Reuse predicates across calls.
    value: The fact value, as a string.
    confidence: Confidence in [0.0, 1.0]. When omitted, it is set to the
        ceiling for `epistemico`: 1.0 'medido', 0.8 'reportado',
        0.7 'inferido'. An explicit value is always kept.
    source: Optional identifier of where the fact came from.
    epistemico: How it is known: 'medido' (returned by a system: an HTTP
        response, a query, command output), 'inferido' (concluded by
        reasoning), 'reportado' (stated by someone else). Omitted or
        unrecognized values are classified automatically, falling back to
        'inferido'.
    volatilidad: Whether it can stop being true: 'evento' (something that
        happened; does not decay), 'estado' (how something is; expires if
        it changes), 'pendiente' (still to do; expires within days).
        Omitted or unrecognized values are classified automatically.
    fuente: Optional. How you came to know this, so it can be recalled
        with its source the way a person remembers who told them what.
        Who you were with and through which agent are NOT declared here:
        the server stamps them from your credential. Keys, all optional
        and free text except `modo`:
          modo: 'vivido' (I did or said it), 'conversado' (someone told
            me directly), 'leido' (a document, web page, another agent's
            message, a tool's output), 'pensado' (I inferred or
            concluded it).
          de: who said or originated it, e.g. "Cris" or
            {"nombre": "Cris", "tipo": "persona"}.
          con: who you were with, only if not your owner.
          para: who you did it for.
          canal: channel inside the agent, e.g. "whatsapp", "terminal".
          donde: scope or place: repo, project, file, URL.

Input Schema

Name	Required	Description	Default
`value`	Yes
`fuente`	No
`source`	No
`entity_id`	Yes
`predicate`	Yes
`confidence`	No
`epistemico`	No
`volatilidad`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / fuente

Added value: +{
+  "additionalProperties": true,
+  "default": null,
+  "title": "Fuente",
+  "type": "object"
+}

First observedOct 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations, which only declare it is a non-read-only, non-destructive, non-idempotent write. The description discloses temporal behavior (confidence decays unless reaffirmed, except 'evento'), the response payload ('contradicciones'), and the critical safety property that nothing is deleted or superseded automatically. That is exactly the context an agent needs before writing.

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?

Front-loads purpose, then the decay/contradiction semantics, then a structured Args block, so scanning is easy. It is long, and a few passages are expansive ('the way a person remembers who told them what'), but given 8 undocumented parameters the length is largely earned.

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?

For a mutation tool with no output schema it covers the write semantics and names the one response key that matters. It leaves prerequisites and failure modes unaddressed (whether entity_id must already exist, what happens on error), and the full response shape is only partially implied.

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

Parameters5/5

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

Schema coverage is 0%, so the description carries the entire burden and does so: it defines all eight parameters, the three required ones, the confidence ceiling defaults per epistemico value, the auto-classification and 'inferido' fallback for unrecognized values, the volatility taxonomy, and the nested fuente keys with their allowed values. It adds far more meaning than the schema provides.

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?

States a specific verb and resource ('Store a semantic fact') and defines the resource precisely as a (subject, predicate, value) statement that holds independently of observation time. It explicitly contrasts itself with the closest sibling, store_episode, so an agent can route without opening either schema.

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?

Gives two concrete routing rules: use store_episode for events, and use supersede_memory to retire a contradicted fact rather than expecting automatic replacement. It does not, however, position itself against the wider sibling set (create_entity, store_procedure, create_relation), so guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All NEXUS AGI tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?