Engram

mcp_engram_query_with_momentum

Retrieve evolving concepts by blending semantic similarity with conceptual trajectory. Ideal for tracking actively changing knowledge, unlike standard recall for stable facts.

Instructions

Momentum-assisted recall: blends semantic similarity (q tensor, 80%) with conceptual trajectory (p tensor, 20%). Optional α re-weight (default true): multiplies blend by edge_volatility_scale(min goal-edge α) so static structure ranks above high-churn succession edges (RSI Cycle 24). WHEN TO USE INSTEAD OF recall: When you want concepts that are actively changing or evolving. Use regular recall for stable crystallized knowledge. Supports zedos_filter incl. 'training'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "mcp_engram_query_with_momentum"
  }
}

Input Schema

Name	Required	Description
`k`	No	Number of results to return (default: 5, max: 20)
`query`	Yes	Natural language query
`zedos_filter`	No	Optional: filter by memory type (same values as mcp_engram_recall, including 'training' for ZEDOS_TRAINING / richer CLS blocks). Leave unset for all types.
`alpha_weighted`	No	Optional override. Omit → ENGRAM_ALPHA_SPEED_GATE master (default on). true: re-weight 80/20 by goal-edge α; false: pure q/p blend.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.0-beta.12Aug 4, 2026

addedInput schema / properties / alpha_weighted

Added value: +{
+  "default": true,
+  "description": "Optional override. Omit → ENGRAM_ALPHA_SPEED_GATE master (default on). true: re-weight 80/20 by goal-edge α; false: pure q/p blend.",
+  "type": "boolean"
+}

Changed1 schema field changedv0.7.0-beta.2Jun 17, 2026

addedInput schema / properties / zedos_filter

Added value: +{
+  "description": "Optional: filter by memory type (same values as mcp_engram_recall, including 'training' for ZEDOS_TRAINING / richer CLS blocks). Leave unset for all types.",
+  "type": "string"
+}

First observedv0.1.0Apr 24, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden for behavioral transparency. It does disclose the ranking algorithm (80/20 blend and α re-weight) and mentions filter behavior, which is useful. However, it does not explicitly state that this is a read-only operation, what the return format is, or any side effects. For a query tool, this is a gap, though less severe than for a mutating tool.

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 description is a single paragraph with the core idea front-loaded and a distinct 'WHEN TO USE' section that improves scannability. However, it contains unexplained internal references like 'RSI Cycle 24' and 'goal-edge α' that an agent may not parse, and the phrasing could be tightened. Overall, it is efficient and well-structured, not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should clarify what the tool returns. It implies it returns memory results (indicated by 'recall' and the k parameter), but does not explicitly state the return format or any additional behavior like pagination or sorting. Given the moderate complexity (4 parameters, no annotations), the description is adequate but leaves room for more completeness.

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%, with each parameter already having a clear description. The description's explanation of alpha_weighted and zedos_filter largely repeats schema information or introduces opaque jargon (e.g., 'edge_volatility_scale', 'RSI Cycle 24') that adds little clarity. It does add context about the 80/20 blending, but not enough to elevate the score beyond the baseline.

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?

The description clearly identifies the tool as 'Momentum-assisted recall' and specifies its core function: blending semantic similarity (q tensor, 80%) with conceptual trajectory (p tensor, 20%). It also distinguishes itself from the sibling tool mcp_engram_recall by explicitly stating 'WHEN TO USE INSTEAD OF recall', making the purpose unmistakable.

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?

The description provides explicit usage guidance: 'WHEN TO USE INSTEAD OF recall: When you want concepts that are actively changing or evolving. Use regular recall for stable crystallized knowledge.' This clearly states when to use this tool versus the alternative. It also notes zedos_filter support including 'training', adding practical usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server