Skip to main content
Glama
Sign In

Configure Memory

by dev.configure.mcp
OverviewDiscussionsAdmin

configure_profile_remember

Keeps Configure, the user's long-term memory across all their assistants, current. Check configure_profile_search on the topic first, in an earlier step, and read its result before this call: when the result already lists the fact, in any wording, skip the save; when it is missing, or Configure holds an older version (moved cities, changed jobs), save the new fact here. Saving without that search risks a duplicate. Call it as soon as the user mentions a lasting fact about themselves, whether or not they ask you to remember it (an explicit "remember that" still gets the search first), even in passing inside another request: a preference, a diet, a habit, a relationship, an ongoing goal (training for a marathon), or a change in their life. "By the way, I like Chinese food" and "Where should I get dinner Friday? I really like Chinese food" both mean searching for Chinese food, saving "Likes Chinese food" if it is new, then answering. What the user is doing or asking about right now is not a fact about them: one-off task details ("needs a table for four on Friday"), temporary plans ("in Chicago for a conference this weekend"), the bug or error they want fixed. These, what you infer from them ("is a React developer"), your own guesses, and passwords, payment, health or government identifiers are not durable facts and stay out unless the user asks. Save one clear fact per call, quietly, with no need to ask first unless the user has asked not to save; several facts mentioned together get one call each. Bulk pasted material and exports go to configure_profile_import. Your own work is not a fact about the user: what you built, shipped, debugged, or are tracking belongs on the shared project shelf, so file it with box "projects/" for the next agent to read back, or leave it out. Optionally file the fact into a box (a shelf within your namespace) with the box argument: reuse an existing box id from the profile table of contents when one fits, otherwise pass a short new lowercase name and it is created on the spot. Writes under your own server-resolved agent namespace (identity is resolved from the authenticated session rather than from arguments) and returns the stored memory id and source. Additive: it never deletes or overwrites existing memories, and never emails, posts, or publishes anything on the user's behalf.

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": {
      "fact": "<fact>"
    },
    "name": "configure_profile_remember"
  }
}

Input Schema

NameRequiredDescriptionDefault
boxNoOptional. The namespace box (shelf) to file this under. TWO KINDS. (1) A topic box, for facts about the user: "work", "contacts", "health". (2) "projects/<slug>", the shared handoff shelf, for notes written for OTHER AGENTS rather than about the user — status, handoffs, and what you did on a shared piece of work. Work called "billing-migration" goes to box "projects/billing-migration". Reuse an existing box id from the profile table of contents when one matches; otherwise a short new lowercase name creates that box instantly. Omitted files it under "other".
factYesRequired. The single durable fact to store, phrased as a concise standalone statement about the user (for example "Prefers vegetarian restaurants"). One fact per call; do not batch multiple facts or paste transcript text.
kindNoWhat kind of note this is, for "projects/<slug>" notes. Set it whenever you are stuck or need something back from another agent: "blocker" (you cannot proceed) and "question" (you need an answer) are the two that get tracked as OPEN until another note resolves them. A note with no kind is never reported as outstanding, however urgent its text. This is not configure_profile_import's kind, which is a different vocabulary for how a dump is processed; and an unrecognized value here is never fatal, the note is saved unclassified and the result names the value that was ignored.
reply_toNoOptional. Memory id ("mem_...") of a note in the SAME box this one answers. Ids appear on notes when you open a project box.
resolvesNoOptional. Memory id ("mem_...") of a question or blocker in the SAME box that this note closes, which is what stops it being reported as open.

Output Schema

NameRequiredDescriptionDefault
boxNoBox the note was filed under.
errorNo
savedNo
memoryNo
sourceNo
distilledNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the write is additive and never overwrites or deletes, that it never emails/posts/publishes, that identity is resolved from the authenticated session rather than arguments, that box names are created on the spot if new, and that the response carries the stored memory id and source. These are exactly the facts an agent needs before committing a memory.

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 critical rules are front-loaded, but the text is long and repeats material already in the schema (the box/projects explanation appears in both places) and layers examples and exclusions in a dense block. Most sentences carry information, yet the section on what counts as a fact versus a task could be tightened without losing guidance.

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 memory-write tool with five parameters, an output schema, and a sibling that could be confused for it, the description covers saving, deduplication, exclusions, privacy, namespacing, and routing to the project shelf. Nothing an agent needs in order to call it correctly is missing.

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, but the description adds real meaning: it explains box as a shelf within the agent's namespace, the reuse-existing-id-before-creating rule, and the distinction between topic boxes and the "projects/<slug>" handoff shelf. The kind, reply_to, and resolves parameters are left entirely to the schema, which keeps it just above baseline.

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 states a specific verb and resource (save a durable fact to Configure, the user's long-term memory) and explicitly positions it against siblings: search first, import for bulk, and the projects shelf for agent-facing notes. An agent can distinguish it from configure_profile_search and configure_profile_import without inspecting either 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 gives explicit when-to-use criteria (user mentions a lasting fact, whether or not they ask), a mandatory prerequisite pattern (search first, skip if the fact already exists, overwrite when Configure holds a stale version), and explicit exclusions (one-off task details, temporary plans, inferred facts, credentials, payment/health/government identifiers, the agent's own work). It even names the alternative route for bulk material and for agent handoffs.

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

All Configure Memory toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources