Engram

Explain Engram Setup

engram_setup

Read-onlyIdempotent

Explain onboarding and inspect the authenticated workspace when an agent needs setup guidance. Returns one JSON response with plan/counts/limits, tool groups, activation checklist and suggested calls; no pagination or installation.

Hints personalize examples: project names the work; repo scopes activation guidance, falling back to project when omitted. Does not configure the machine, open a working session or edit knowledge. Use engram_start to begin work, engram_rehydrate to recover it and engram_proof to audit adoption. Consumes workspace daily call quota; exhaustion requires reset or a plan change. OAuth: memory:read.

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.
`role`	No	Agent responsibility used in task context, e.g. backend engineer. Start/setup default to implementation agent.
`task`	No	Concrete current goal or decision, e.g. diagnose checkout retries; used to focus context and session recovery.
`stack`	No	Project technologies used to focus context; omit when unknown.
`market`	No	Business/domain context, e.g. fintech or education; not a geographic access setting.
`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.

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.

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

Added value: +"Business/domain context, e.g. fintech or education; not a geographic access setting."

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

Added value: +"Agent responsibility used in task context, e.g. backend engineer. Start/setup default to implementation agent."

addedInput schema / properties / stack / description

Added value: +"Project technologies used to focus context; omit when unknown."

addedInput schema / properties / stack / items / description

Added value: +"Technology name, e.g. TypeScript or PostgreSQL."

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

Behavior4/5

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

Annotations already declare this safe (readOnly, idempotent, non-destructive), yet the description still adds quota behavior ('Consumes workspace daily call quota; exhaustion requires reset or a plan change'), the required OAuth scope (memory:read), and the absence of pagination/installation. A mildly useful return-shape summary is also given even though an output schema exists. Strong additive disclosure above the annotation floor — though quota language is terse about how much each call costs.

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?

Purpose and return shape are front-loaded, then exclusions/alternatives, then hint semantics, then quota and auth — a logical order with no filler sentences. It is dense and slightly overpacked (four clauses in the quota/auth tail), but every sentence carries distinct information.

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?

Covers the areas an agent actually needs to call this correctly: what comes back, that pagination/installation are out of scope, the sibling routing, the quota cost, and the auth scope. With an output schema present, it is not obligated to detail return values, so nothing material is missing.

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 coverage is 100%, so the schema already documents all seven parameters in detail; the baseline is 3. The description's only param-relevant contribution — 'project names the work; repo scopes activation guidance, falling back to project when omitted' — largely restates what the schema already says about repo/project, so it adds little beyond the structured fields.

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 ('Explain onboarding and inspect the authenticated workspace') and immediately frames the trigger ('when an agent needs setup guidance'). It explicitly differentiates itself from siblings by naming engram_start, engram_rehydrate and engram_proof with their distinct purposes, so an agent can route 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?

Provides explicit when-to-use (setup guidance) plus explicit exclusions ('Does not configure the machine, open a working session or edit knowledge') and names three alternatives with the condition that selects each (begin work, recover it, audit adoption). This is the full when/when-not/alternatives triad.

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?