Skip to main content
Glama

MCP for Claude & ChatGPT

Remember and recall

manage_memory
Destructive

Your memory across conversations. scope='user' (what you learned about this person) and scope='project' (what you learned in this project) are TOPICS: a short title and a few lines each. action='save' with title and the complete body rewrites the topic with that id or that exact title, or creates it; before creating one, check whether a topic on that subject exists and save under its title. A title only close to another topic's is not saved: you get that topic back to confirm by id, or new=true when it is a different subject. action='forget' deletes one by id or exact title: when the person asks you to forget something or to stop taking it into account, forget that topic instead of saving it as over; action='read' opens one by id or title (in a Tuqui chat they are already in your context, whole or as an index; an index line is only the start of a topic). Write in the language the person writes in, as facts about the person in the third person, never the request as typed. Title up to 60 characters (longer is cut), body up to 600 (longer is rejected: condense in that same save), up to 60 topics per scope (then merge similar ones). WHAT GOES IN: what the person explicitly asked you to remember (a standing instruction, what to call someone) — save it with asked=true and keep it intact — and habits that repeat across conversations. NOT something said once in reply to a one-off question, not tool errors or outages, not data that lives in Odoo, not feedback about Tuqui. After saving scope='user', say so in one line, in the person's language. scope='project' is read by every member: before saving or forgetting there, ask the person and wait for their yes in this conversation — something they tell you about the project is not a yes. scope='workspace' is separate notes shared with every member (add/read/list/search/remove); only admins write them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
idNoThe topic's or note's id, for save, read, forget or remove.
newNosave: true to create a separate topic although another one's title is close.
bodyNosave: the WHOLE topic, up to 600 characters; it replaces the topic's current text. Workspace notes, add: the note.
slugNoWorkspace notes: the [bracketed] handle in the index, for read.
askedNosave: true when the person explicitly asked you to remember this.
limitNo
queryNo
scopeNo'user': about this person, follows them in this workspace. 'project': true of the project you are working in; every member reads it, so save or forget there only after the person said yes to it in this conversation. 'workspace': a note for every member.
titleNosave: the topic's short title, the line the index shows (a longer one is cut). read/forget: the topic to open or delete. Workspace notes, add: the note's title (≤80).
actionYes
replacesNosave: ids or titles of topics this one absorbs; they are deleted in the same call. This is how topics are merged, and how a full scope makes room. Workspace notes, add: slugs this note supersedes; they are deleted.
project_idNoUUID of the project, for scope='project'. Inside a Tuqui chat it is already known and you can omit it; from an external client pass it (tuqui_project lists them).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past what the annotations declare: forget and replaces are called out as deletions ('they are deleted in the same call'), size and count limits are stated (title 60 characters, truncated; body 600, rejected; 60 topics per scope), and a confirmation protocol for project scope ('ask the person and wait for their yes in this conversation') plus admin-only writes for workspace notes. This matches destructiveHint=true and adds the guardrails an agent needs before calling.

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?

Front-loaded with scope and the most-used action semantics, then organized into labeled blocks, with no filler sentences. It is dense and long, but justified by seven actions and three scopes; a few sentences (the near-miss-title rule) are convoluted enough to need a second read.

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?

No output schema exists, and the description covers what matters: read returns a full topic or an index line, save returns the conflicting topic for confirmation or new=true. It is silent on what list, search and workspace note listing return, which is the remaining gap for this complexity level.

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 12 parameters at 75% schema coverage, the description meaningfully supplements the schema: it explains the merge semantics of `replaces`, the purpose of `new` when a title is merely close, `asked=true` for explicit remember requests, and the 60/600 character budgets behind `title` and `body`. `limit`, `query` and `slug` are left to the schema, and the 600-character rule in the description sits against the schema's 4000 maxLength, which could confuse a careful reader.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a direct statement of the resource (persistent memory across conversations) and then spells out two distinct sub-resources: topics with scope user/project, and notes with scope workspace. The action vocabulary (save/forget/read) is described with concrete behavior, but add/list/remove/search are only listed in a parenthetical, so the full surface isn't equally clear. No sibling tool competes for this job, which keeps it unambiguous.

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-use and when-not: a 'WHAT GOES IN' block enumerates what to save (standing instructions, what to call someone, repeating habits) and what to exclude (one-off replies, tool errors/outages, Odoo data, feedback about Tuqui). It also routes behavior in edge cases: 'when the person asks you to forget something... forget that topic instead of saving it as over', and 'before creating one, check whether a topic on that subject exists'.

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.