Hosted agent memory that learns from outcomes, with shared rooms. No key: mcp.mnemoverse.com/mcp
Scored across 11 tools
Each tool occupies a distinct slot: write vs read vs list_recent vs list_rooms vs list_recent-vs-read distinction is spelled out explicitly ('semantic search answers what do I know about X; this answers what happened lately'). Room lifecycle tools (create/join/invite) are cleanly separated by role, and memory_graph vs memory_stats vs memory_feedback have clearly different outputs. The only mild adjacency is stats vs graph as 'overview' tools, but the descriptions resolve it.
Ten of eleven tools follow a strict memory_<verb>_<noun> snake_case pattern with consistent verb placement. vault_list breaks the namespace prefix and sits in a different resource family, which is a deliberate but visible deviation. Otherwise highly predictable.
Eleven tools is well within the sweet spot, and every one earns its place: read/write core, recent listing, feedback signal, graph introspection, stats, and three room operations. Nothing feels padded or missing at the count level.
The memory lifecycle is strong (write, read, list, feedback, stats, graph, shared rooms), but there is no delete/forget or update path at all — the description explicitly says deletion is REST-API-only, leaving agents unable to correct or remove a bad memory. vault_list is also a dead end: it lists aliases but no tool retrieves or uses a secret, and room management lacks leave/revoke/member operations.
Create a SHARED memory room — a space OTHER people's assistants can read, and write too when their membership scope is read_write, across the AI tools members connect to Mnemoverse. Members can access the room's existing history, including memories saved before they joined; joining does not expose their private account memory. 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 only say it is a non-destructive, non-readonly create; the description adds substantive behavior an agent could not infer: write access depends on membership scope (read_write), members see history saved before they joined, and joining does not leak private account memory. It also discloses that the result is a room address used as a `domain` handle elsewhere.
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 sharing/permission model is front-loaded and the operational follow-through (invite, domain, list) comes after. It is slightly dense and has one overlapping clause ("across the AI tools members connect to Mnemoverse") that could be trimmed without loss.
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?
Only two simple parameters, full schema coverage, an output schema that covers return values, and annotations covering the safety profile. The description still adds the sharing model, membership scope, privacy boundary, and downstream handle usage — the decision-relevant context is complete.
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 both parameters are documented in-schema, so the baseline is 3. The description goes beyond that by explaining the semantic role of the returned address (`domain` on memory_write/memory_read), which is the non-obvious part of using this tool's output as input elsewhere; it adds nothing about the optional `description` parameter.
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?
The description opens with a specific verb+resource ("Create a SHARED memory room") and immediately contrasts it with private memory ("OTHER people's assistants can read", "joining does not expose their private account memory"). This makes it distinguishable from siblings like memory_join_room and memory_list_rooms without opening their schemas.
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?
It states the triggering condition explicitly ("Use when the user wants to share context or collaborate with someone else") with a concrete example utterance. It also points to the follow-on tools: memory_invite_to_room for membership and memory_write/memory_read/memory_list_recent for using the returned address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate memories returned by memory_read to help improve future retrieval ranking. Pass their IDs as memory_ids and an outcome from -1 (unhelpful) to 1 (helpful). Records feedback and updates ranking signals: positive feedback raises a memory's ranking; negative feedback lowers it so other memories out-rank it — nothing is erased. Saved text is not changed or deleted. For memories read from a shared room, 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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the actual effect: positive feedback raises ranking, negative lowers it so others out-rank it, and nothing is erased or edited. It also surfaces a permission constraint (read-only room members cannot rate) that the annotations do not express.
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 action and its purpose, then progressively narrower details (outcome scale, ranking effect, domain rule, permission caveat). Dense but slightly redundant: 'nothing is erased' and 'Saved text is not changed or deleted' say nearly the same thing.
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?
The tool has an output schema, so return values need not be described. For a 3-parameter mutation with annotations covering the safety profile, the description supplies everything an agent needs: the source of IDs, the scale, the shared-room rule, and the ranking consequence.
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 schema already documents all three parameters and the -1..1 range. The description still adds cross-tool meaning by identifying memory_ids as the `id:` line of a memory_read result and by explaining the conditional domain requirement for shared rooms.
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 ('Rate memories returned by memory_read') and immediately names the effect on retrieval ranking. It is clearly distinguishable from siblings like memory_read (which returns memories) and memory_write (which creates text), because rating is an explicit separate action.
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 ties usage to memories obtained from memory_read, states how to pass IDs and outcome, tells the agent to include the room address only for shared-room memories, and names an exclusion (read-only room members cannot rate). When-to-use, when-not-to-use, and the alternative path are all covered.
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, though it names the ones you have (rooms_not_searched).
| 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. |
| rooms_not_searched | No | Present only on a call WITHOUT `domain`, when you have shared rooms or they could not be checked: rooms are separate stores that call did not search. |
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 real behavioral context beyond them: completeness-within-a-scope, the size budget that can truncate a page below `limit`, the guarantee of no skips/duplicates across pages, and the `rooms_not_searched` signal on unscoped calls. It also discloses a limitation not visible elsewhere ('nothing is skipped there, unlike a semantic search').
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 opening sentence is well front-loaded and the paragraph advances from purpose to paging to scope. However, the size-budget/cursor mechanic is explained twice (once in prose, again in the `limit` description) and the paragraph is dense enough to be mildly repetitive.
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 6 optional parameters and an output schema present, the description supplies exactly what the schema cannot: which scope the call covers, why a page may be short, how to continue, and where the room-address list comes from. An agent has everything needed to call it correctly on the first try.
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, but the description adds synthesis the schema cannot: `since` as a novelty watermark, `domain` as mandatory for room access, and the interaction between `limit` and the size budget that makes large limits wasteful in rooms. It largely restates the schema's per-parameter caveats rather than adding new semantics, which keeps it below a 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?
The description leads with a specific verb and ordering ('List the NEWEST memories first') and immediately contrasts itself with the sibling capability of semantic search ('what happened lately' vs 'what do I know about X'). An agent can pick between this and memory_read without opening either 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?
It names concrete use cases (resuming after a break, catching up on a room, reviewing recent saves), states when to pass `since` versus paging with the cursor, and gives an explicit MUST for the alternative store ('to catch up on a shared room you MUST pass its address as `domain`'). When-not guidance is present: unscoped calls never cover rooms.
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. 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 correction is a fresh memory_write: it is stored alongside the earlier memory, which is not deleted or hidden, unless it is too close to an existing memory, in which case the write is refused. No MCP deletion tool is exposed; a user can permanently delete an individual personal memory through the REST API or with help from support.
| 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, or in `rooms_not_searched`, which an answer without `domain` carries when you have 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. |
| rooms_not_searched | No | Present only on a call WITHOUT `domain`, when you have shared rooms or they could not be checked: rooms are separate stores that call did not search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, but the description adds valuable context annotations cannot: cross-session/cross-tool persistence scope, relevance ranking with newest-first fallback, the id handoff to memory_feedback, and the surprising fact that a near-duplicate write is refused rather than overwriting. The deletion-policy sentences lean toward memory_write's concerns, which keeps this just below a 5.
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 purpose and applicability before any mechanics, and each sentence handles a distinct concern. It runs long, however, and the correction/deletion paragraph is only loosely tied to a read tool, arguably belonging to memory_write.
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, the description need not explain return shapes, and it still covers persistence scope, ranking behavior, id usage, and the fact that no MCP delete path exists. Nothing essential to calling 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%, so the schema already carries parameter meaning; the description only echoes order_by: 'recency' and notes that results carry ids for memory_feedback. That id/feedback loop is a genuine addition, but query, since, until, domain, top_k, diversity, and exclude_author are left entirely to the schema.
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?
Opens with a specific verb+resource ('Search long-term memory') and enumerates the content classes it targets (preferences, decisions, project setup, people, earlier context). It also draws explicit boundaries against memory_feedback (post-answer feedback) and memory_write (corrections), so an agent can place it among the siblings without opening schemas.
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 a positive trigger ('applies when an answer may depend on something from an earlier session or another tool') and an explicit exclusion ('not needed for general world knowledge'). It also states the follow-up step with memory_feedback, so the when-and-what-next is fully specified.
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. 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?
Annotations already declare this is a mutating, non-idempotent, non-destructive write. The description adds substantial behavioral context beyond that: the novelty gate outside shared rooms, the possibility of refusal, and the fact that the result reports whether the memory was stored or refused. This is exactly the kind of condition an agent could not infer from 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?
The description is front-loaded with the core purpose and then layers in usage, safety exclusions, and novelty-gate behavior in a logical order. It is somewhat dense, but every sentence carries real information and none is 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?
Given that an output schema exists and annotations cover the safety profile, the description supplies what structured fields cannot: persistence semantics, acceptable content categories, prohibited data, and the novelty-gate refusal behavior. An agent has enough to decide whether and how 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 schema already documents `domain`, `content`, and `concepts` thoroughly, including byte-for-byte domain matching and room addresses. The description reinforces the self-contained-content requirement but largely restates what the schema already says, so it sits at the baseline.
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?
The description states a specific verb and resource ('Store a long-term memory') and scopes it precisely: persistence across sessions and across every connected AI tool. It is clearly distinguishable from sibling tools like memory_read or memory_list_recent, which retrieve rather than store.
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?
It explicitly names when to use the tool ('durable information: a stated preference, a decision, a fact about people, roles or project setup, a lesson learned') and when not to ('transient chatter that only matters this turn does not belong here'). The prohibition list for sensitive data adds a hard exclusion boundary that leaves little room for misuse.
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_list_recent1 field changedOutput schema / properties / rooms_not_searchedAdded value: +{
+ "additionalProperties": false,
+ "description": "Present only on a call WITHOUT `domain`, when you have shared rooms or they could not be checked: rooms are separate stores that call did not search.",
+ "properties": {
+ "note": {
+ "description": "The same disclosure the text ends with.",
+ "type": "string"
+ },
+ "rooms": {
+ "description": "The live rooms this call did not search; present only when state is 'live'. A row missing room_id, address or role is omitted here and still named in `note`.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "description": "Domain address (xroom:<id>); pass as `domain` on read/write.",
+ "type": "string"
+ },
+ "archived": {
+ "description": "True if archived (owned rooms only).",
+ "type": "boolean"
+ },
+ "name": {
+ "description": "The room name.",
+ "type": "string"
+ },
+ "role": {
+ "description": "'owner' or 'member'.",
+ "type": "string"
+ },
+ "room_id": {
+ "description": "The room's id (room_...).",
+ "type": "string"
+ },
+ "scope": {
+ "description": "'read' or 'read_write'.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "room_id",
+ "address",
+ "role",
+ "archived"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "description": "'live': the rooms listed can be read by passing an address as `domain`. 'archived-only': every room you have is archived and refuses reads. 'unknown': the room list could not be checked, so whether any room went unsearched is not known.",
+ "enum": [
+ "live",
+ "archived-only",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "note"
+ ],
+ "type": "object"
+}memory_read2 fields changedInput schema / properties / domain / descriptionPrevious 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."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, or in `rooms_not_searched`, which an answer without `domain` carries when you have rooms."Output schema / properties / rooms_not_searchedAdded value: +{
+ "additionalProperties": false,
+ "description": "Present only on a call WITHOUT `domain`, when you have shared rooms or they could not be checked: rooms are separate stores that call did not search.",
+ "properties": {
+ "note": {
+ "description": "The same disclosure the text ends with.",
+ "type": "string"
+ },
+ "rooms": {
+ "description": "The live rooms this call did not search; present only when state is 'live'. A row missing room_id, address or role is omitted here and still named in `note`.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "description": "Domain address (xroom:<id>); pass as `domain` on read/write.",
+ "type": "string"
+ },
+ "archived": {
+ "description": "True if archived (owned rooms only).",
+ "type": "boolean"
+ },
+ "name": {
+ "description": "The room name.",
+ "type": "string"
+ },
+ "role": {
+ "description": "'owner' or 'member'.",
+ "type": "string"
+ },
+ "room_id": {
+ "description": "The room's id (room_...).",
+ "type": "string"
+ },
+ "scope": {
+ "description": "'read' or 'read_write'.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "room_id",
+ "address",
+ "role",
+ "archived"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "description": "'live': the rooms listed can be read by passing an address as `domain`. 'archived-only': every room you have is archived and refuses reads. 'unknown': the room list could not be checked, so whether any room went unsearched is not known.",
+ "enum": [
+ "live",
+ "archived-only",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "state",
+ "note"
+ ],
+ "type": "object"
+}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 memory for AI agents over MCP. One memory shared by all your agents.
Public chat and shared memory for AI agents. Open reads, free write keys. MCP + A2A + WebSocket.
Shared memory for AI agents, with a receipt for every write. Hosted MCP at agentics.you/mcp.
Hosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.
Add one secure layer between your agents and this server.