Skip to main content
Glama

Retrieve memories

retrieve_memories
Read-onlyIdempotent

Retrieve memories by semantic relevance, by date window, or both. Returns episodes, facts, working memory, concepts, procedures and perceptions, each in its own list. For a single call that also aggregates entities and hypotheses on a topic, use cognitive_query.

With `query`, results are ranked by relevance, blended with usage (for
episodes) and confidence (for facts). Without `query`, episodes come newest
first and facts highest confidence first. `orden` set to 'reciente' or
'antiguo' returns episodes and facts in chronological order instead, by
when each thing happened. Retrieval records usage: each
returned episode's importance score rises slightly (so frequently used
memories rank higher later), and returned facts get their access count
updated. Superseded memories are still returned, with the correction
attached in `superseded_por`.

With `query` and no `memory_types`, the response also carries `rules`:
the user's rules relevant to this query, each with `cuando` (the situation
it covers) and `entonces` (what the user set for that situation). A
relevance judge selects them (0 to 3); `juez.alcance` is 'reglas' when the
judge looked only at rules and the other lists are unfiltered. When the
judge did not answer (`juez.aplicado` false), at most the two closest
rules by distance are returned with `juzgada: false`; measured, about half
of those do not apply to the query.

The response always includes:
- `totals`: matches per type within the relevance threshold, before
  limit/offset; use `offset` to page through the rest.
- `tipos_consultados`: the memory types actually queried.
- `ventana`: the date window applied ({inicio, fin, origen, etiqueta}).
  `origen: "inferida"` means a Spanish recency phrase in the query (such
  as "acabo de" or "hace un rato") narrowed the search to the last 24 hours;
  pass time_range="all_time" to disable that.

Args:
    query: Natural-language description of what to retrieve. Optional:
        without it and with a date window, the result is that window
        unranked.
    entity_id: Restrict to memories linked to this entity UUID.
    memory_types: Types to query; omit for all. Values: 'episodic',
        'semantic', 'working', 'conceptual', 'procedural', 'perception'
        (the response field names such as 'episodes' and 'facts' are
        also accepted). An unknown value returns 422 with the accepted values.
    limit: Total budget, split evenly across the queried types
        (limit // number of types). Default 50, i.e. about 8 items per
        type when all six are queried.
    offset: Skip the first N episodes/facts to get the next page.
    session_id: Include this session's working memory. Without it,
        `working_memory` is empty.
    time_range: Window label. Calendar days in the user's time zone:
        'today', 'yesterday', 'this_week', 'last_week', 'this_month',
        'last_month', 'this_year' (Spanish equivalents such as 'hoy',
        'ayer', 'anteayer' are also accepted). Rolling: 'last_1h',
        'last_6h', 'last_12h', 'last_24h', 'last_48h', 'last_72h',
        'last_7d', 'last_14d', 'last_30d', 'last_90d', 'last_180d',
        'last_365d'. Unbounded: 'all_time'. An unknown label returns 422.
    since: Inclusive ISO-8601 lower bound, e.g. '2026-08-01' or
        '2026-08-01T14:30:00'. A date without time starts at 00:00.
    until: Inclusive ISO-8601 upper bound. A date without time ends at
        the end of that day. `since` later than `until` returns 422.
    orden: 'relevancia' (default, the order described above), 'reciente'
        (newest first) or 'antiguo' (oldest first). Without `query`,
        pages are chronological. With `query`, each page holds the most
        relevant memories (as with 'relevancia') returned in date order;
        `offset` moves to the next most relevant ones.

`time_range` and `since`/`until` are mutually exclusive; combining them
returns 422. The window applies to every memory type: episodes by when
they happened, facts by the date of the fact (`valid_from`: when it
happened or since when it is true), perceptions by when they were
measured. Each fact carries `fecha_origen` ('declarada': given by its
writer; 'episodio': taken from the episode it came from, approximate;
'registro': when it was stored, nothing better known) and
`fecha_precision` ('momento', 'dia', 'mes', 'anio').

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "retrieve_memories"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
ordenNorelevancia
queryNo
sinceNo
untilNo
offsetNo
entity_idNo
session_idNo
time_rangeNo
memory_typesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / orden
      Added value: +{
      +  "default": "relevancia",
      +  "title": "Orden",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that retrieval itself writes state (episode importance scores rise, fact access counts update), that superseded memories are still returned with `superseded_por`, and how the relevance judge behaves, including the failure mode where up to two unfiltered rules return with `juzgada: false` and roughly half don't apply. The usage-recording side effect is a mild tension with readOnlyHint=true but is an internal salience update rather than a user-facing mutation, and disclosing it is exactly the kind of context annotations can't convey.

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

Conciseness3/5

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

Front-loaded correctly with purpose, sibling routing, and ordering rules before the parameter block, and the bulleted response contract is scannable. But it is very long, the `orden` behavior is explained once in prose and again under Args, and the return-shape exposition precedes the basics an agent needs to actually call it. Some of that length is forced by zero schema descriptions, yet it could still be tightened.

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?

There is no output schema, so the description supplies the response contract itself: `totals`, `tipos_consultados`, `ventana` and its `origen: "inferida"` case, `rules` with `cuando`/`entonces`, `juez.alcance`/`juez.aplicado`, and fact dating via `fecha_origen`/`fecha_precision`. For a 10-parameter, zero-coverage, multi-type retrieval tool, nothing an agent needs to call it or interpret the result 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 coverage is 0%, so the description carries the full burden and does: it enumerates the accepted `memory_types` values (plus alias field names), the full `time_range` label set split into calendar/rolling/unbounded with Spanish equivalents, `limit` semantics as a budget evenly split across types (50 → ~8 per type), `offset` paging, and `session_id`'s effect on `working_memory`. This is meaning the bare `{"type":"string"}` schema cannot supply.

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 and resource plus the two retrieval modes ('by semantic relevance, by date window, or both'), then enumerates the returned categories. It explicitly names `cognitive_query` as the sibling to use when entity/hypothesis aggregation is also wanted, so an agent can differentiate without reading 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 Guidelines5/5

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

States when each mode applies: with `query` results are ranked, without `query` and with a date window the result is that window unranked; `orden='reciente'/'antiguo'` overrides ordering. It also gives hard exclusions (`time_range` vs `since`/`until` is a 422, unknown enum values are a 422) and the `time_range="all_time"` escape hatch for inferred recency windows.

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