Skip to main content
Glama
Sign In
mcp-hyperspace-memory

mcp-hyperspace-memory

Official
by YARlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

memory_update

Replace an existing memory with updated text, refreshing embeddings and metadata while preserving session context; returns old and new memory IDs plus status.

Instructions

Update an existing memory by deleting memory_id and storing new_text with refreshed embeddings and metadata. Returns a JSON object with old_memory_id, new_memory_id, and status.

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": {
      "memory_id": "<memory_id>",
      "new_text": "<new_text>",
      "session_id": "<session_id>"
    },
    "name": "memory_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoUpdated tags for the new memory.
new_textYesThe updated memory text.
memory_idYesID of the memory to replace.
importanceNoUpdated importance level (1-10). Default: 5.
session_idYesSession identifier (keep the same as the original if updating in place).
memory_typeNoUpdated memory type. Default: 'episodic'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.2.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a decent job: it discloses the non-obvious delete-and-recreate semantics, that the memory ID changes, that embeddings and metadata are refreshed, and it summarizes the return payload. It omits whether the deletion is irreversible, what happens to existing links or derived edges pointing at the old memory_id, and any permission requirements.

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?

Two sentences, both front-loaded with the operation and the replacement semantics, followed by the return contract. Nothing is redundant and no sentence could be dropped without losing information.

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

Completeness4/5

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

For a six-parameter mutation tool with no annotations and no output schema, the description covers the operation, the destructive mechanism, and the return shape, which is most of what an agent needs. It falls short on the consequences of replacing a memory (whether links, edges, or history survive), which matters given the large family of memory_link and related sibling tools.

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 all six parameters already have descriptions and the baseline is 3. The description adds the useful detail that metadata is refreshed and that the result carries old_memory_id/new_memory_id, but it adds no meaning about tags, importance, memory_type, or the in-place session_id rule beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Update an existing memory') and goes further by explaining the mechanism: delete the old entry and store new_text with refreshed embeddings and metadata. It does not name or contrast with siblings such as memory_remember or memory_forget, but the 'existing memory_id required' framing makes the boundary reasonably evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the agent can infer this is for replacing a memory that already has an ID, versus creating one. There is no explicit when-to-use/when-not guidance, no mention of alternatives, and no caution about when updating in place is inappropriate versus forgetting and re-remembering.

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

Deploy Server

Other Tools