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. 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`.

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.

`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 when they were stored, perceptions by when they
were measured.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
sinceNo
untilNo
offsetNo
entity_idNo
session_idNo
time_rangeNo
memory_typesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior2/5

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

The description is unusually rich on ranking behavior (relevance blended with usage for episodes and confidence for facts), superseded handling, 422 error cases, and mutually exclusive parameters. However, it explicitly states that retrieval mutates stored state — 'each returned episode's importance score rises slightly' and 'returned facts get their access count updated' — which contradicts the declared readOnlyHint=true and idempotentHint=true. The disclosure itself is valuable, but it conflicts with the annotations an agent may rely on.

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, then the sibling alternative, then mechanics, then a per-argument block — a logical order with no filler sentences. It runs long (roughly 500 words) and repeats the 422 contract three times and restates the returned type list in both prose and response-field form, so it could be trimmed without losing meaning.

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 9-parameter, no-output-schema tool this is effectively complete: the response shape (`totals`, `tipos_consultados`, `ventana` including the `origen: "inferida"` case) is documented, all arguments are covered, cross-parameter restrictions are stated, and failure modes are enumerated. An agent could call this correctly without inspecting the schema.

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 9 undocumented, enum-less parameters, so the description must carry the whole load — and it does: exact accepted `time_range` labels (calendar, rolling, unbounded, plus Spanish aliases), ISO-8601 formats for `since`/`until` with boundary semantics, the `limit // number_of_types` budget split, `offset` paging, `session_id` gating working memory, and `memory_types` values with the 422 behavior on unknown input.

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 (retrieve memories) plus the three retrieval modes (semantic relevance, date window, or both), and names exactly what comes back (episodes, facts, working memory, concepts, procedures, perceptions). It also explicitly routes to the sibling `cognitive_query` for topic-level aggregation, so an agent can distinguish it without opening a 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 against an alternative: 'For a single call that also aggregates entities and hypotheses on a topic, use `cognitive_query`.' It also explains what happens without `query` (that window unranked) and gives an escape hatch ('pass time_range="all_time" to disable' inferred recency), which is precisely the guidance an agent needs to avoid a wrong call.

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