Hosted agent memory that learns from outcomes, with shared rooms. No key: mcp.mnemoverse.com/mcp
Scored across 11 tools
Most tools target clearly distinct actions (create/invite/join/list rooms, read/write/feedback, graph, stats). The only real overlap is memory_read (semantic search) versus memory_list_recent (newest-first listing), but their descriptions explicitly contrast these use cases, so misselection risk is low.
Ten of eleven tools follow a clean memory_<verb>_<noun> snake_case pattern (memory_read, memory_write, memory_create_room, memory_list_recent). The lone outlier vault_list is a separate vault subsystem rather than an inconsistency in convention.
Eleven tools is well-scoped for a memory server with three concerns (core memory ops, shared rooms, vault). Each tool maps to a distinct capability with no filler.
Covers the full memory lifecycle: write, read, recency-listing, ranking feedback, graph inspection, stats, plus room create/invite/join/list. Minor gaps exist (no leave/delete-room, no vault create/read — though delete is deliberately excluded by design), but agents can work around these.
Create a SHARED memory room — a space OTHER people's assistants can read, and write too when their invite granted read_write (the default scope), across Claude/ChatGPT/Cursor. Use when the user wants to share context or collaborate with someone else (e.g. 'make a room for me and my teammate'). Returns the room's address; pass that address as the domain on memory_write/memory_read to use it, and on memory_list_recent to catch up on what others added. People join through an invite minted with memory_invite_to_room.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Room name, unique within your account (e.g. 'launch-team'). | |
| description | No | Optional description of the room. |
| Name | Required | Description |
|---|---|---|
| name | No | The room name as stored. |
| address | Yes | Domain address (xroom:<id>); pass as `domain` on read/write. |
| room_id | Yes | The room's id (room_...); pass to memory_invite_to_room. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), so the description only needs to add context — and it does: it discloses the shared/cross-platform nature, the default read_write invite scope, and what is returned. It stops short of stating error behavior (e.g. duplicate-name rejection) or any permission/rate constraints, but the added context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and the usage trigger before the downstream instructions. The parentheticals (default scope, platform list, example phrase) are informative but make the middle slightly dense; nothing is redundant enough to remove outright.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still names the key return value (the room's address) and explains how to feed it into memory_write/memory_read/memory_list_recent, which is the critical integration knowledge an agent needs. Nothing required to invoke and then use the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description's mention of `domain` refers to other tools' parameters, not this tool's inputs, so it adds no meaning to `name` or `description` beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a SHARED memory room') and immediately qualifies the resource as a cross-assistant shared space, which cleanly separates it from siblings like memory_join_room and memory_list_rooms. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('Use when the user wants to share context or collaborate with someone else') with a concrete example utterance, and routes the complementary action to the named sibling memory_invite_to_room. The condition that selects this tool over its alternatives is stated rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether memories returned by memory_read were actually helpful. This is a learning signal, not a log: positive feedback raises a memory's ranking so it surfaces faster next time (across all of the user's tools), negative feedback lowers it so other memories out-rank it — nothing is erased and nothing decays with time. Use it after an answer that relied on or rejected memories from memory_read: pass the ids of those memories as memory_ids, with outcome 1 when they helped and -1 when they were wrong or stale. For memories read from a shared room, also pass that room's address as domain; your own memories need no domain. A read-only room member cannot rate the room's memories.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Only for memories read from a shared room: that room's address (xroom:...), exactly as you read it. Omit it for your own memories, which are rated by id alone. | |
| outcome | Yes | How helpful was this? 1.0 = very helpful, 0 = neutral, -1.0 = harmful/wrong | |
| memory_ids | Yes | IDs of the memories to rate, the `id:` line of each memory_read result. |
| Name | Required | Description |
|---|---|---|
| avg_valence | No | Average valence of the rated memories after the update. Reported as 0 in an asynchronous acknowledgement, where the real value is computed later — a 0 here is therefore not evidence of a neutral outcome. |
| updated_count | Yes | How many memories the service reports it applied the rating to. Processed synchronously this is the real count of memories that existed and were updated; processed asynchronously it is a best-effort ACCEPTED-count estimate — the number of IDs submitted — and the authoritative number is not known until the background worker runs. Zero means no submitted ID matched in the service's resolved request scope. |
| coactivation_edges | No | Number of links between query concepts and result concepts that this rating changed. This connector does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and idempotentHint=false; the description goes much further, disclosing that positive feedback raises ranking across all of the user's tools, negative lowers it, and that 'nothing is erased and nothing decays with time.' It also flags the permission constraint on shared rooms, which no annotation conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, and the three-sentence body covers signal semantics, usage, and permissions with little waste. It is slightly dense and repeats the outcome values the schema already lists, which costs it the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param mutation with an output schema present, the description covers everything an agent needs: the semantic effect of the call, when to invoke it, how to pass each parameter, and the permission edge case. Return values are correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: memory_ids are the id lines from memory_read results, outcome is tied to the helpful/wrong judgment, and domain is scoped to shared rooms with the explicit note that own memories need none. This goes modestly beyond the schema's own wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('report whether memories returned by memory_read were actually helpful') and ties the tool directly to the sibling memory_read, distinguishing it from memory_write/memory_create_room etc. An agent knows immediately this is a feedback/ranking signal, not a retrieval or write tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('after an answer that relied on or rejected memories from memory_read'), how to call it (pass ids as memory_ids, outcome 1 or -1), and the conditional case (pass domain only for shared-room memories; own memories need no domain). It even states a precondition/exclusion: a read-only room member cannot rate the room's memories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the association edges around given concepts: which concepts the memory has linked together, with each link's weight, outcome valence and co-activation count. Use to inspect what a memory store has learned or to explain why a read expanded to a concept. Reads your own graph, or a shared room's when its address is passed as domain; any other domain value has no effect. At depth 2 or 3 the engine drops edges below weight 0.05 unless min_weight is set. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Hops to expand from the seeds (1-3, default 1). At depth 2 or 3, if min_weight is omitted the engine floors edge weight at 0.05 at EVERY hop — including the first — so a hub concept cannot fan out across the whole store before limit applies; pass min_weight explicitly (0 included) to see every edge anyway. | |
| limit | No | Max edges to return (1-500, default 100 — mirrors memory_read's top_k bounds). | |
| seeds | Yes | Concepts to center the graph on (1-20, each ≤200 chars, non-blank) — e.g. ['deploy', 'staging']. An unrecognised concept simply contributes no edges; it is not an error. | |
| domain | No | Read a shared room's graph instead of your own: pass that room's address (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms. Unlike memory_read, any OTHER value has no effect here — the association store has no domain column, so a plain domain name behaves exactly like omitting this field. | |
| min_weight | No | Only include edges at or above this weight (≥ 0). Omit for no floor at depth 1; at depth 2/3 the engine applies its own 0.05 floor when this is omitted (see depth) — pass 0 to see every edge at every depth. |
| Name | Required | Description |
|---|---|---|
| edges | Yes | Association edges found within the requested depth. |
| nodes | Yes | Concepts touched by edges below. A seed with no surviving edge (unrecognised concept, or every edge fell below the weight floor) is not listed. |
| truncated | Yes | True when a per-hop server cap or limit cut the walk short — the store may hold more edges than are reported here. |
| min_weight_applied | Yes | The weight floor actually used at every hop: your min_weight when you set one (0 included); otherwise 0.05 from depth 2, or 0 at depth 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds non-obvious behavior: the 0.05 weight floor auto-applied at depth 2/3 unless min_weight is passed, that a non-address domain value is silently a no-op, and that an unrecognised seed is not an error. These are genuine surprises an agent would otherwise hit, though the trailing 'Read-only' merely restates the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what the tool returns, then usage, then the domain caveat, then the depth/min_weight caveat — a sensible ordering with no filler sentences. The final 'Read-only.' is redundant against the annotations, the only wasted token.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape explanation is unnecessary, and the annotations carry the safety profile. What remains — when to use it, the domain constraint, and the min_weight floor interaction — is fully covered, leaving nothing an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states only locally: how depth and min_weight interact (0.05 floor at every hop including the first) and that domain must be a room address, unlike memory_read. It does not add anything for seeds or limit, which the schema already documents fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Reads the association edges around given concepts') and enumerates what each edge carries (weight, outcome valence, co-activation count). This clearly separates it from sibling memory_read, which retrieves memories rather than the link structure between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete use cases: inspecting what a store has learned, and explaining why a read expanded to a concept — the latter implicitly points at memory_read as the upstream operation. It also scopes the domain parameter ('reads your own graph, or a shared room's when its address is passed'). No explicit when-not or named alternative tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint an invite for a room you own and get a ready-to-forward message. An invite is single-use by default; pass max_uses to let several people join with the same one. The user sends that message to the person they want to add (any messenger); the recipient opens the link or tells THEIR assistant the code to join. Use when the user asks to invite someone to a room they own, including one just created with memory_create_room.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Role the invitee gets — 'read' or 'read_write' (default read_write). | |
| room_id | Yes | The room's id (room_...), from memory_create_room. | |
| max_uses | No | How many people may join with this invite (default 1, single-use). | |
| expires_in_days | No | Days until the invite expires (default 7). |
| Name | Required | Description |
|---|---|---|
| code | No | The invite code (mnvr_...). Single-use by default, with a configurable use limit. Shown once. |
| scope | No | Role the invitee will get. |
| join_url | No | Landing URL the invitee can open to join. |
| expires_at | No | ISO 8601 expiry, or null. |
| room_address | No | The room's domain address (xroom:<id>). |
| share_message | Yes | Ready-to-forward invite text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety flags (non-readonly, non-idempotent, non-destructive). The description adds substantial behavior beyond them: single-use default, max_uses for multi-recipient, the message flow (user forwards, recipient opens link or tells THEIR assistant the code). That workflow context is exactly what annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the action and artifact. Each sentence carries distinct information (what it mints, the single-use default, the forwarding flow, the trigger) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need no explanation. The description supplies the trigger, defaults, and end-to-end workflow an agent needs; nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented with defaults and ranges. The description only reinforces max_uses' single-use default, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Mint an invite for a room') and immediately describes the concrete artifact produced (a ready-to-forward message). It is clearly distinguishable from siblings like memory_join_room or memory_create_room.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it: 'when the user asks to invite someone to a room they own, including one just created with memory_create_room,' naming a sibling. It lacks an explicit when-not or an alternative for the recipient side, but the trigger context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join a shared memory room using an invite code (starts with 'mnvr_'). Use when the user pastes an invite code or says something like 'join room with code ...'. The result gives the room's address, which is the domain for reading the shared room with memory_read, and tells you what you may do with it: memory_write to that address is only allowed when your membership scope is read_write; a read-only membership has that write refused; and when the server does not report a scope, whether memory_write would succeed is stated as unknown rather than promised either way.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The invite code (mnvr_...). |
| Name | Required | Description |
|---|---|---|
| name | No | The room name. |
| scope | No | Your role in the room ('read' | 'read_write'). |
| address | Yes | Domain address (xroom:<id>); pass as `domain` on read/write. |
| room_id | Yes | The room's id (room_...). |
| next_steps | Yes | How to use the room now. |
| already_member | No | True if you were already a member (no-op join). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, the description still adds real content: the join returns a room address usable as `domain`, and write permission depends on membership scope, with read-only writes refused and unknown scopes reported as unknown rather than promised. This is unusually candid about permission outcomes, though it stops short of describing what happens on an invalid or expired code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and trigger are front-loaded in the first two sentences, and every sentence carries information about downstream use. The closing scope sentence is dense and slightly convoluted, but it is not padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be re-explained, yet the description covers the one fact an agent needs to chain correctly (the address is the `domain` for reads) plus the write-permission conditionality. Complete for a single-parameter join tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists and schema coverage is 100%, so the schema already documents `code` and its 'mnvr_...' form. The description repeats the prefix convention without adding syntax, error behavior, or length/format nuance beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (join) and resource (shared memory room) plus the required input format 'mnvr_'. It is immediately distinguishable from siblings like memory_create_room and memory_invite_to_room, which are the adjacent operations in the same lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('use when the user pastes an invite code or says something like "join room with code ..."') and routes onward: the returned address is the `domain` for memory_read, and memory_write is conditional on scope. Alternatives and conditions are named rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the NEWEST memories first — no search query needed. Semantic search answers 'what do I know about X'; this answers 'what happened lately': resuming work after a break, catching up on a shared room ('any new messages?'), or reviewing what was saved recently. Pass since (your last-seen time) to get only what's new, and page through older entries with the returned cursor. Complete by construction WITHIN ONE SCOPE — nothing is skipped there, unlike a semantic search. A page is also bounded by SIZE, so a page of long entries comes back shorter than limit and hands you a cursor for the rest — nothing is dropped, and following the cursor is how you get it. To catch up on a shared room you MUST pass its address as domain: rooms are separate stores and an unscoped call never covers them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most entries per page (default: 20). Newest first. ⚠️ A CEILING, not a promise: the page is ALSO bounded by size, so a page of long entries stops early and returns a cursor for the rest. In rooms whose entries run long, ask for 5–10 — a large `limit` there buys nothing the size budget will not take back, and costs round trips. | |
| since | No | Only entries created at/after this ISO-8601 instant (naive = UTC) — your novelty watermark. | |
| until | No | Only entries created at/before this ISO-8601 instant (inclusive). Pair with `since` to read a closed window — 'what happened on Monday' — instead of paging back from now. | |
| cursor | No | Opaque cursor from a previous page's 'More older entries exist' line — continues the listing without skips or duplicates. | |
| domain | No | Restrict to one domain. REQUIRED to read a shared room — pass its address ('xroom:room_01ABC'), because rooms are separate stores that an unscoped feed does NOT cover. Omit only when you mean your own domains. Room addresses come from memory_list_rooms. Room entries are often long — a room feed usually reaches its size budget after a handful of them, so expect to page (see `limit`). | |
| exclude_author | No | Drop entries written by this author PRINCIPAL. ⚠️ NOT USABLE FROM HERE YET — the principal is never shown in these results, so there is no value you can get through this tool; a guess like 'me' filters nothing, silently. Same caveat as on memory_read. |
| Name | Required | Description |
|---|---|---|
| items | Yes | Entries newest-first (creation time descending). |
| next_cursor | No | Pass back as cursor for the next (older) page; null = listing complete. Absent when the service sent a continuation token this client will not pass on; the text then says the token could not be displayed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: completeness within a scope vs. semantic search gaps, size-bounded pages that return fewer than `limit` with a cursor, rooms being separate stores an unscoped call never covers, and the fact that `exclude_author` is currently unusable. This is unusually rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core contrast before operational detail, and nearly every sentence carries information. It is somewhat long, and the size-budget/ceiling explanation is restated in the parenthetical about `limit`, so there is minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return shape need not be explained, and the description still covers paging, scope completeness, room scoping, and the unusable parameter. Nothing an agent needs to invoke this correctly within a room vs. personal scope is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the per-parameter descriptions are already exhaustive, so the baseline is 3; the prose adds cross-parameter semantics the schema cannot easily convey (domain as the mandatory room address, since as a novelty watermark, limit as a ceiling rather than a promise, cursor as the continuation mechanism). Some of this duplicates the `limit` and `domain` schema text, keeping it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with explicit scope: 'List the NEWEST memories first — no search query needed,' and immediately contrasts itself against the semantic-search sibling ('Semantic search answers what do I know about X; this answers what happened lately'). An agent can distinguish this from memory_read/memory_list_rooms without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering scenarios (resuming work after a break, catching up on a shared room, reviewing recent saves) and an explicit negative case routing semantic questions elsewhere. It also states the hard requirement for room catch-up ('you MUST pass its address as domain'), which is exactly the when-to-use guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the shared memory rooms you can use — the ones you OWN plus the ones you've JOINED — each with the address to pass as domain on memory_read, and on memory_write too where your membership scope is read_write; a read-only membership has that write refused. Use this to RE-FIND a room in a new session (e.g. 'what rooms do I have?', 'resume the room with my teammate') instead of having to create or re-join it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| rooms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral context: the returned address is the value to pass as `domain` on memory_read and memory_write, and write is refused for read-only memberships. That permission nuance is not derivable from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and dense with useful content, but the middle clause nesting the `domain` usage for two other tools inside a dash-heavy sentence makes it harder to parse than a two-sentence split would be. Still, essentially every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and rich annotations cover the safety profile. The description fills the remaining gaps: usage scenario, cross-tool handoff via `domain`, and membership-based write refusal. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters (schema coverage 100% trivially), so the baseline is 4. The description's mention of `domain` belongs to sibling tools, not this one, so there is no additional parameter meaning to add here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb + resource ('List the shared memory rooms') with scope made explicit: rooms you OWN plus rooms you've JOINED. It is unambiguously distinguishable from siblings memory_create_room and memory_join_room, which the description implicitly contrasts against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the triggering scenario ('RE-FIND a room in a new session') with concrete user phrasings, and explicitly says to use this instead of creating or re-joining. Both the when and the not-this alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search long-term memory for user preferences, past decisions, project setup, people, or earlier context. The memory persists across sessions and across every AI tool the user has connected (Claude, ChatGPT, Cursor, VS Code). It applies when an answer may depend on something from an earlier session or another tool; it is not needed for general world knowledge. Returns matches ranked by relevance (or newest-first with order_by: 'recency'); each result carries an id; after the answer, memory_feedback takes these ids to record which memories helped. A wrong or stale memory is corrected by writing a fresh one with memory_write, not by deleting it.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language description of what you're looking for, e.g. 'database choice for the API' or 'user's preferred testing framework'. | |
| since | No | Only memories created at/after this ISO-8601 instant (naive = UTC) — e.g. your last-seen watermark in a shared room. | |
| top_k | No | Requested number of results (default: 5, what this connector asks for when you omit it; the engine's own default of 10 never applies, because the field is always sent). ⚠️ Not a hard cap: association expansion can return MORE than this, and the relevance floor can return fewer — raising it does not reliably widen the result set. For a complete, exactly-bounded listing use memory_list_recent instead. | |
| until | No | Only memories created at/before this ISO-8601 instant. | |
| domain | No | Restrict the search to one domain namespace (e.g. 'project:acme'). Omitting it searches your OWN domains — it does NOT include shared rooms, which are separate stores: to search a room, pass its address here (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms. | |
| order_by | No | 'relevance' (default) = ranking order. 'recency' = the matched set re-sorted newest-first. For a complete newest-first feed with no search at all, use memory_list_recent instead. | |
| diversity | No | 0 (default) returns the matches as ranked. Above 0, a match that is a near-copy of one already picked gives its slot to the next distinct memory (maximal marginal relevance); 1 lets similarity alone decide after the first pick. It changes which memories come back, not their scores, and applies only when there are more matches than top_k and top_k is below 200. | |
| exclude_author | No | Drop memories written by this author PRINCIPAL — the server-side identity. ⚠️ NOT USABLE FROM HERE YET: the principal is not shown in these results, so there is no value you can obtain through this tool, and a guess like 'me' silently matches nothing and filters nothing. Only pass it if your system knows the exact principal from elsewhere (e.g. the REST API). |
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching memories, ordered per order_by. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real context beyond them: the memory is shared across sessions and across every connected AI tool, results are relevance-ranked (or recency-sorted), each result carries an id, and stale memories are superseded rather than deleted. It stops short of describing latency, result size, or failure modes, but the behavioral picture is substantially richer than the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then persistence scope, then when/when-not, then return shape, then sibling routing — every sentence carries distinct information and there is no filler. Density is high but appropriate for a tool with this much behavioral nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no further explanation, and annotations cover the safety profile. The description complements both by covering cross-session/cross-tool scope, ranking semantics, the id-based feedback loop, and the correct path for correcting stale memories — nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the per-parameter docs already explain domain scoping, order_by, top_k caveats, and diversity in depth. The description mostly restates the relevance-vs-recency behavior already documented on order_by, so the baseline of 3 is correct; it adds workflow framing (ids feed memory_feedback) but little new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (long-term memory) and enumerates the content classes it holds (preferences, decisions, project setup, people, earlier context). It also distinguishes itself from siblings by naming memory_list_recent, memory_write, and memory_feedback in their proper roles, so an agent can route without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit positive and negative conditions: 'applies when an answer may depend on something from an earlier session or another tool; it is not needed for general world knowledge.' It further names alternatives for adjacent needs (memory_list_recent for bounded listings, memory_write for corrections, memory_feedback for attribution).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of the stored memory: total count, the number of learned concept associations, the list of domains, and average quality scores. This memory is shared across all AI tools the user has connected to Mnemoverse. Use it to orient yourself, to confirm the exact domain name before writing to it, or when the user asks what you remember. Read-only — changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| domains | Yes | User-defined memory domains. |
| episodes | No | Number of individual memories (not merged into a summary). |
| prototypes | No | Number of summary memories merged from several individual ones. Consolidation is not running on the hosted service, so this count does not currently grow. |
| avg_valence | No | Average valence of stored memories: how well recalls turned out, on a scale from -1 to 1. |
| memory_count | Yes | Number of saved memories. |
| hebbian_edges | No | Number of learned concept-to-concept associations; memory_graph reads them. |
| avg_importance | No | Average importance of stored memories, on a scale from 0 to 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the "Read-only — changes nothing" clause is redundant. The genuinely additive fact is that the memory is shared across all AI tools connected to Mnemoverse, which is scope information not available in the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the returned data, then sharing scope, then usage triggers — a sensible order with no filler. The final "Read-only — changes nothing" clause is redundant against the annotations and could be dropped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Zero parameters, an output schema (so returns need not be explained), and annotations covering the safety profile mean the description only needs context — which it supplies via the cross-tool sharing scope and usage triggers. Nothing an agent needs 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema-baseline of 4 applies and there is nothing for the description to compensate for. No parameter semantics are needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ("Get an overview") plus resource (stored memory), with the exact contents enumerated: total count, learned concept associations, domain list, average quality scores. This makes the aggregate nature clear against siblings like memory_read and memory_list_recent. However, no sibling is named or explicitly contrasted, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three concrete when-to-use triggers: orienting yourself, confirming the exact domain name before writing, and answering "what do you remember." These are actionable contexts. No when-not condition or named alternative (e.g., memory_list_recent for recency) is provided, so it isn't a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a long-term memory that persists across sessions and across every AI tool the user has connected to Mnemoverse (Claude, ChatGPT, Cursor, VS Code). Suited to durable information: a stated preference, a decision, a fact about people, roles or project setup, a lesson learned; transient chatter that only matters this turn does not belong here. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records. Behavior: outside shared rooms, a novelty gate refuses a write the embedder cannot tell apart from a memory already stored in the same domain, so the result tells you whether the memory was stored or refused. Write content as a self-contained statement that still makes sense when recalled out of context.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme'). Matched byte-for-byte — a leading space, a different case, or an invisible character opens a SEPARATE, permanent store, so reuse an exact name from memory_stats rather than retyping one. To write into a shared room, pass its address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms. | |
| content | Yes | The memory to store as a self-contained statement, e.g. 'User prefers TypeScript strict mode' or 'Decided to deploy the API on Cloudflare Workers (2026-06)'. | |
| concepts | No | Key concepts for linking related memories (e.g. ['deploy', 'friday', 'staging']) |
| Name | Required | Description |
|---|---|---|
| reason | No | The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. "Below importance threshold (0.047 < 0.1)". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display, and the value is capped at 400 characters. Absent when the service sent no explanation, or when nothing remains after that normalization. |
| stored | Yes | Whether the memory passed the novelty gate and was stored. |
| memory_id | Yes | Identifier of the stored memory, or null when it was not stored. |
| importance | No | Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. Outside shared rooms, a write that scores below the service's importance threshold is not stored, and `reason` says why when the service sends one. The score is approximate and can read lower for non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the novelty gate that can refuse near-duplicate writes outside shared rooms, noting that the result reports stored vs refused, specifying that domain matching is byte-exact so a stray space opens a separate permanent store, and listing forbidden content classes. This is exactly the kind of behavior an agent cannot infer from destructiveHint=false or idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and durability scope, then usage criteria, then constraints, then behavior. Dense but each sentence earns its place, with only mild overlap between the closing sentence and the schema's own description of the content field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter write tool with an output schema and annotations, the description covers the remaining gaps an agent needs: durability semantics, privacy boundaries, refusal behavior, and content authoring rules. Return structure is correctly left to the output schema while its outcome meaning is still summarized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description adds real meaning on top: content must be a self-contained statement that still makes sense when recalled out of context, which the schema only demonstrates by example. Domain semantics are mostly delegated to the schema, so it lands at 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (store) and resource (long-term memory) plus scope: persists across sessions and across every connected AI tool. This clearly separates it from siblings like memory_read, memory_list_recent, and memory_create_room, which read or set up rather than persist content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit inclusion criteria (stated preference, decision, fact, lesson learned) and exclusion criteria (transient chatter that only matters this turn does not belong here), plus a hard prohibition list. It stops short of naming sibling tools an agent should use instead for retrieval or routing, so it is strong but not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the secrets stored in your Mnemoverse Vault — by ALIAS and purpose only; the secret VALUE is never returned or shown to you, and no tool on this connector returns it. Use this to check WHICH secrets the user has stored and under what alias (e.g. the user says 'do I have a GitHub token saved?'). Only YOUR account's secrets are listed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| secrets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds crucial non-obvious behavior: the secret VALUE is never returned by this or any other tool on the connector, which prevents the agent from promising the user something impossible. It also discloses the account scoping constraint ('only YOUR account's secrets').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical constraint (no values returned) is front-loaded in the first sentence, and the use-case example is second. Slightly dense with em-dash asides, but every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich output schema, the description conveys the one thing the schema cannot: that only aliases, never values, are exposed. For a zero-param, read-only listing tool, nothing an agent needs 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description adds no misleading parameter-like claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (secrets stored in the Mnemoverse Vault) and immediately bounds the scope to alias and purpose only. This is clearly distinguishable from siblings like memory_read or memory_list_recent, which deal with memories rather than vault secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger scenario ('the user says do I have a GitHub token saved?'), which is strong usage context. It does not name an alternative tool to use instead for retrieving a secret, though the description implies no such tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
memory_create_room2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_feedback2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_graph2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_invite_to_room2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_join_room2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_list_recent2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_list_rooms2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_read2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_stats2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_write2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"vault_list2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"memory_read1 field changedInput schema / properties / diversityAdded value: +{
+ "description": "0 (default) returns the matches as ranked. Above 0, a match that is a near-copy of one already picked gives its slot to the next distinct memory (maximal marginal relevance); 1 lets similarity alone decide after the first pick. It changes which memories come back, not their scores, and applies only when there are more matches than top_k and top_k is below 200.",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}memory_create_room1 field changedInput schema / properties / name / descriptionPrevious value: -"Room name, unique within your account (e.g. 'me-and-olya')."New value: +"Room name, unique within your account (e.g. 'launch-team')."memory_feedback1 field changedOutput schema / properties / coactivation_edges / descriptionPrevious value: -"Number of feedback-driven query/result concept co-activation edges changed by the service. This is separate from ordinary Hebbian strengthening among a memory's own concepts. This connector does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0."New value: +"Number of links between query concepts and result concepts that this rating changed. This connector does not send query_concepts, so live calls through this tool report 0; asynchronous acknowledgements also report 0."memory_read1 field changedInput schema / properties / exclude_author / descriptionPrevious value: -"Drop memories written by this author PRINCIPAL — the server-side identity. ⚠️ NOT USABLE FROM HERE YET: the principal is not shown in these results, so there is no value you can obtain through this tool, and a guess like 'me' silently matches nothing and filters nothing. Only pass it if your system knows the exact principal from elsewhere (e.g. the REST API). A self-exclusion shortcut is planned."New value: +"Drop memories written by this author PRINCIPAL — the server-side identity. ⚠️ NOT USABLE FROM HERE YET: the principal is not shown in these results, so there is no value you can obtain through this tool, and a guess like 'me' silently matches nothing and filters nothing. Only pass it if your system knows the exact principal from elsewhere (e.g. the REST API)."memory_stats3 fields changedOutput schema / properties / episodes / descriptionPrevious value: -"Number of episodic (not yet consolidated) memories."New value: +"Number of individual memories (not merged into a summary)."Output schema / properties / hebbian_edges / descriptionPrevious value: -"Number of Hebbian concept-to-concept links, learned from concepts that occur together as memories are stored and used."New value: +"Number of learned concept-to-concept associations; memory_graph reads them."Output schema / properties / prototypes / descriptionPrevious value: -"Number of consolidated prototype memories."New value: +"Number of summary memories merged from several individual ones. Consolidation is not running on the hosted service, so this count does not currently grow."memory_write1 field changedOutput schema / properties / importance / descriptionPrevious value: -"Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. A first-generation metric UNDER ACTIVE DEVELOPMENT and known to be unreliable — the same content has measured ~0.08 in Russian against ~0.55 in English, so it under-reads non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score."New value: +"Novelty score for this write (0-1): how much it adds over the nearest memories already saved in the same domain. Outside shared rooms, a write that scores below the service's importance threshold is not stored, and `reason` says why when the service sends one. The score is approximate and can read lower for non-English text. It is not a verdict on whether the memory was worth keeping. Absent when the service sent no score."memory_feedback3 fields changedInput schema / properties / atom_idsRemoved value: -{
- "description": "Deprecated since 0.11, removed in 0.13: atom_ids is the old name of memory_ids, still accepted on its own until then. Pass memory_ids instead.",
- "items": {
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
-}Input schema / properties / memory_ids / descriptionPrevious value: -"Required: IDs of the memories to rate, the `id:` line of each memory_read result. (Optional in this schema only while the deprecated atom_ids is still accepted in its place.)"New value: +"IDs of the memories to rate, the `id:` line of each memory_read result."Input schema / requiredPrevious value: -[
- "outcome"
-]New value: +[
+ "memory_ids",
+ "outcome"
+]memory_graphmemory_create_room3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / description / descriptionPrevious value: -"Optional human description of the room."New value: +"Optional description of the room."Output schema / requiredPrevious value: -[
- "room_id",
- "address",
- "name"
-]New value: +[
+ "room_id",
+ "address"
+]memory_feedback9 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / atom_idsAdded value: +{
+ "description": "Deprecated since 0.11, removed in 0.13: atom_ids is the old name of memory_ids, still accepted on its own until then. Pass memory_ids instead.",
+ "items": {
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / domainAdded value: +{
+ "description": "Only for memories read from a shared room: that room's address (xroom:...), exactly as you read it. Omit it for your own memories, which are rated by id alone.",
+ "type": "string"
+}Input schema / properties / memory_ids / descriptionPrevious value: -"Personal-scope memory IDs from a prior memory_read. Shared-room IDs cannot currently be rated because this tool has no domain input."New value: +"Required: IDs of the memories to rate, the `id:` line of each memory_read result. (Optional in this schema only while the deprecated atom_ids is still accepted in its place.)"Input schema / properties / memory_ids / items / formatRemoved value: -"uuid"Input schema / properties / memory_ids / items / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"Input schema / properties / memory_ids / maxItemsRemoved value: -20Input schema / properties / outcome / descriptionPrevious value: -"Outcome signal: -1.0 (failure) to +1.0 (success)."New value: +"How helpful was this? 1.0 = very helpful, 0 = neutral, -1.0 = harmful/wrong"Input schema / requiredPrevious value: -[
- "memory_ids",
- "outcome"
-]New value: +[
+ "outcome"
+]memory_invite_to_room6 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / expires_in_days / descriptionPrevious value: -"Days until the invite expires (1-90, default 7)."New value: +"Days until the invite expires (default 7)."Input schema / properties / max_uses / descriptionPrevious value: -"How many accounts may redeem the invite (1-1000, default 1)."New value: +"How many people may join with this invite (default 1, single-use)."Input schema / properties / room_id / maxLengthPrevious value: -200New value: +100Input schema / properties / scope / descriptionPrevious value: -"Role the invitee gets: 'read' or 'read_write' (default read_write)."New value: +"Role the invitee gets — 'read' or 'read_write' (default read_write)."Output schema / requiredPrevious value: -[
- "code",
- "join_url",
- "share_message",
- "scope",
- "room_address",
- "expires_at"
-]New value: +[
+ "share_message"
+]memory_join_room2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / requiredPrevious value: -[
- "room_id",
- "address",
- "name",
- "scope",
- "already_member",
- "next_steps"
-]New value: +[
+ "room_id",
+ "address",
+ "next_steps"
+]memory_list_recent13 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from the previous page's next_cursor — continues the listing without skips or duplicates."New value: +"Opaque cursor from a previous page's 'More older entries exist' line — continues the listing without skips or duplicates."Input schema / properties / domain / descriptionPrevious value: -"Restrict to one namespace (e.g. a shared room address 'xroom:...'); omit for all."New value: +"Restrict to one domain. REQUIRED to read a shared room — pass its address ('xroom:room_01ABC'), because rooms are separate stores that an unscoped feed does NOT cover. Omit only when you mean your own domains. Room addresses come from memory_list_rooms. Room entries are often long — a room feed usually reaches its size budget after a handful of them, so expect to page (see `limit`)."Input schema / properties / domain / maxLengthRemoved value: -100Input schema / properties / exclude_author / descriptionPrevious value: -"Drop entries written by this author PRINCIPAL — the 'everyone but me' read in a shared room. Same parameter memory_read takes."New value: +"Drop entries written by this author PRINCIPAL. ⚠️ NOT USABLE FROM HERE YET — the principal is never shown in these results, so there is no value you can get through this tool; a guess like 'me' filters nothing, silently. Same caveat as on memory_read."Input schema / properties / limit / descriptionPrevious value: -"Page size (default: 20). Newest first."New value: +"Most entries per page (default: 20). Newest first. ⚠️ A CEILING, not a promise: the page is ALSO bounded by size, so a page of long entries stops early and returns a cursor for the rest. In rooms whose entries run long, ask for 5–10 — a large `limit` there buys nothing the size budget will not take back, and costs round trips."Input schema / properties / since / maxLengthRemoved value: -40Input schema / properties / until / descriptionPrevious value: -"Only entries created at/before this ISO-8601 instant (inclusive). Pair with `since` to read a closed window — 'what happened on Monday' — instead of paging back from now and discarding."New value: +"Only entries created at/before this ISO-8601 instant (inclusive). Pair with `since` to read a closed window — 'what happened on Monday' — instead of paging back from now."Input schema / properties / until / maxLengthRemoved value: -40Output schema / properties / items / items / properties / memory_id / formatRemoved value: -"uuid"Output schema / properties / items / items / properties / memory_id / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"Output schema / properties / next_cursor / descriptionPrevious value: -"Pass back as cursor for the next (older) page; null = listing complete."New value: +"Pass back as cursor for the next (older) page; null = listing complete. Absent when the service sent a continuation token this client will not pass on; the text then says the token could not be displayed."Output schema / requiredPrevious value: -[
- "items",
- "next_cursor"
-]New value: +[
+ "items"
+]memory_list_rooms2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / properties / rooms / items / requiredPrevious value: -[
- "room_id",
- "name",
- "address",
- "role",
- "scope",
- "archived"
-]New value: +[
+ "room_id",
+ "address",
+ "role",
+ "archived"
+]memory_read11 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / domain / descriptionPrevious value: -"Restrict recall to a single namespace, e.g. 'project:x' (default: all)."New value: +"Restrict the search to one domain namespace (e.g. 'project:acme'). Omitting it searches your OWN domains — it does NOT include shared rooms, which are separate stores: to search a room, pass its address here (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms."Input schema / properties / domain / maxLengthRemoved value: -100Input schema / properties / exclude_author / descriptionPrevious value: -"Drop memories written by this author PRINCIPAL (the server-side identity, not shown in these results). Useful when your system knows principals; a self-exclusion shortcut is planned server-side."New value: +"Drop memories written by this author PRINCIPAL — the server-side identity. ⚠️ NOT USABLE FROM HERE YET: the principal is not shown in these results, so there is no value you can obtain through this tool, and a guess like 'me' silently matches nothing and filters nothing. Only pass it if your system knows the exact principal from elsewhere (e.g. the REST API). A self-exclusion shortcut is planned."Input schema / properties / order_by / descriptionPrevious value: -"'relevance' (default) keeps ranking order; 'recency' re-sorts the matched set newest-first. For a complete newest-first listing without a search, use memory_list_recent."New value: +"'relevance' (default) = ranking order. 'recency' = the matched set re-sorted newest-first. For a complete newest-first feed with no search at all, use memory_list_recent instead."Input schema / properties / query / descriptionPrevious value: -"Natural-language query for saved memories. Do not include passwords, API keys, payment data, MFA codes, government IDs, or health records."New value: +"Natural-language description of what you're looking for, e.g. 'database choice for the API' or 'user's preferred testing framework'."Input schema / properties / since / descriptionPrevious value: -"Only memories created at/after this ISO-8601 instant (naive = UTC) — e.g. a last-seen watermark in a shared room."New value: +"Only memories created at/after this ISO-8601 instant (naive = UTC) — e.g. your last-seen watermark in a shared room."Input schema / properties / top_k / descriptionPrevious value: -"Maximum number of memories to return (1-50, default 5)."New value: +"Requested number of results (default: 5, what this connector asks for when you omit it; the engine's own default of 10 never applies, because the field is always sent). ⚠️ Not a hard cap: association expansion can return MORE than this, and the relevance floor can return fewer — raising it does not reliably widen the result set. For a complete, exactly-bounded listing use memory_list_recent instead."Input schema / properties / top_k / maximumPrevious value: -50New value: +500Output schema / properties / items / items / properties / memory_id / formatRemoved value: -"uuid"Output schema / properties / items / items / properties / memory_id / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"memory_stats6 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / properties / avg_importanceAdded value: +{
+ "description": "Average importance of stored memories, on a scale from 0 to 1.",
+ "type": "number"
+}Output schema / properties / avg_valenceAdded value: +{
+ "description": "Average valence of stored memories: how well recalls turned out, on a scale from -1 to 1.",
+ "type": "number"
+}Output schema / properties / episodesAdded value: +{
+ "description": "Number of episodic (not yet consolidated) memories.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / hebbian_edgesAdded value: +{
+ "description": "Number of Hebbian concept-to-concept links, learned from concepts that occur together as memories are stored and used.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / prototypesAdded value: +{
+ "description": "Number of consolidated prototype memories.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}memory_write7 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / conceptsAdded value: +{
+ "description": "Key concepts for linking related memories (e.g. ['deploy', 'friday', 'staging'])",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 256,
+ "type": "array"
+}Input schema / properties / content / descriptionPrevious value: -"The text to remember (1-10,000 chars). Do not store passwords, API keys, payment data, MFA codes, government IDs, or health records."New value: +"The memory to store as a self-contained statement, e.g. 'User prefers TypeScript strict mode' or 'Decided to deploy the API on Cloudflare Workers (2026-06)'."Input schema / properties / domain / descriptionPrevious value: -"Namespace: 'general', 'user:X', 'project:Z' (default 'general')."New value: +"Namespace to organize memories (e.g. 'engineering', 'user:alice', 'project:acme'). Matched byte-for-byte — a leading space, a different case, or an invisible character opens a SEPARATE, permanent store, so reuse an exact name from memory_stats rather than retyping one. To write into a shared room, pass its address here instead (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms."Output schema / properties / memory_id / anyOfRemoved value: -[
- {
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$",
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / memory_id / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / reason / descriptionPrevious value: -"The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. \"Below importance threshold (0.047 < 0.1)\". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display. Absent when the service sent no explanation."New value: +"The memory service's own explanation of this outcome, quoted as sent — when stored is false this is the ONLY statement of WHY, e.g. \"Below importance threshold (0.047 < 0.1)\". Ordinary text is preserved exactly; only control, bidi, zero-width, and repeated-whitespace characters are normalized before display, and the value is capped at 400 characters. Absent when the service sent no explanation, or when nothing remains after that normalization."vault_list1 field changedInput schema / additionalPropertiesRemoved value: -falsememory_create_roommemory_feedbackmemory_invite_to_roommemory_join_roommemory_list_recentmemory_list_roomsmemory_readmemory_statsmemory_writevault_listHosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Add one secure layer between your agents and this server.
