Engram

Get Repository Context

engram_get_context

Read-onlyIdempotent

Audit repository knowledge by category: conventions, gotchas, patterns, solutions and architecture. Unlike engram_recall or engram_smarter, this searches each category separately and returns five sample arrays for coverage review, rather than one task-ranked list. Returns JSON with repo/file/total and up to 21 entries; this is a bounded search, not a full repository-memory export.

repo is required; file/task refine search without reading files. Only when all five categories have no repo matches does the search broaden to workspace/public memory. Empty results are valid. Does not edit 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`	Yes	Repository slug to inspect, e.g. billing-api. If no repo-specific memories match, the server broadens to workspace/public knowledge.
`task`	No	Concrete current goal or decision, e.g. diagnose checkout retries; used to focus context and session recovery.

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.

Changed4 schema fields changedOct 16, 2026

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

Added value: +"Repository slug to inspect, e.g. billing-api. If no repo-specific memories match, the server broadens to workspace/public knowledge."

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

Behavior5/5

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

Annotations already declare a safe read profile, but the description adds substantial operational context beyond them: OAuth scope memory:read, consumption of the workspace daily call quota, the bounded nature of the search (not a full memory export), the broadening behavior, and the explicit guarantee that it does not edit knowledge.

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 purpose and the key contrast to siblings before moving to bounds, fallback behavior, and operational notes. It is dense but nearly every sentence carries distinct, decision-relevant information, with only minor redundancy against the schema.

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?

An output schema exists, so return values need not be explained, yet the description still sketches the JSON shape (repo/file/total, up to 21 entries). Combined with annotations, a full schema, and clear scope/fallback/quota notes, an agent has everything needed to invoke it correctly.

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 all three parameters are already documented in the schema. The description restates that repo is required and that file/task refine the search without reading files, but adds little syntax or format detail beyond the schema, so the baseline of 3 applies.

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 ('audit repository knowledge by category'), enumerates the categories, and explicitly distinguishes itself from engram_recall and engram_smarter by explaining the per-category sampling vs. a single task-ranked list. An agent can differentiate this from all siblings 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?

Names the alternatives (engram_recall, engram_smarter) and the condition that selects this one (coverage review across five separate category arrays). It also states when broadening to workspace/public occurs and that empty results are valid, leaving nothing to inference.

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?