Mnemoverse Memory

memory_create_room

Create a shared memory room so other people's assistants can read and write context across Claude, ChatGPT, and Cursor for team collaboration.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Room name, unique within your account (e.g. 'launch-team').
`description`	No	Optional description of the room.

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.14.2Oct 1, 2026

changedInput schema / properties / name / description

Previous value: -"Room name, unique within your account (e.g. 'me-and-olya')."New value: +"Room name, unique within your account (e.g. 'launch-team')."

Changed1 schema field changedv0.11.0Sep 23, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "address": {
+      "description": "Domain address (xroom:<id>); pass as `domain` on read/write.",
+      "type": "string"
+    },
+    "name": {
+      "description": "The room name as stored.",
+      "type": "string"
+    },
+    "room_id": {
+      "description": "The room's id (room_...); pass to memory_invite_to_room.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "room_id",
+    "address"
+  ],
+  "type": "object"
+}

Addedv0.5.0Jul 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds the substantive traits: the room is shared/cross-vendor (Claude/ChatGPT/Cursor), the default invite scope is read_write, and it returns an address to be reused as the `domain` argument elsewhere. It does not address name-collision behavior for a non-idempotent create, which leaves one gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the definition of the room before the usage trigger and the follow-on tools. It is a long sentence chain but each clause carries distinct information (scope, cross-platform reach, default invite scope, return value, next steps); minor tightening is possible but nothing is fat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so line-by-line return documentation is unnecessary, yet the description still tells the agent what the address is for. Combined with the invite/read/write follow-on pointers, an agent has enough to create and then use a room; only edge cases (duplicate names, permissions to create) are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 `name` (unique within account) and the optional `description`; the baseline is 3. The description adds no additional meaning about the two parameters themselves (the uniqueness rule it references is already in the schema).

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

Purpose5/5

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

States a specific verb+resource ('Create a SHARED memory room') and immediately distinguishes it from siblings by defining what a room is (a space other people's assistants can read/write). An agent can tell it apart from memory_list_rooms, memory_join_room, and memory_invite_to_room without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger condition and a concrete user-utterance example ('make a room for me and my teammate'), plus points to memory_invite_to_room as the way people join. It stops short of stating when NOT to create a room or how it differs for solo use, so it is clear context rather than full routing guidance.

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

Deploy Server