Retrieve and expand a specific memory, summary, observation, or evidence record by ID from prior results, optionally including predecessor history for context.
Expand one selected record from a prior tool result.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Memory, summary, observation, or evidence id. | |
| history | No | Include predecessors; evidence has none. | |
| correlation_id | No |
Changes observed during successful MCP inspections.
v0.6.2Input schema / properties / history / descriptionPrevious value: -"true: include predecessor lineage; evidence has no lineage."New value: +"Include predecessors; evidence has none."v0.6.1Input schema / properties / history / descriptionPrevious value: -"Set true to expand predecessor lineage for memory, summary, or observation records; evidence ids have no lineage."New value: +"true: include predecessor lineage; evidence has no lineage."Input schema / properties / id / descriptionPrevious value: -"Memory, summary, observation, or evidence id returned by a prior tool result."New value: +"Memory, summary, observation, or evidence id."v0.5.6Input schema / properties / afterRemoved value: -{
- "description": "Timeline observations after the focus item (default: 5)",
- "maximum": 20,
- "minimum": 0,
- "type": "number"
-}Input schema / properties / beforeRemoved value: -{
- "description": "Timeline observations before the focus item (default: 5)",
- "maximum": 20,
- "minimum": 0,
- "type": "number"
-}Input schema / properties / correlation_idAdded value: +{
+ "type": "string"
+}Input schema / properties / historyAdded value: +{
+ "description": "Set true to expand predecessor lineage for memory, summary, or observation records; evidence ids have no lineage.",
+ "type": "boolean"
+}Input schema / properties / id / descriptionPrevious value: -"Record ID to retrieve, interpreted according to kind"New value: +"Memory, summary, observation, or evidence id returned by a prior tool result."Input schema / properties / id / typePrevious value: -"number"New value: +"string"Input schema / properties / include_timelineRemoved value: -{
- "description": "Include surrounding observations in the same session",
- "type": "boolean"
-}Input schema / properties / kindRemoved value: -{
- "description": "Memory kind to retrieve (defaults to observation)",
- "enum": [
- "observation",
- "prompt"
- ],
- "type": "string"
-}Input schema / properties / max_lengthRemoved value: -{
- "description": "Max characters to return (default: 50000)",
- "minimum": 100,
- "type": "number"
-}Input schema / properties / offsetRemoved value: -{
- "description": "Character offset for large content (default: 0)",
- "minimum": 0,
- "type": "number"
-}v0.4.13v0.4.1v0.3.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that this is a read-only retrieval, does not explain what expansion returns, does not mention the optional history behavior, and gives no permission or side-effect context. The word 'expand' hints at non-destructive retrieval but that is the only signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single focused sentence with no wasted words, front-loading the core action. It is perhaps too terse for the gaps it leaves, but structurally it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only source of behavioral context, and it says nothing about return shape, history semantics, or the undocumented correlation_id. For a retrieval tool that may return variable content, this leaves the agent without enough to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: the schema documents 'id' and 'history' with useful detail, while 'correlation_id' is undocumented. The description's only contribution is that 'id' refers to a record from a prior tool result, which adds marginal context beyond the schema. Baseline 3 fits given the partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'expand' plus the object 'one selected record from a prior tool result' makes the purpose reasonably clear: fetch the full detail of a single record referenced by a previous result. It does not differentiate itself from the sibling mem_recall, so an agent cannot tell from the text alone which retrieval tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from a prior tool result' implies the context of use — after another tool has returned a record stub — which gives some usage guidance. However, it never states when to use this vs. mem_recall or mem_context, and offers no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.