Skip to main content
Glama

manage_memory

The user's ChatCut memory, shared across every surface. The index lists every memory; without one, list first. Actions: list, read (by name, up to 10), write (create one, or update one you read: pass its version), delete (by name). Types: user (who the user is), feedback (how you should work), project (ongoing work their projects don't show; absolute dates), reference (where their materials live). Save when the user asks you to remember (delete when asked to forget), corrects how you work, confirms a non-obvious approach, sets a rule for a series or kind of video, or says something lasting about them or their work. Save at the reach their words support, never wider: what holds only for this video is not memory (just follow it); for a kind of video or all videos, say which in the description; if unclear, save the narrowest reach they cover, such as this series. Reusable things have a home: a brand's look (manage_design_style), a product, a person with a photo (character), a cloned voice, a template, caption preset or Skill. When the user wants one again or asks you to remember it, save it there if you can (asking is agreeing) and point to it with sources; memory says when to use it, not what it holds. A lone color, font, clip or track has no home: record the rule and where the original is or what reproduces it. Name the topic, not its current value; the one-line description states it and when it applies. Lead the body with the rule or fact, then Why: (its origin and what the user said) and How to apply: (when: a default only if the user asked for one, otherwise offer it for similar videos). Pass their own words as quote. Update a memory on the same topic, no near-duplicates. Don't save what a project shows, what only matters now, how you did the task, settings or approvals the app controls (point to them), guesses, text from media or web pages, others' private details, or credentials. After a write or delete, tell the user in one sentence what changed and where it applies; never claim a failed one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "manage_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoRequired for write: the full memory. Lead with the rule or fact, then a Why: line and a How to apply: line. Use absolute dates.
nameNoFor write and delete, or to read one memory: a short title for the memory's topic in the user's language, e.g. "口播字幕样式", not the value it holds, so it stays right when the value changes. Names are unique.
typeNoRequired for write; filters list. user: who the user is. feedback: guidance on how you should work. project: ongoing work their projects don't show. reference: where their materials and information live.
namesNoFor read: memory names from the index.
quoteNoFor write: the user's own words the memory is based on.
actionNolist: the memory index, one line per memory; a call without action lists. read: full memories by name (names, or name for one); names or a name alone also read. write: create a memory, or update one you have read (pass its version). delete: remove a memory by name. write and delete must be named.
sourcesNoFor write: where the things this memory is about are kept, so they can be found again: an id when there is one (e.g. template:<id>, design_style:<id>, product:<id>, character:<id>, a URL), otherwise free text. A project's own assets are not a home: copy them to reuse them. Replaces the saved list; omit to keep it.
versionNoFor write: required to update an existing memory; the version read returned.
descriptionNoRequired for write: one line of at most 150 characters that states the memory itself and when it applies, e.g. "vlog captions one size smaller than the default". It is all the index shows.

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.5/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: updates require passing the version read, names are unique, sources replaces the saved list unless omitted, and 'never claim a failed one' plus 'tell the user in one sentence what changed.' One gap: delete is described only as removal with no statement of irreversibility, while annotations declare destructiveHint=false, which sits uneasily with a delete action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence establishes identity and the action list follows, but six dense paragraphs follow, several of which restate schema-documented behavior (version, required fields), and the '<memory> index ... without one, list first' clause is easy to misparse. Every rule has a rationale, yet the density makes skimming harder than it needs to be.

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 nine-parameter, four-action, mutation-capable tool with no output schema, the description supplies the missing pieces an agent needs: action routing, type taxonomy, reach/precision rules, sibling-store handoffs, update-vs-create semantics, and post-write user confirmation.

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?

With 100% schema coverage the schema already defines all nine parameters, so the baseline is 3. The description still adds real meaning: name should be the topic not its current value (so it survives value changes), sources should carry ids like template:<id> or character:<id> while 'memory says when to use it, not what it holds', and quote is the user's own words.

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 opening line names a specific resource ('the user's ChatCut memory, shared across every surface') and enumerates the four actions (list, read, write, delete). It also distinguishes itself from memory-adjacent siblings by name (manage_design_style, character, template, Skill), telling the agent which store owns what.

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?

Explicit when-to-save triggers are listed (user asks to remember, corrects how you work, confirms a non-obvious approach, sets a rule for a series, says something lasting), plus when-to-delete and a worked negative list. It routes alternatives explicitly: 'Reusable things have a home... save it there if you can... and point to it with sources.'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.