Skip to main content
Glama
Sign In
universal-memory

universal-memory

by YanAmorelli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

update_canonical_skill

Destructive

Validate and replace Markdown content for an existing canonical skill, writing it through the safe pipeline and optionally syncing native targets. Use for canonical edits only.

Instructions

Validate and replace Markdown content for an existing canonical skill. Use for canonical edits; use update_skill for latent metadata or rename_skill for a slug change. Requires initialized project memory and an active canonical selector. Writes canonical content through the safe pipeline; sync=true also updates native targets subject to drift_decision. Returns skill metadata, changed paths, warnings, and write references. Repeated calls can create audit/snapshot records even when content matches.

Input Schema

NameRequiredDescriptionDefault
syncNoSynchronize native runtime copies after the canonical write when true. Defaults to false, which only writes canonical content.
raw_markdownYesComplete replacement canonical SKILL.md Markdown including valid frontmatter; required and validated before writing.
drift_decisionNokeep preserves changed native copies; overwrite permits replacing managed divergent copies. Defaults to keep.keep
skill_id_or_nameYesActive canonical skill ID, slug, or unambiguous display name. Use list_skills to resolve it; not a latent candidate ID.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.4
    • addedInput schema / properties / drift_decision / description
      Added value: +"keep preserves changed native copies; overwrite permits replacing managed divergent copies. Defaults to keep."
    • addedInput schema / properties / raw_markdown / description
      Added value: +"Complete replacement canonical SKILL.md Markdown including valid frontmatter; required and validated before writing."
    • addedInput schema / properties / skill_id_or_name / description
      Added value: +"Active canonical skill ID, slug, or unambiguous display name. Use list_skills to resolve it; not a latent candidate ID."
    • addedInput schema / properties / sync / description
      Added value: +"Synchronize native runtime copies after the canonical write when true. Defaults to false, which only writes canonical content."
  2. First observedv0.4.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as destructive, non-readonly, and non-idempotent. The description adds that writes go through a safe pipeline, that sync=true propagates to native targets subject to drift_decision, and that repeated calls can create audit/snapshot records even when content matches. Those side effects and drift behavior go beyond the annotations without contradicting them.

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?

The description is front-loaded and compact, moving from purpose to alternatives to prerequisites to behavior. The sentence about return values is somewhat redundant with the output schema, and the density of semicolon-separated behaviors is high, but there is little wasted wording.

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

Completeness5/5

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

For a destructive canonical write with four parameters, many sibling alternatives, and an output schema, the description covers prerequisites, side effects, drift handling, and returns. It is complete enough for an agent to call correctly without needing the schema for safety context.

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 input schema already defines each parameter. The description adds relationship-level meaning: sync=true also updates native targets, those updates are subject to drift_decision, and an active canonical selector is required. That is useful beyond the individual field descriptions, though it does not restate raw_markdown semantics.

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?

The description begins with a specific verb and resource: 'Validate and replace Markdown content for an existing canonical skill.' It explicitly distinguishes this tool from update_skill and rename_skill, so an agent can identify its scope 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 Guidelines5/5

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

It states 'Use for canonical edits' and names the alternatives for latent metadata and slug changes. It also gives clear prerequisites: initialized project memory and an active canonical selector. This is explicit when-to-use guidance with sibling alternatives and a required context.

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