Skip to main content
Glama

Process observation

process_observation

Record a new observation in one call. The observation is stored as an episode, the entities it mentions are resolved or created, and optional relations between them are recorded.

Steps:
1. Each relation triple upserts its source and target entities by name and
   records the directed relation. Predicates and types outside the
   vocabulary accepted by relate_entities are not rejected. They are
   normalized to related_to / unclassified, and the original predicate is
   kept as evidence.
2. Each name in entity_hints reuses an entity already resolved in step 1,
   or an existing entity of any type whose name matches (exact
   case-insensitive match first, otherwise the closest search result). If
   nothing is found, a new 'unclassified' entity is created.
3. The text is stored as an episode linked to every resolved entity. If
   there are no entities, an 'observation' anchor entity is created
   instead.
4. One 'observed' fact (the first 200 characters) is stored on the first
   entity. The episode is attached as evidence for the relations and
   entities this call created.
5. If trigger_cycle is true, run_cognitive_cycle is run afterwards.

Returns episode, entities (with created flags), facts, relations (with
per-triple errors) and cycle.

Example:
    process_observation(
        content="Pedro joined Globex as CTO",
        entity_hints=["Pedro", "Globex"],
        relations=[{"source": "Pedro", "source_type": "person",
                    "predicate": "works_for", "target": "Globex",
                    "target_type": "organization"}],
    )

Args:
    content: The observation text. It is stored in full in the episode.
    source: Label for who produced the observation (e.g. 'agent', 'user', 'sensor', 'inference').
    entity_hints: Optional list of entity names mentioned in the observation.
    trigger_cycle: If true, run the cognitive cycle after storing.
    relations: Optional list of triples {"source", "predicate", "target", optional "source_type", "target_type", "valid_from", "supersede_previous", "epistemic_status"}. The types default to 'unclassified'. The temporal fields work as in relate_entities. Set supersede_previous to true to close the previous relation of the same kind (e.g. a person changed employer).
    epistemico: How the information is known, which sets its confidence ceiling: 'medido' (measured: returned by a system, reproducible; 1.0), 'reportado' (reported: told by a person or third party; 0.8) or 'inferido' (inferred: concluded by reasoning; 0.7). If given, it applies to the episode, the fact, newly created entities and any relation without its own epistemic_status. If omitted, it is guessed from the content for the episode and fact, and falls back to 'inferido'.
    fuente: Optional. How you came to know this: modo ('vivido' I did or said it, 'conversado' someone told me, 'leido' a document/web/another agent/tool output, 'pensado' I inferred it), de (who said it), con (who you were with, only if not your owner), para (who you did it for), canal (e.g. 'whatsapp'), donde (repo, project, URL). Who you were with and through which agent are stamped by the server from your credential. Applied to the episode and the fact.

Input Schema

NameRequiredDescriptionDefault
fuenteNo
sourceNoagent
contentYes
relationsNo
epistemicoNo
entity_hintsNo
trigger_cycleNo

Output Schema

NameRequiredDescriptionDefault
cycleNo
factsNo
episodeNo
entitiesNo
relationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / $defs / CognitiveCycleResult / description
      Previous value: -"Outcome of a full cognitive cycle (strengthen → hypothesize → discover)."New value: +"Outcome of a full cognitive cycle."
    • removedOutput schema / $defs / CognitiveCycleResult / properties / strengthen
      Removed value: -{
      -  "anyOf": [
      -    {},
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "title": "Strengthen"
      -}
    • addedOutput schema / $defs / CognitiveCycleResult / properties / world_model
      Added value: +{
      +  "anyOf": [
      +    {},
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "World Model"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / fuente
      Added value: +{
      +  "additionalProperties": true,
      +  "default": null,
      +  "title": "Fuente",
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the mutation/safety profile; the description goes well beyond by disclosing silent normalization (unknown predicates/types coerced to related_to/unclassified with the original kept as evidence), entity resolution order (exact case-insensitive match, then closest search hit, then new 'unclassified' entity), the 'observation' anchor fallback when no entities exist, the 200-character fact cap, and the trigger_cycle chaining to run_cognitive_cycle. These are exactly the non-obvious side effects an agent cannot infer from readOnlyHint/destructiveHint/idempotentHint.

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?

Purpose is front-loaded, the numbered steps mirror execution order, the worked example is genuinely illustrative, and the Args section is scannable. There is some duplication — "stored in full in the episode" repeats step 3, and the fallback-to-'inferido' rule is stated twice — which keeps it from being a tight 5 given the overall length.

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 high-complexity, 7-parameter, nested-object mutation tool with no schema documentation and no descriptive annotations, the description covers inputs, ordering, normalization, side effects, and the trigger_cycle cascade. A return-shape note is present too, though the output schema already covers that; nothing an agent needs to call 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% with 7 parameters including nested objects, so the description carries the full burden and does: every parameter is explained, relations enumerates its sub-fields (source, predicate, target, types, valid_from, supersede_previous, epistemic_status) with semantics, and epistemico spells out its three levels and their confidence ceilings (1.0/0.8/0.7) plus the fallback behavior. The fuente sub-keys (modo values, de, con, canal, donde) are likewise defined.

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 opening states a specific verb and resource ("Record a new observation") and immediately scopes it as a composite: stored as an episode, entities resolved or created, relations recorded. This distinguishes it from the single-purpose siblings store_episode, store_fact, create_entity and relate_entities without the agent needing to open 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 Guidelines4/5

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

The phrase "in one call" plus the five-step breakdown makes the intended context clear: use this when one observation spans text, entities and relations rather than chaining the primitive tools. It also anchors relations behavior to relate_entities ("Predicates and types outside the vocabulary accepted by relate_entities..."). It never states exclusions or a cost/side-effect tradeoff against calling store_episode + create_entity separately, so no explicit when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources