Skip to main content
Glama
Sign In

past.dev

by dev.past
OverviewDiscussionsAdmin

Recall a project's memory

recall_memory
Read-onlyIdempotent

Recalls from one project's memory, as POST /api/v1/recall does: the same arguments, the same refusals and the same answer, each result with its sources. With no identity it reads what the console's Memories screen shows: everything in the project. With an identity it reads as that identity: what the whole project sees, and the audiences that hold the identity. While ingestions of the project are still processing, pending says how many and that their memory is not in this answer yet. It spends credits where the recall is priced, as an API recall does: every recall on Pay as you go, and on Flex and Enterprise each one above the billing period's fair use, which get_plan states. Needs project Read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "recall_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNoThe order of the results after they are chosen: relevance (the default) or chronological.
levelNoThe evidence budget in words: low (8,000 tokens, the default), medium (16,000), high (24,000) or extra-high (32,000). Send this or maxTokens, never both.
limitNoHow many results at most, 1 to 200. 100 when omitted.
queryYesWhat to look for, in plain words.
projectNoThe project's slug, exactly as list_projects returned it. Omit it only when the organization has one live project.
identityNoRead as this identity: the customer's own id for one of their users. Omit it to read everything in the project, as the Memories screen does.
maxTokensNoThe evidence budget in tokens, for a figure no level gives. Send this or level, never both.
occurredToNoThe latest time the evidence may carry (ISO 8601), inclusive.
occurredFromNoThe earliest time the evidence may carry (ISO 8601), inclusive.
queryTimestampNoRecall as of this moment (ISO 8601), with only what was known then. Now when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / identity / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / level / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / project / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / sort / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses the credit-billing model (always on Pay as you go, above fair use on Flex/Enterprise, with get_plan as the source), the required permission, and the important partial-result behavior when ingestions are still processing ('pending says how many and that their memory is not in this answer yet'). These are exactly the traits an agent can't infer from structured fields.

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 the core operation, then identity semantics, then pending state, then billing — a sensible order with no filler sentences. It is dense and runs long in prose form, and a couple of clauses (project omission, level vs maxTokens) duplicate the schema rather than adding to it.

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 10-parameter tool with no output schema, it covers cost, permissions, visibility scoping, and partial results, and hints at return shape ('each result with its sources'). It does not describe the overall result envelope or how `pending` is surfaced, which matters somewhat given no output schema exists.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: what `identity` actually changes about visibility ('what the whole project sees, and the audiences that hold the identity') and that the no-identity mode mirrors the console. The level/maxTokens exclusivity and project-omission rule are restated from the schema rather than extended.

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 ('Recalls from one project's memory') with an explicit scope (one project), and anchors it to a concrete referent ('as POST /api/v1/recall does' / 'the console's Memories screen'). An agent can distinguish this read/recall operation from ingest_memory, get_timeline, or find_trace_roots without opening the 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 clear conditional guidance: omit `identity` to read everything as the Memories screen does, supply it to read as that identity; omit `project` only when the org has one live project. It also flags the prerequisite 'Needs project Read' and the credit cost, but never names a sibling tool as the alternative for adjacent jobs (e.g. timeline or lineage lookups).

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

All past.dev toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources