Engram

Rehydrate Context

engram_rehydrate

Recover interrupted work after compaction, resume or lost context. Returns Markdown checkpoints, decisions, gotchas, open loops and recent events. Unlike engram_start, this restores the prior journal when available; unlike engram_recall or engram_smarter, it recovers session history rather than only searching durable knowledge.

session_id selects an accessible workspace session. Closed or teammate journals are read-only history, never reopened. Automatic recovery requires one active journal for this member, repo/project and authenticated OAuth connection or supplied agent_tool within the recovery window. Multiple matches return 409: list sessions and choose an id. since filters events after selection. If none matches, loads durable task memory and opens a journal. Repeating active recovery adds events; it does not erase history. Consumes workspace daily call quota. OAuth: memory:read and session:write.

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.
`task`	No	Concrete current goal or decision, e.g. diagnose checkout retries; used to focus context and session recovery.
`depth`	No	Default standard: up to 30 events/4 summaries; brief uses 12/2, full 60/8. This controls journal detail, not retrieval depth.
`since`	No	Optional ISO 8601 lower bound for journal events, e.g. 2026-10-16T10:00:00Z; omit for normal recent-session recovery.
`reason`	No	Recovery trigger, e.g. context compaction or resumed after interruption; recorded in the journal.
`project`	No	Product/project name for session context. Start/setup use it as the repository hint when repo is omitted.
`agent_tool`	No	Calling client name for attribution, e.g. codex, claude-code, cursor, or gemini. Omit if unknown.
`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

changedInput schema / properties / session_id / description

Previous value: -"Session id returned by start/rehydrate. Omit to let the server resolve the applicable recent session or retrieval attribution."New value: +"Exact journal id from start/rehydrate/list_sessions. Disambiguates parallel work; writing requires your active session. Rehydrate may read shared or closed history."

Changed9 schema fields changedOct 16, 2026

addedInput schema / properties / agent_tool / description

Added value: +"Calling client name for attribution, e.g. codex, claude-code, cursor, or gemini. Omit if unknown."

addedInput schema / properties / depth / description

Added value: +"Default standard: up to 30 events/4 summaries; brief uses 12/2, full 60/8. This controls journal detail, not retrieval depth."

addedInput schema / properties / project / description

Added value: +"Product/project name for session context. Start/setup use it as the repository hint when repo is omitted."

addedInput schema / properties / reason / description

Added value: +"Recovery trigger, e.g. context compaction or resumed after interruption; recorded in the journal."

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 / session_id / description

Added value: +"Session id returned by start/rehydrate. Omit to let the server resolve the applicable recent session or retrieval attribution."

addedInput schema / properties / since / description

Added value: +"Optional ISO 8601 lower bound for journal events, e.g. 2026-10-16T10:00:00Z; omit for normal recent-session recovery."

addedInput schema / properties / task / description

Added value: +"Concrete current goal or decision, e.g. diagnose checkout retries; used to focus context and session recovery."

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

Behavior4/5

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

Adds real behavioral context beyond the annotations: closed/teammate journals are read-only and never reopened, repeated recovery appends events rather than erasing history, daily call quota is consumed, and OAuth scopes are memory:read and session:write. These are consistent with destructiveHint=false, idempotentHint=false and readOnlyHint=false, but the description does not detail error modes or response shape beyond the return contents.

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 sibling differentiation, then mechanics — a sensible ordering with no filler sentences. It is dense and long, but each sentence carries operational information; slightly tighter grouping of the recovery preconditions would improve scannability.

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 an 8-parameter, zero-required, open-world-false recovery tool with an output schema present, the description covers purpose, alternatives, preconditions, disambiguation, quota and auth — everything needed to invoke it correctly. Return-value detail is correctly left to the output schema.

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 description coverage is 100%, so the baseline is 3, and the description goes further by explaining session_id's selection semantics (accessible workspace session; closed/teammate journals readable but not writable) and since's role (filters events after session selection). The remaining parameters (repo, task, depth, reason, project, agent_tool) are left to 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 ('Recover interrupted work after compaction, resume or lost context') and immediately names what it returns (Markdown checkpoints, decisions, gotchas, open loops, recent events). It explicitly distinguishes itself from three siblings (engram_start, engram_recall, engram_smarter), so an agent can route correctly without opening 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 Guidelines5/5

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

Gives explicit when-to-use-vs-alternatives ('unlike engram_start... unlike engram_recall or engram_smarter...'), states the preconditions for automatic recovery (one active journal for member/repo/OAuth connection within the window), and handles the 409 multi-match case by routing to list_sessions. Fallback behavior when nothing matches is also stated.

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?