Engram

Get Engram Proof

engram_proof

Read-onlyIdempotent

Audit adoption before a rollout or when checking whether the workspace is using memory and reporting outcomes. Takes no arguments. Returns JSON with memory-bank breakdowns, learning-loop activity, proof points and a benchmark checklist.

Does not change knowledge or run a benchmark. Use engram_setup for onboarding and engram_recall for task knowledge. Consumes workspace daily call quota. OAuth: memory:read.

Input Schema

Name	Required	Description	Default
No arguments

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 16, 2026

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

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), and the description adds value beyond them: no arguments required, the shape of the response, a quota consumption warning ('Consumes workspace daily call quota'), and the required OAuth scope (memory:read). That is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: purpose/trigger first, negative boundaries and alternatives second, operational facts (quota, auth) last. No filler, no repetition of the title.

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 zero-argument, read-only audit tool with an output schema and full annotation coverage, the description supplies everything an agent needs: when to call it, what it returns, what it does not do, siblings to prefer, quota cost, and auth scope. Nothing material 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?

The tool takes zero parameters, so the baseline is 4. The description explicitly confirms 'Takes no arguments', which is consistent with the empty schema but adds little beyond it.

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 action (audit adoption) and the concrete artifact returned (JSON with memory-bank breakdowns, learning-loop activity, proof points, benchmark checklist). This is clearly distinguishable from siblings like engram_recall and engram_report_outcome.

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 triggering conditions ('before a rollout', 'when checking whether the workspace is using memory'), an explicit non-use statement ('Does not change knowledge or run a benchmark'), and names alternatives with their own use cases (engram_setup for onboarding, engram_recall for task knowledge).

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?