Privacy Policy
Last updated: October 2026
This Privacy Policy explains how Mnemoverse ("we", "us", or "our") collects, uses, and protects information when you use our website at https://mnemoverse.com, our Memory API at https://core.mnemoverse.com, and any MCP connector (Claude, ChatGPT, Cursor, VS Code, or other MCP-compatible client) that connects to that API. Section 11 below covers the connector- and API-specific data flow in detail; sections 1–10 cover the website.
Mnemoverse is operated by UINSIDE Inc., a Delaware corporation with its principal address at 3418 NE 210th Ln, Miami, FL 33180, USA. UINSIDE Inc. is the data controller for the account, billing, and operational data described in this policy — the data we decide to collect to run the service. For the memory content you choose to store through the API, you (or the organisation on whose behalf you act) decide what is stored and for what purpose, and UINSIDE Inc. stores and processes that content on your behalf, on your instructions, as a data processor. Business customers who require a data-processing agreement (DPA) can request one at support@mnemoverse.com.
1. Information We Collect
We may collect the following types of data:
- Personal Information you voluntarily provide, such as your email address when you contact us.
- Usage Data, including IP address, browser type, pages visited, and time spent on our site, collected via analytics tools and cookies.
- Signup Attribution Data: when you create an account, we record how you found us — the referring page (scheme, host, and path only; no query strings or fragments), any campaign tags (UTM parameters) on the link you followed, the page you first landed on, and the time — linked to your account. We process this under our legitimate interests to understand which channels and content bring users to Mnemoverse; it is never sold or shared, and it is deleted together with your account.
2. How We Use Your Information
We use the collected data to:
- Respond to inquiries or requests.
- Improve our website and user experience.
- Analyze traffic and usage patterns (via anonymized data, and — for signup attribution only — the account-linked data described in Section 1).
We do not sell or rent your personal data to third parties.
3. Legal Basis for Processing (GDPR)
If you are in the European Economic Area (EEA), we rely on a legal basis for each processing purpose rather than treating one basis as covering everything:
- Performance of a contract or steps you request before entering one — creating and operating your account; providing the Memory API, MCP connectors, Shared Rooms, support, and billing; and processing the content and instructions you submit so those services work.
- Legitimate interests — securing the service, preventing abuse, diagnosing failures, and improving reliability, where those interests are not overridden by your rights and reasonable expectations.
- Consent — optional cookies or similar processing where consent is required. You may withdraw consent without affecting processing that was lawful before withdrawal.
- Legal obligations — records or disclosures we must retain or make under applicable law.
Accepting a room invitation is a product action that requests access to a shared service. It is not presented as consent to unrelated processing or marketing. Where content a member stores into a room includes another person's personal data, we process it to provide the requested shared service (a legitimate interest, balanced against that person's rights); the member is responsible for having a lawful basis to share it.
4. Data Storage and Security
We take appropriate technical and organizational measures to protect your personal data against loss, misuse, and unauthorized access.
5. Your Rights
Depending on your location, you may have the following rights:
- Access the data we hold about you
- Request correction or deletion
- Object to or restrict data processing
- Receive data you provided in a portable format where the right to portability applies
- Withdraw consent at any time
- Lodge a complaint with the data-protection authority responsible for your place of residence, work, or the alleged infringement
To exercise your rights, contact us at support@mnemoverse.com.
6. Third-Party Services
We may use third-party services (e.g., analytics tools) that process data on our behalf. These services are carefully selected and comply with data protection laws.
7. Data Retention
We retain personal data only for as long as necessary to fulfill the purposes for which it was collected, unless a longer retention is required by law.
8. Children’s Privacy
Our website and the Memory API service are not directed at children. We do not knowingly collect personal data from children below the age of digital consent that applies to them (13 in the United States; in the EEA, 16 — or the lower age, down to 13, that a member state has set). If you believe a child has provided us personal data, contact us at support@mnemoverse.com and we will delete it.
9. Changes to This Policy
We may update this Privacy Policy from time to time. Any changes will be posted on this page with an updated revision date.
10. Contact Us
If you have any questions, contact us at support@mnemoverse.com.
11. Memory API & MCP Connectors
This section governs data processed by the Mnemoverse Memory API and by any MCP (Model Context Protocol) connector you authorise to use it — including the Mnemoverse connectors in Claude, ChatGPT, Cursor, VS Code, and any other MCP-compatible client. If you only browse our website, sections 1–10 apply and section 11 does not.
11.1 What the Memory API stores and retrieves
The MCP surface covered here includes six core memory tools, four Shared Rooms tools, and one Vault tool. A particular connector may expose only a subset. Each operation has a defined effect on the data we store on your behalf:
| Tool | What it does | What we store as a result |
|---|---|---|
memory_read | Search the memory bucket addressed by the request and return a ranked list (items). Each result carries its memory_id (the identifier used to rate or manage that memory), content, domain, created_at (when it was created, where known) and, where recorded, author (the identity of the agent that wrote it, never the human account holder). | The query is not persisted as a memory atom. The service keeps usage statistics for the memories a search considers, which it uses to improve ranking. Query embeddings may be retained transiently for caching (see 11.6). |
memory_list_recent | List the newest memories first, no search query; optionally filtered by domain and a since/until time window, paged with a cursor. Each entry (items) carries the same fields as a memory_read result, and next_cursor is the cursor for the next (older) page. | Nothing new. A read-only listing query — unlike memory_read, it does not update usage statistics. |
memory_stats | Return counts and aggregates over your stored memories: memory_count (the number of saved memories), domains (your memory domains), episodes (the number of individual memories), prototypes (the number of summary memories), hebbian_edges (the number of concept-to-concept associations), avg_valence (the average valence of stored memories, from -1 to 1) and avg_importance (their average importance, from 0 to 1). | Nothing new. |
memory_graph | Return the associations the memory has formed around the concepts you name. Each concept in the result (nodes) carries its name (concept) and degree (the number of returned associations that touch it); each association (edges) carries the two concepts it links (source, target), its weight (its strength), valence (its outcome polarity, from -1 to 1), count (a co-activation count) and updated_at (when the association was last updated). truncated says whether a server cap or limit cut the result short, and min_weight_applied gives the weight floor actually used. | Nothing new. A read-only query. |
memory_write | Create a new memory atom from the content and optional metadata (concepts, domain) you supply. Returns stored (whether the memory was stored), memory_id (the stored memory's identifier, or null when it was not stored) and, where the service sends them, importance (an approximate novelty score for the write, from 0 to 1) and reason (the service's own explanation of the outcome, such as why a memory was not stored). | The atom: content, concepts, domain, timestamp, and the user/project identifiers that scope it. Every write also records authorship provenance: which account, and which agent or environment, created the atom. In a room, other members can see and filter on it. May be filtered by our importance gate and reported back as not stored (stored: false) if below threshold, rather than silently dropped; never overwrites or deletes an existing atom. |
memory_feedback | Record whether one or more existing atoms you can access were helpful — your own atoms, or atoms in a room where you hold read-write membership. Returns updated_count (the number of memories the service reports the rating applied to), avg_valence (the average valence of the rated memories after the update) and coactivation_edges (the number of concept associations the rating changed); when the service processes a rating later, these values are its acknowledgement, not the final result. | The updated rating (valence) of the targeted atoms and a count of ratings received, and the ranking data those ratings feed. |
memory_create_room | Create an empty shared-memory room. Returns its room_id, its address (xroom:<id>, used as domain on other calls) and its name. | A room record and the creator's owner membership. |
memory_invite_to_room | Create a room share code with a scope, expiry, and use limit. Returns the code, its scope and expires_at, the room's room_address, and join_url and share_message — an invite link and a ready-to-send message, both carrying the invite code; the message also names the room. | A hashed invite record, its scope, expiry, use limit, and redemption count. The plaintext code is returned when created and is not stored in plaintext. |
memory_join_room | Redeem a valid room share code for the signed-in account. Returns the room's room_id, address and name, your scope in it, already_member (true if you were already a member) and next_steps (how to use the room now). | A room-membership record, updated invite redemption state, and a short notice in the room, visible to its members, that a new participant joined. |
memory_list_rooms | List the rooms you own or have joined. Each entry (rooms) carries the room's room_id, name and address (for use as domain on other calls), your role (owner or member) and scope (read or read-write), and whether it is archived. | Nothing new. A read-only listing query. |
vault_list | List the secrets in your Mnemoverse Vault. Each entry (secrets) carries the secret's alias, its context (its purpose) and its concepts (concept tags). | Nothing new. A read-only listing query; the secret's stored value is never returned by this tool or any other on this server. |
Where the table names a field a tool returns, it uses the name that field has in the tool's structured result.
Tool descriptions match the intended server effects. A read does not create, overwrite, or delete memory content; it updates the usage statistics disclosed above.
11.2 What we do NOT collect through the Memory API
- We do not read the contents of conversations in your MCP client (e.g. your Claude or ChatGPT chats). The client decides what to send us via the operations above; everything outside those calls stays in the client.
- We do not infer or attach additional identifiers (such as device fingerprints) to the atoms you write.
- We do not sell, rent, or otherwise transfer your memory atoms to third parties for marketing or advertising purposes.
11.3 The OAuth connect flow
When you connect a Mnemoverse MCP connector to a client (e.g. Claude "Add connector" or a developer-mode app in ChatGPT), your client takes you through an OAuth 2.1 authorization-code flow with PKCE on our authorization server at https://auth.mnemoverse.com. During that flow:
- You log in (or sign up) with the credentials your Mnemoverse account uses (email + password, or an OIDC identity provider if one is enabled on your account).
- You see a consent screen listing the scopes the client is requesting (
openid,profile,email,memory:read,memory:write, andoffline_accessfor long-lived sessions). You can approve the listed scope set or deny the authorization request. An approved token is limited to the scopes shown on that screen. - Your client receives an access token bound to your account and to the Memory API as the audience. The client stores its copy; we do not access the client's local token store. Our authorization server also stores the token and grant records required by the current OAuth implementation for validation, expiry, audit, and revocation.
The OAuth flow is documented for developers at /api/agent-setup. Tokens issued to a connector expire on our side at a fixed time: an access token one hour after it is issued, and a refresh token 30 days after it is issued (each refresh issues a new one, so the 30 days count from the client's last refresh).
To disconnect one connector, remove it in the client's connector settings; the tokens already issued to it then expire as described above. The Mnemoverse console has no control that revokes a single connector today.
To disconnect every connected app at once, reset your password through the console and tick Also disconnect all connected apps on the reset page. The refresh tokens issued to your connected apps are then deleted, so no app can obtain a new access token, and each app loses access when its current access token expires, within an hour. The page tells you whether the disconnect succeeded. You reconnect the apps you still use from their own settings. A password reset without that choice does not disconnect connected apps. Neither choice revokes API keys, including the key an editor extension receives when you connect it through the console; revoke those on the console's API Keys page.
11.4 Retention
- Private memory atoms are retained until you delete them (via the REST API delete endpoints or an account-deletion request — see 11.5). We do not auto-expire private atoms based on age.
- Shared-room content is retained until the room bucket or the relevant content is deleted through an available control or a verified support process. Archiving a room disables ordinary access but does not erase its memory bucket, and archived room content does not currently auto-expire merely because it was archived. See 11.8 for shared-content requests and the effect of membership revocation.
- OAuth tokens use shorter-lived access tokens and longer-lived refresh tokens, with the lifetimes given in 11.3. After you disconnect a connector in the client, the tokens issued to it expire as described there. Refresh tokens are deleted before they expire when you reset your password and choose to disconnect connected apps (11.3), and your OAuth state is deleted as part of an account-deletion request (11.5).
- Operational logs (request timestamps, tool name, success/failure, byte counts — not the contents of atoms or query text) are held by our monitoring and log providers under their retention settings, and are used only for operations and security.
- Backups of the primary memory store are kept on the rolling schedule of our database provider. A delete via the REST API removes the atom from primary storage immediately; until the backup window rolls past it, a copy may still exist in a backup we cannot selectively edit.
What we do not yet automate, stated plainly. We do not currently run our own scheduled job that expires logs or backups on a fixed clock, and account deletion is carried out by our team on a verified request rather than by a self-service button. We are building both:
| Commitment | Target |
|---|---|
| Scheduled retention enforcement — logs and backups expired automatically on a stated clock, and the clock published here | 31 December 2026 |
| Self-service account deletion from the console, without contacting support | 31 December 2026 |
Until those ship, deletion happens the way section 11.5 describes: you delete atoms and domains yourself through the REST API, with immediate effect, and account-level erasure is handled by our team on request. We would rather publish this gap than publish a retention clock we cannot yet enforce.
11.5 Deletion and your control
You have several ways to remove data, in increasing order of scope. There is no delete control in the console today: memories and domains are deleted through the REST API, and the whole account by a request to support.
- Per-atom deletion — available via the REST API (
DELETE /memory/atoms/{id}) as an administrative operation. It is not exposed as an MCP tool call from your client. If a stored fact is simply wrong rather than something you want forgotten outright, writing a corrected memory is the better fix — see the API reference for the delete endpoint's exact behavior. Deletion itself is irreversible. - Domain-level deletion — available via the REST API (
DELETE /memory/domain/{domain}) as an administrative operation. It is not exposed as an MCP tool call from your client. Removes every atom tagged with that private domain. It does not act on shared room (xroom:) domains — room-content deletion is support-assisted (see 11.8). Irreversible. - Disconnecting a connector — affects client access and leaves your atoms untouched. To disconnect one client, remove the connector in the client's connector settings; the tokens already issued to it expire on our side as described in 11.3. To disconnect every connected app at once, choose that option when you reset your password through the console (11.3).
- Account deletion — email support@mnemoverse.com from the address on the account. We delete the account record, your private account-owned atoms, OAuth state, and corresponding stored embeddings within 30 days of verifying the request. Copies inside backups disappear as the provider's backup window rolls past them, as described in 11.4.
Subject-access requests (your right to a copy of the data we hold, or to restriction/objection under GDPR) follow the same channel.
Account deletion does not automatically erase content previously shared into a room, because that content is stored in a shared bucket and may form part of other members' records. You may include room content in an access, correction, restriction, or erasure request. We will verify the request, assess the affected content and the rights of other people, and delete, de-identify, or restrict it where required. Where applicable, we also notify recipients to whom the personal data was disclosed.
11.6 Sub-processors
We use a small set of sub-processors to operate the Memory API. We assess their security and data-protection posture before use and when material processing changes.
| Provider category | Purpose | Data exposed |
|---|---|---|
| Railway — infrastructure and database hosting for the memory engine | Compute, network, and managed PostgreSQL (with pgvector) for the Memory API's memory store. | Memory atoms, shared-room buckets, and operational logs. |
| Neon — managed PostgreSQL for accounts and authorization | Stores your account and identity records, sessions, and the OAuth token and grant records issued by the authorization server. | Email address, account identifiers, session records, and OAuth token/grant records. |
| Prisma Data Platform (Accelerate) — database connection proxy | Edge connection pooling and query routing in front of the accounts database. | The account and authorization data above, in transit to Neon. |
| Cloudflare — edge runtime and network | Runs the authorization server at auth.mnemoverse.com and provides edge routing and CDN for our sites and APIs. | Request metadata and IP address. |
| NVIDIA — hosted embedding API (when configured) | Generating semantic embeddings of memory content and search-query text (model nv-embedqa-e5-v5). Depending on configuration, embeddings run on either a local model or this hosted API; where the hosted API is used, that content is sent to NVIDIA. | Memory atom content and search-query text (sent as the embedding input). We do not include account identifiers in the embedding request. |
| Resend — transactional email | Account and subscription-lifecycle notifications (e.g. suspension and usage-limit notices). | Account/billing contact email address, message content. |
| Sentry / Axiom — error monitoring and log aggregation | Capturing errors, request-level performance metrics, and operational logs from the Memory API and the authorization server. | Error stack traces and request metadata (path, status, latency). Memory-atom and query content is not intentionally included. |
The MCP client provider you choose is also a recipient of the tool calls and results handled in that client. For example, when you authorise the Claude or ChatGPT connector, Anthropic or OpenAI respectively processes those payloads under its own terms and privacy policy. These client-side paths are not sub-processors we appoint to operate the Memory API. If you do not connect through such a client, no data flows through that path.
A current list of the sub-processors we use is available on request at support@mnemoverse.com.
International transfers. Some of the sub-processors above may process personal data outside your country, including outside the European Economic Area (EEA) and the United Kingdom. Where we transfer personal data out of the EEA or UK, we rely on an appropriate safeguard — an adequacy decision where one applies, the European Commission's Standard Contractual Clauses (with the UK Addendum where applicable), or, where a provider is certified, the EU–US Data Privacy Framework. Our sub-processors are established primarily in the United States and the European Union; the current list, with each provider's location and transfer safeguard, is available on request at support@mnemoverse.com.
11.7 Security
The Memory API enforces multi-tenant isolation through database-level row-level security for your private memory: every read and write against your own account is scoped to the authenticated user and (where applicable) project, and a query that attempts to read another tenant's private data is rejected by the database engine itself, not by application logic alone. Access tokens have a short lifetime and use audience-binding so a token issued to one resource cannot be replayed against another.
The one deliberate exception to tenant isolation is Shared Rooms (Beta) — see 11.8. A room is an opt-in, membership-checked shared memory space that more than one account can use by design. Access to room data is authorized by an active room membership and its scope, which the API checks on every request and which a database row-level- security policy also enforces — a different boundary from the private-account isolation that scopes your own memory. Rooms do not weaken isolation of your private memory: content stays in the room bucket it was written to, and joining a room does not expose anything from your private account to other members.
Breach notification. If a personal-data breach affecting your information occurs, we assess it promptly and, where the law requires, notify the competent supervisory authority (in the EEA, within 72 hours of becoming aware) and inform affected users without undue delay where the breach is likely to result in a high risk to their rights and freedoms. Because a Shared Room's storage is used by more than one account, a breach affecting a room may affect several members at once, and we notify each affected member on that basis.
11.8 Shared Rooms (Beta)
Beyond your private memory, the Memory API supports an opt-in shared memory space called a room (/api/rooms). Providing and securing the room requested by its members is part of the service described in section 3. A room is its own memory bucket, separate from any member's private account. Private content is not moved into a room automatically: room sharing occurs when a request authenticated to a member's account targets the room address (domain: "xroom:<room_id>").
- Membership is required and checked on every call. You must be an active member of a room — added by the room's owner through a share code (single-use by default, with a configurable use limit) or the console — before access succeeds. The invite link (
join_url) and ready-to-send message (share_message) returned with a share code both carry that code, and the message also names the room, so anyone who receives either can use the code to join, with the scope it grants, until it expires or reaches its use limit. Membership is either read-only or read-write, may expire, and may be revoked by the room owner. Support may also act on a verified legal or account-security request. - Current and future active members are recipients of room content. Content that is successfully stored in a room can be retrieved by active members whose scope permits the operation. Someone invited later may therefore receive content stored before they joined. Read-only members cannot write, give feedback, or run other write-scoped operations. Room content is not made available through the room interface to people without active membership.
- Room usage is attributed and billed to the member who makes the call, not to the room's owner — a write or read against a room consumes the calling member's own account and quota, the same as a private-memory call.
- What you put into a room, you cannot take back yourself. A room is shared by design, so contributing to one is closer to saying something in front of others than to filing it in your own drawer. There is no control that lets a member retract their own past contributions from a room, and leaving or being removed does not withdraw them.
- Membership revocation is access control, not erasure. Removing a member stops future access immediately but cannot make them forget information they already received, and does not delete content they previously contributed. Re-inviting a removed member restores access under the new active scope.
- Shared-content rights remain available. Revocation does not limit anyone's applicable rights of access, correction, restriction, objection, portability, or erasure. A member, former member, room owner, or other data subject may send a verified request concerning personal data in room content to support@mnemoverse.com. We assess the request against the requester's identity, authorship or data- subject relationship, the room's shared context, and other members' rights.
- Room deletion is currently support-assisted. The console's archive action disables ordinary room access but does not erase the storage bucket. Deletion of a room bucket happens on a verified request, which we assess case by case — a room owner may ask, and so may anyone exercising a data-protection right over personal data the room holds. Archived content remains in primary storage until that process completes; archiving alone does not start an automatic expiry period. Deleted primary data then disappears from backups as the provider's window rolls past it (11.4), except where a legal obligation requires longer retention.
If you invite someone into a room, or accept an invitation to join one, content successfully stored there may be disclosed to the room's current and future active members under the scope and retention rules above. The join screen should be read together with this section before you accept.
11.9 Aggregate structural analytics
To operate, secure, and improve the service, we compute aggregate, content-free structural statistics over the data the Memory API stores on your behalf — for example, counts of memory atoms and concept-graph edges, degree and edge-weight distributions, and usage aggregates by tenant class. These analyses read structure, never content: they never read or quote the text of your memories.
We may publish such statistics in technical reports or research publications. Anything published is limited to class-level aggregates or structure-only statistics under pseudonymous tenant identifiers — never memory content, never plaintext account identifiers, and never calendar dates of an individual tenant's activity.
11.10 Changes to this section
We will keep section 11 in step with the actual behaviour of the Memory API. If we add a tool, add a sub-processor, change retention, or change the OAuth scopes, we update this section and bump the "Last updated" date at the top of the page. We do not silently expand the scope of what the API does without a documentation change.