Skip to main content
Glama

supersede

Replace an existing memory node with a new node when a change needs a new identity, linking the successor back to the replaced node; use revise for in-place edits.

Instructions

Replace a node with a fresh one carrying new content, connected by a supersedes edge from the successor to the node it replaces. Use when the change is large enough to warrant a new identity; revise edits in place instead. new_type is optional — it defaults to the old node's.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
oldYesOld node name (or id).
tierNoTier override. A CLOSED vocabulary, one of exactly these: `operational`, `archival`. Defaults from the type. (Not the memory *layer* — that is `core`/`hot`/`warm`/`cold`/`frozen`, set by `layer`.)
new_bodyYesNew node body.
new_nameYesNew node name.
new_typeNoType for the successor. OPTIONAL — omit to keep the old node's own type, which is what a straight replacement wants. A CLOSED vocabulary, one of exactly these: `episode`, `task`, `checklist`, `roadmap`, `experiment`, `hypothesis`, `scratch`, `draft`, `audit_event`, `chain`, `board`, `idea`, `outcome`, `reference`, `concept`, `entity`, `summary`.
initiativeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.5

TDQS

A4.4/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 explain the core mutation mechanics: a new node is created and a supersedes edge is added from successor to the old node, so old is retained as the edge target. It also states the new_type default. However, it does not mention permission requirements, whether the old node's status changes, or any failure behavior, leaving some behavioral gaps for a mutation tool without annotations.

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?

Three compact sentences with zero waste. The primary operation is front-loaded, the alternative routing follows immediately, and the parameter note is a brief final fragment. Every sentence earns its place.

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 6-parameter mutation tool with no output schema, the description covers the essential semantics: what is created, how it is linked, and when to prefer the alternative. It omits return-value or error behavior, but without an output schema that is less critical; the remaining gap is minor side-effect detail on the old node.

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 description coverage is 83%, so the schema already documents most parameters including the new_type default. The description repeats the optionality and default of new_type but adds no syntax, format, or constraint details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource: replace a node with a new identity, connected by a supersedes edge. It explicitly contrasts with the sibling `revise`, so an agent can distinguish the two without inspecting both schemas.

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-to-use guidance ('when the change is large enough to warrant a new identity') and names the alternative tool (`revise`) with its opposite condition. Nothing is left to inference.

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