Engram

Report Memory Outcome

engram_report_outcome

Record whether a recalled memory helped; returns a confirmation. Use its exact memory_id and evidence in detail. success=false may include failure_reason; outdated marks obsolete knowledge, while success raises confidence.

Only accessible workspace/public memories may be reported. Repeating adds outcomes and changes confidence; do not blindly retry. Use engram_store with supersedes_memory_ids for a verified replacement, or engram_reflect to batch milestone outcomes. Consumes workspace daily call quota. OAuth: outcome: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.
`detail`	No	Brief evidence of how the memory changed the decision, or why it failed. Exclude secrets.
`success`	Yes	Whether this memory helped the actual task: true for a useful application, false for a misleading or unusable result.
`memory_id`	Yes	Exact id from a recalled memory; do not substitute a repository name, URL, or the memory text.
`session_id`	No	Session where this memory was retrieved; used for outcome attribution, not to reopen or modify that journal. May be closed.
`failure_reason`	No	Why an unsuccessful memory failed; outdated marks obsolete knowledge. Omit for a successful use.

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: +"Session where this memory was retrieved; used for outcome attribution, not to reopen or modify that journal. May be closed."

Changed7 schema fields changedOct 16, 2026

addedInput schema / properties / detail / description

Added value: +"Brief evidence of how the memory changed the decision, or why it failed. Exclude secrets."

addedInput schema / properties / failure_reason / description

Added value: +"Why an unsuccessful memory failed; outdated marks obsolete knowledge. Omit for a successful use."

addedInput schema / properties / memory_id / description

Added value: +"Exact id from a recalled memory; do not substitute a repository name, URL, or the memory text."

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

Added value: +"Whether this memory helped the actual task: true for a useful application, false for a misleading or unusable result."

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 only declare the safety profile (readOnly=false, idempotent=false, destructive=false). The description goes well beyond: repeats accumulate outcomes and shift confidence, only accessible workspace/public memories are reportable, the call consumes daily quota, and OAuth scope outcome:write is required. It is also consistent with idempotentHint=false rather than contradicting it.

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?

The core action is front-loaded and most sentences carry distinct payloads (mechanics, restrictions, retry warning, alternatives, quota, auth). It is denser than ideal with several constraints packed into the second paragraph, but nothing is 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 mutation tool with 6 params and an output schema, the description covers everything an agent needs: auth scope, quota cost, mutation/idempotency behavior, eligibility restrictions, and sibling routing. Return values are handled by the output schema, so no gap remains.

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. The description still adds value by tying semantics to behavior: exact memory_id (not a name/URL/text), detailed evidence, failure_reason's meaning, and that success raises confidence. It does not add syntax beyond the schema, but it reinforces how parameters are meant to be supplied.

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 ("Record whether a recalled memory helped") plus the confirmation return. It also separates itself from engram_reflect ("batch milestone outcomes") and engram_store ("verified replacement"), so an agent can route without opening a sibling 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 (record a recall outcome with the exact memory_id and detailed evidence), when-not (do not blindly retry because repeats mutate confidence), and named alternatives with the conditions that select them (engram_store with supersedes_memory_ids, engram_reflect for milestones).

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?