Skip to main content
Glama
Sign In
universal-memory

universal-memory

by YanAmorelli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sync_skills

Destructive

Synchronize one or all active canonical skills into native runtime directories after canonical content changes; keep divergent native copies or overwrite managed ones and return per-skill results.

Instructions

Synchronize one or all active canonical skills into native runtime directories. Use after canonical content changes; use sync_instructions for host instruction blocks and import_skill to bring external content into UMEM. Requires initialized project memory. Writes native copies; drift_decision=keep preserves divergent native content, overwrite permits replacement of managed divergent copies. Returns per-skill synchronization results and warnings, optionally including gitignore checks. Repeated sync can still create audit records; review drift before overwriting.

Input Schema

NameRequiredDescriptionDefault
targetsNoNative runtime registry IDs for synchronization. Omitted uses the workflow default targets; an empty list requests no explicit targets.
drift_decisionNokeep preserves changed native copies; overwrite permits replacing managed divergent copies. Defaults to keep.keep
check_gitignoreNoInclude warnings about native target gitignore coverage when true. Defaults to false; does not edit .gitignore.
skill_id_or_nameNoCanonical skill ID, slug, or unambiguous name. Omitted or blank synchronizes all active canonical skills.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.4
    • addedInput schema / properties / check_gitignore / description
      Added value: +"Include warnings about native target gitignore coverage when true. Defaults to false; does not edit .gitignore."
    • 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 / skill_id_or_name / description
      Added value: +"Canonical skill ID, slug, or unambiguous name. Omitted or blank synchronizes all active canonical skills."
    • addedInput schema / properties / targets / description
      Added value: +"Native runtime registry IDs for synchronization. Omitted uses the workflow default targets; an empty list requests no explicit targets."
  2. First observedv0.4.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag a destructive, non-idempotent write, but the description adds real context beyond them: native copies are written, drift_decision=keep preserves divergent content while overwrite replaces managed copies, and repeated sync still produces audit records. The warning to 'review drift before overwriting' is valuable, though it doesn't detail what is irreversibly lost on overwrite.

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 purpose is front-loaded in the first sentence and each subsequent sentence covers usage, prerequisites, or behavior. Some restatement of the drift_decision semantics already in the schema is slightly redundant, but nothing is padding.

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?

An output schema exists, so return values needn't be spelled out, yet the description still notes per-skill results, warnings, and optional gitignore checks. Combined with the prerequisite and drift-decision guidance, an agent has everything needed to invoke this write tool safely.

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 four parameters are already documented, and the description's drift_decision phrasing largely restates the schema text. It adds only a light operational cue ('review drift before overwriting') rather than new semantics for targets or skill_id_or_name, so the baseline 3 applies.

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 ('Synchronize one or all active canonical skills into native runtime directories'), including scope (one vs all). It explicitly separates itself from siblings sync_instructions and import_skill, so the agent can route correctly without opening 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 an explicit trigger ('Use after canonical content changes'), names two alternatives with their distinct roles, and states a prerequisite ('Requires initialized project memory'). This is close to ideal when/when-not guidance.

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