MemScope

Save memory

save_memory

Use this when a durable fact, decision, convention or owner is worth keeping for the person or their team, or the person asks you to save something; one fact per call. Never transcripts, conversation history, chit-chat, one-off requests or secrets. Use scope: "shared" for organization-wide knowledge and "personal" for the person's own items; pass team/project when the context is known; the organization's policy decides who may read it. Confirm with the result's visible_to (e.g. 'Personal: only you') and ai_checks. related lists readable memories it duplicates, updates or contradicts, with a suggestion; it is never merged. Set kind and valid_until when known, supersedes when it replaces a memory.

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": {
      "content": "<content>"
    },
    "name": "save_memory"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Optional type of memory.
`team`	No	Team to file it under: id, slug, name or alias of a team you belong to. Unknown ones are rejected.
`agent`	No	Your agent label.
`scope`	No	The widest audience: 'shared' (= 'organization'), 'personal' (= 'private'), 'team' or 'project' (personal if the group cannot be resolved). Omitted: the given team or project, else the organization's default. AI checks may narrow it.
`run_id`	No	Your run id.
`content`	Yes	One self-contained fact, decision or convention, up to 8000 characters.
`project`	No	Project to file it under: id, slug, name or alias of a project you belong to. Unknown ones are rejected.
`importance`	No	0.0 (routine) to 1.0 (critical), default 0.5. A floor: classification may raise it.
`supersedes`	No	Id of a memory this one replaces.
`valid_until`	No	ISO date/datetime it stops applying (future, within 5 years).
`idempotency_key`	No	Optional, up to 200 characters (e.g. a UUID): a retry with the same key returns the first save instead of a duplicate.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, it discloses that the organization's policy decides readership, that the result exposes `visible_to` and `ai_checks` for verification, and that `related` memories are never merged but come with a suggestion. That is materially more than the readOnlyHint/destructiveHint/idempotentHint flags carry.

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?

Guidance is front-loaded with use/never-use before the parameter advice, and every sentence carries content. The scope and result paragraphs are semicolon-dense, which makes them slightly harder to scan than a list would 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?

With 11 parameters, an output schema and a mutation annotation set, the description covers triggering, exclusions, scope semantics, and how to interpret the `related`, `visible_to` and `ai_checks` fields. An agent has everything needed to call it and verify the outcome.

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; the description earns a bump by explaining when to pass `scope: "shared"` vs `"personal"`, when to supply `team`/`project`, and when to set `kind`, `valid_until` and `supersedes`. It is guidance rather than restatement, though several optional parameters (`agent`, `run_id`, `importance`, `idempotency_key`) go unmentioned.

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?

The opening clause names a specific verb ('save') and resource ('memory') and enumerates the durable things worth storing (fact, decision, convention, owner), plus the 'one fact per call' rule. It does not distinguish itself from the sibling `remember`, which reads like an overlapping save path, so full marks are withheld.

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 positive triggers (durable facts, user asks to save) and explicit exclusions (transcripts, conversation history, chit-chat, one-off requests, secrets). Scope routing rules — shared for organization-wide, personal for the person's items, team/project when context is known — leave little to inference.

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

All MemScope tools Inspect

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

Need Help?