Maindex Expert Memory Service

memory_supersede

Destructive

Replace an existing memory with a new one. Creates the replacement, marks the old memory as deprecated (superseded_by → new), and creates a supersedes link. Tags from the old memory are automatically inherited by the new one (merged with any caller-provided tags). Mutates. Not idempotent. Returns the new memory with id and shortId. SOFT-DELETED: old_memory_id must refer to an active (non-deleted) memory; soft-deleted rows are not superseded by this tool (use memory_update to restore, or memory_recall with include_deleted only for read). Updating a deleted memory via memory_update is the supported undelete path, not memory_supersede.

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": {
      "old_memory_id": "<old_memory_id>",
      "headline": "<headline>"
    },
    "name": "memory_supersede"
  }
}

Input Schema

Name	Required	Description	Default
`body`	No	Body text of the new replacement memory
`kind`	No	Memory type for the replacement	note
`tags`	No	Tags for the replacement memory (merged with inherited tags from the old memory)
`team`	No	Team slug filter. Omit for mixed personal+team results. Use "personal" for personal-only.
`signer`	No	Agent identity -- who wrote this. Required fields: agent_id, run_id.
`source`	No	Source metadata for the replacement memory
`headline`	Yes	Headline of the new replacement memory
`metadata`	No	Arbitrary key-value metadata for the replacement
`collection`	No	Target team collection for team-scoped supersede (required when old_memory_id is team-namespaced unless inferrable from old memory)
`collections`	No	Collection slugs or IDs for the replacement
`canon_status`	No	Canon status for the replacement (defaults to accepted)	accepted
`old_memory_id`	Yes	ID of the memory being superseded

Output Schema

Name	Required	Description
`id`	Yes	UUID of the memory
`body`	Yes	Memory body content
`kind`	No	Memory type
`tags`	Yes	Tags attached to the memory
`status`	No	Memory status
`shortId`	Yes	Human-friendly short ID (mem-*)
`headline`	Yes	Memory headline
`metadata`	Yes	User-provided metadata
`createdAt`	Yes	ISO 8601 creation timestamp
`updatedAt`	Yes	ISO 8601 last-update timestamp
`confidence`	No	Confidence percentage (0-100)
`canonStatus`	No	Canon status
`collections`	Yes	Collections containing this memory
`verificationStatus`	No	Verification status
`restoredFromDeleted`	No	True when this update revived a soft-deleted memory (status was deleted, now active)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructive/non-idempotent, but the description adds substantive behavior: tag inheritance and merging, the supersedes link creation, the return payload shape (id and shortId), and the hard constraint that the target must be active. The soft-delete boundary is exactly the kind of state rule annotations cannot express.

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?

Front-loaded with the action and effects, then constraints. The final sentence restates the undelete guidance already given in the preceding parenthetical, which is mild redundancy in an otherwise dense, well-ordered description.

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 12-parameter mutation with nested signer/source objects and an output schema, the description covers the semantics an agent most needs: what changes, what is inherited, and what fails. Team/collection scoping and provenance-signing prerequisites are left entirely to the schema.

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 baseline is 3; the description earns above that by explaining the merge semantics of the tags parameter (inherited tags combined with caller-provided ones) and by constraining old_memory_id to active memories. It does not explain team/collection scoping or signer requirements, which remain purely schema-driven.

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?

Names a specific verb and resource ('Replace an existing memory with a new one') and immediately enumerates the three side effects (create replacement, deprecate old with superseded_by, create supersedes link). This distinguishes it cleanly from memory_update and memory_forget in the sibling list.

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-not guidance: soft-deleted rows are not superseded here, and names the correct alternatives (memory_update to restore, memory_recall with include_deleted for read-only inspection). It even closes the loop by stating memory_update is the supported undelete path rather than this tool.

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

All Maindex Expert Memory Service tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?