Skip to main content
Glama

knowledge_supersede

Idempotent

Merge duplicate knowledge pages by marking an old slug as superseded by a canonical page and archiving it with a tombstone link. Both pages must already exist.

Instructions

Mark one knowledge page as superseded by another, then archive the old page. Records the supersession relationship in the supersessions table. This is the dedup-merge primitive: write the canonical page with knowledge_write, then call knowledge_supersede(old_slug=loser, new_slug=canonical). Both pages must already exist. old_slug is archived with a tombstone pointing to new_slug.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note explaining the merge or supersession decision
new_slugYesSlug of the canonical replacement page (must already exist)
old_slugYesSlug of the page being retired (the duplicate or loser)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv0.4.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description does not contradict them: it clarifies that the old page is archived (not deleted) and left with a tombstone pointing to new_slug, which is genuinely added context about what state changes. It stops short of saying the action is reversible (e.g. via the sibling knowledge_restore) or what auth is needed.

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?

Four tight sentences, front-loaded with the effect, then the mechanism, then a concrete call example, then the postcondition. Nothing is repeated and no sentence is filler.

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?

Covers effect, precondition, sequencing and side effects for a mutation tool with no output schema, which is most of what an agent needs. Failure modes (e.g. what happens if new_slug does not exist) and the undo path are unstated.

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 the baseline is 3; the description earns extra by disambiguating the roles in prose ('old_slug=loser, new_slug=canonical') and by restating the existence precondition for both, which maps directly onto the two required parameters. The optional note parameter is left to the schema alone.

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+resource+consequence ('Mark one knowledge page as superseded by another, then archive the old page') and names the workflow role ('the dedup-merge primitive'). It also names the sibling it pairs with (knowledge_write), so an agent can place it in the pipeline without opening the schema.

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

Usage Guidelines4/5

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

Gives explicit sequencing ('write the canonical page with knowledge_write, then call knowledge_supersede') and a precondition ('Both pages must already exist'). It does not, however, say when to prefer this over the sibling knowledge_merge, which is the most likely confusion the agent will have.

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