Engram

Load Task Context

engram_smarter

Read-onlyIdempotent

Brief a materially different task within the same session. Unlike engram_recall, this combines goal-focused memories with optional procedural checklists; unlike engram_get_context, it ranks evidence for the task instead of returning category samples. Returns Markdown with ranked workspace/public memory and retrieval hints. Use engram_start to begin work and engram_rehydrate for lost context.

Example: {"repo":"engram","context":"Improve public-page delivery on Netlify while preserving localized SEO and onboarding."}. context states the whole goal; repo/file focus retrieval without reading local files. limit overrides depth; include_skills=false suppresses checklists. Records retrieval/session telemetry without editing knowledge. Consumes workspace daily call quota. OAuth: memory:read.

Input Schema

Name	Required	Description
`file`	No	File path/name used only as a search hint, e.g. src/auth.ts. Engram does not read or modify local files.
`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.
`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–30. Omitted defaults: focused=5, deep=12; explicit values override these defaults.
`context`	Yes	Natural-language task and relevant facts, e.g. migrate our PostgreSQL schema with zero downtime. Never include credentials or raw customer data.
`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.
`include_skills`	No	Include relevant procedural checklists. If omitted, the server infers this from task/context keywords; false suppresses checklists.

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"
+}

Changed7 schema fields changedOct 16, 2026

addedInput schema / properties / context / description

Added value: +"Natural-language task and relevant facts, e.g. migrate our PostgreSQL schema with zero downtime. Never include credentials or raw customer data."

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

Added value: +"File path/name used only as a search hint, e.g. src/auth.ts. Engram does not read or modify local files."

addedInput schema / properties / include_skills / description

Added value: +"Include relevant procedural checklists. If omitted, the server infers this from task/context keywords; false suppresses checklists."

addedInput schema / properties / limit / description

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

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

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.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, but the description adds behavior beyond them: it records retrieval and session telemetry 'without editing knowledge', consumes the workspace daily call quota, and requires the memory:read OAuth scope. Quota and auth requirements are exactly the operational context annotations cannot express.

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 differentiators, then the example, then operational notes — every sentence carries information. It is dense and leans on jargon like 'materially different task' and 'retrieval hints', which slightly slows parsing, but there is little true filler.

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 7-parameter, single-required-param retrieval tool with an output schema, the description covers the remaining gaps: session semantics, quota cost, auth scope, and telemetry side effects, while leaving return-format explanation to the output schema. Nothing an agent needs to invoke it correctly is missing.

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 cross-parameter semantics the schema states only in isolation: 'context states the whole goal; repo/file focus retrieval without reading local files. limit overrides depth; include_skills=false suppresses checklists.' It clarifies the interaction between depth/limit and the meaning of repo/file, though it does not add format detail beyond the schema's own examples.

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 ('brief a materially different task within the same session') and immediately positions itself against two named siblings, engram_recall and engram_get_context, explaining what it does differently (goal-focused memories plus optional checklists; ranked evidence rather than category samples). An agent can distinguish it from every other retrieval tool 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?

Explicitly names the alternative tools and the condition that selects them: 'Use engram_start to begin work and engram_rehydrate for lost context.' It also supplies a concrete example invocation showing the intended context shape, which removes ambiguity about when this tool is the right entry point.

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?