Engram

Recall Memory

engram_recall

Read-onlyIdempotent

Answer one concrete question from authenticated workspace/public memory before deciding or debugging. Unlike engram_smarter, this retrieves question-specific evidence without task checklists; unlike engram_get_context, it returns one ranked memory list instead of separate category samples. Use engram_rehydrate to recover an interrupted session.

Returns JSON with ranked memories, ids, trust/conflict signals and retrieval hints. Example: {"repo":"engram","query":"What did we learn about Netlify SSR costs?"}. No matches returns count=0; deepen or rephrase rather than assume the answer. repo/type/tags narrow the question; limit overrides the depth budget. Records retrieval telemetry without editing knowledge. Consumes workspace daily call quota; stop on quota errors and retry only transient failures. OAuth: memory:read.

Input Schema

Name	Required	Description
`repo`	No	Repository slug, e.g. engram or billing-api, within the authenticated workspace. This is a memory filter, not a filesystem path or workspace selector.
`tags`	No	Topic labels for storing or filtering memory; omit when no useful labels apply.
`type`	No	Knowledge category: team rule, reusable pattern, pitfall, proven fix, design decision, or library/version quirk.
`depth`	No	Default focused uses a small retrieval budget; deep expands it when focused results are insufficient. An explicit limit overrides the default budget.
`limit`	No	Maximum retrieved memories, 1–20. Omitted defaults: focused=5, deep=12; explicit values override these defaults.
`query`	Yes	Specific decision, error or question to search, e.g. how are checkout retries deduplicated?
`session_id`	No	Exact journal id from start/rehydrate/list_sessions. Disambiguates parallel work; writing requires your active session. Rehydrate may read shared or closed history.

Output Schema

Name	Required	Description
`text`	Yes	The same bounded payload as content[0].text; interpret it using format. JSON text contains the endpoint-specific fields described by this tool.
`format`	Yes	Payload encoding: Markdown context/checkpoint, serialized JSON data, or plain confirmation text.
`truncated`	Yes	True when the payload exceeded 120,000 characters and was cut with a notice. Narrow the request; truncated JSON is not parseable.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / session_id

Added value: +{
+  "description": "Exact journal id from start/rehydrate/list_sessions. Disambiguates parallel work; writing requires your active session. Rehydrate may read shared or closed history.",
+  "type": "string"
+}

Changed8 schema fields changedOct 16, 2026

addedInput schema / properties / depth / description

Added value: +"Default focused uses a small retrieval budget; deep expands it when focused results are insufficient. An explicit limit overrides the default budget."

addedInput schema / properties / limit / description

Added value: +"Maximum retrieved memories, 1–20. Omitted defaults: focused=5, deep=12; explicit values override these defaults."

addedInput schema / properties / query / description

Added value: +"Specific decision, error or question to search, e.g. how are checkout retries deduplicated?"

addedInput schema / properties / repo / description

Added value: +"Repository slug, e.g. engram or billing-api, within the authenticated workspace. This is a memory filter, not a filesystem path or workspace selector."

addedInput schema / properties / tags / description

Added value: +"Topic labels for storing or filtering memory; omit when no useful labels apply."

addedInput schema / properties / tags / items / description

Added value: +"Searchable topic label, e.g. oauth or postgres."

addedInput schema / properties / type / description

Added value: +"Knowledge category: team rule, reusable pattern, pitfall, proven fix, design decision, or library/version quirk."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "format": {
+      "description": "Payload encoding: Markdown context/checkpoint, serialized JSON data, or plain confirmation text.",
+      "enum": [
+        "markdown",
+        "json",
+        "text"
+      ],
+      "type": "string"
+    },
+    "text": {
+      "description": "The same bounded payload as content[0].text; interpret it using format. JSON text contains the endpoint-specific fields described by this tool.",
+      "type": "string"
+    },
+    "truncated": {
+      "description": "True when the payload exceeded 120,000 characters and was cut with a notice. Narrow the request; truncated JSON is not parseable.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "text",
+    "format",
+    "truncated"
+  ],
+  "type": "object"
+}

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive/closed-world), it discloses that retrieval telemetry is recorded without editing knowledge, that the call consumes workspace daily quota, to stop on quota errors, retry only transient failures, and the required OAuth scope memory:read. It also describes the zero-match behavior, which is behavioral, not schema, information.

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?

Dense and front-loaded: the routing comparison comes first, then return shape, then guardrails. Every sentence carries information, though the embedded JSON example and the compression of quota/OAuth/telemetry rules into run-on clauses make it heavier than needed.

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?

With an output schema present, the description needn't detail returns, yet it still summarizes ranked memories/ids/trust-conflict signals and retrieval hints. Filters, depth/limit interaction, auth scope, quota behavior, and fallback on zero matches are all covered — 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters with enums and defaults. The description adds only light framing ('repo/type/tags narrow the question; limit overrides the depth budget'), much of which duplicates the limit/depth interaction already stated in the schema.

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+resource: answering one concrete question from authenticated workspace/public memory. It explicitly distinguishes itself from engram_smarter (question-specific evidence, no checklists) and engram_get_context (one ranked list vs. category samples), so an agent can pick it apart from siblings without opening schemas.

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?

Gives the decision-time/debugging context ('before deciding or debugging'), names two alternatives with the conditions that select them, and routes session recovery to engram_rehydrate. It also tells the agent what to do when there are no matches (deepen or rephrase rather than assume).

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

All Engram 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?