NEXUS AGI

Store episode

store_episode

Store an episodic memory: a specific, timestamped event tied to an entity. Use it for things that happened; for timeless statements use store_fact. To also resolve entity mentions and store linked facts in one call, use process_observation.

If `entity_id` does not exist, the episode is still stored, unlinked,
and the id is listed in `context.entity_ids_descartados` in the response.
When `volatilidad` or `epistemico` is omitted or not one of the listed
values, it is classified automatically from the text.

Args:
    entity_id: UUID of the entity this episode is about.
    event_type: Free-form event type, e.g. 'observation', 'action',
        'conversation', 'decision'. Reuse values within a domain.
    content: Dict with a 'description' key holding the episode text; other
        keys are stored as context. Without 'description', the whole dict
        is stringified as the text.
    metadata: Optional extra keys merged into the stored context.
    volatilidad: Whether this can stop being true:
        'evento' (something that happened; does not expire),
        'estado' (describes how something is; expires if it changes),
        'pendiente' (something still to do; expires within days).
        A text that narrates work done and ends with what remains to do
        is 'pendiente'.
    epistemico: How the information is known:
        'medido' (returned by a system: an HTTP response, a query, command
        output), 'inferido' (concluded by reasoning), 'reportado' (stated
        by someone else). A text mixing a measurement and a conclusion is
        'inferido'. Default when omitted: automatic, falling back to
        'inferido'.
    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.

Example:
    store_episode(
        entity_id="3f2a...",
        event_type="conversation",
        content={"description": "Alice asked about the deployment status",
                 "channel": "slack"},
    )

Input Schema

Name	Required	Description	Default
`fuente`	No
`content`	Yes
`metadata`	No
`entity_id`	Yes
`epistemico`	No
`event_type`	Yes
`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.7/5.0

Behavior4/5

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

Annotations already declare the non-read-only, non-destructive, non-idempotent profile, but the description adds real behavioral context beyond them: a nonexistent entity_id still stores the episode unlinked and surfaces the id in context.entity_ids_descartados, omitted volatilidad/epistemico are auto-classified from the text, and source attribution fields are server-stamped from the caller's credential. It stops short of describing return shape or the effect of repeated identical calls (relevant given idempotentHint=false).

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-loaded with purpose and sibling routing before any parameter detail, and every sentence carries information rather than filler. The Args block is long, but that length is justified by 0% schema coverage; only minor tightening (e.g. repeated restatement of defaults) would be possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool with nested objects, no output schema, and zero schema-level documentation, the description supplies everything an agent needs: routing, failure behavior for an unknown entity_id, auto-classification defaults, and full semantics for every parameter. Nothing required to invoke it correctly is missing.

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 description coverage is 0%, so the description carries the full burden and does: every one of the 7 parameters is explained, including the undocumented enum-like values for volatilidad ('evento'/'estado'/'pendiente'), epistemico ('medido'/'inferido'/'reportado'), and the nested fuente object with its 'modo' values and optional keys. It even clarifies the content-dict contract (requires a 'description' key, otherwise stringified) and the metadata merge behavior.

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?

Opens with a specific verb+resource definition ('Store an episodic memory: a specific, timestamped event tied to an entity') and immediately distinguishes it from two named siblings, store_fact (timeless statements) and process_observation (entity resolution plus linked facts). An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use and when-not-to-use: 'Use it for things that happened; for timeless statements use store_fact.' It also names the richer alternative (process_observation) and the condition that selects it ('to also resolve entity mentions and store linked facts in one call'). Alternatives and selection conditions are fully specified.

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?