Privacy Policy
Last updated: June 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.
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.
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).
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), our legal basis for collecting and using personal information depends on the data and the context:
- Consent (e.g. accepting cookies)
- Legitimate interests (e.g. site improvement)
- Legal obligations (e.g. responding to lawful requests)
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
- Withdraw consent at any time
To exercise your rights, contact us at hello@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 is not directed at children under 13, and we do not knowingly collect personal data from them.
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 Memory API exposes six MCP tools. Each one has a single, narrow purpose and a defined effect on the data we store on your behalf:
| Tool | What it does | What we store as a result |
|---|---|---|
memory_read | Search your stored memories by natural-language query; returns a ranked list. | Nothing new. The query text is processed in-memory to compute an embedding and is not persisted as a memory atom. Query embeddings may be retained transiently for cache and abuse-detection purposes (see 11.6). |
memory_stats | Return counts and aggregates over your stored memories (totals, domains, average quality scores). | Nothing new. |
memory_write | Create a new memory atom from the content and optional metadata (concepts, domain) you supply. | The atom: content, concepts, domain, timestamp, and the user/project identifiers that scope it. May be filtered by our importance gate and silently skipped if below threshold; never overwrites or deletes an existing atom. |
memory_feedback | Adjust the quality scores (valence / importance) of one or more existing atoms you previously wrote. | The updated score values on the targeted atoms. |
memory_delete | Permanently delete a single atom by its identifier. | The atom is removed from primary storage. |
memory_delete_domain | Permanently delete all atoms in a given domain. | Every atom in that domain is removed from primary storage. Guarded by an explicit confirm: true flag in the tool input. |
Tool descriptions match what the server actually does. We do not run any hidden "upsert" or "search-then-mutate" tool: the read tools never mutate, and the write/delete tools never silently read additional data.
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 six tools 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 ChatGPT App Directory), 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 (
memory:read,memory:write,memory:admin, andoffline_accessfor long-lived sessions). You can deny any scope you do not want to grant; the connector will then behave according to whatever it was granted. - Your client receives an access token bound to your account and to the Memory API as the audience. The token is stored by the client, not by us — we never see your client's local token store. We do store the server-side record that a token was issued, for audit and revocation.
The OAuth flow is documented for developers at /api/agent-setup. You can revoke a connector at any time from your Mnemoverse console under Settings → Connected apps; revocation invalidates the client's tokens immediately.
11.4 Retention
- Memory atoms are retained until you delete them (via
memory_delete/memory_delete_domain, the console UI, or an account-deletion request — see 11.5). We do not auto-expire atoms based on age. - OAuth tokens follow standard short-lived access + long-lived refresh expiry; configurable per client. Refresh tokens are revoked when you revoke the connector or delete the account.
- Operational logs (request timestamps, tool name, success/failure, byte counts — not the contents of atoms or query text) are retained for up to 90 days for operational and security purposes, then deleted or aggregated to non-identifying metrics.
- Backups of the primary memory store are retained on a rolling basis for up to 35 days. A delete via
memory_delete/memory_delete_domainremoves the atom from primary storage immediately; the corresponding backup tombstone is honoured within the 35-day backup horizon and the atom is unrecoverable thereafter.
11.5 Deletion and your control
You have several ways to remove data, in increasing order of scope:
- Per-atom deletion — call
memory_deletefrom your client, or use the atom-level delete control in your console. Irreversible. - Domain-level deletion — call
memory_delete_domain(with the requiredconfirm: trueflag) or use the domain delete control in your console. Removes every atom tagged with that domain. Irreversible. - Connector revocation — revokes the OAuth tokens for one client without touching your atoms. From console.mnemoverse.com → Settings → Connected apps.
- Account deletion — email support@mnemoverse.com from the address on the account. We delete the account record, all atoms, all OAuth state, and all stored embeddings within 30 days; backups age out within the 35-day window 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.
11.6 Sub-processors
We use a small set of sub-processors to operate the Memory API. We review each for security and data-protection posture before adding them and re-review at least annually.
| Sub-processor | Purpose | Data exposed |
|---|---|---|
| Cloud hosting provider (Hetzner / AWS region as configured per environment) | Compute, network, and primary database hosting for the Memory API and the authorization server. | Memory atoms (encrypted at rest), OAuth state, operational logs. |
| Embedding model provider (Voyage AI / OpenAI, depending on the active configuration) | Generating semantic embeddings of memory content and search queries. | Memory atom content, query text. Sent at call-time, not retained by us beyond the operation. We send the minimum text necessary; we do not send user identifiers. |
| Anthropic | The Mnemoverse Memory connector in Claude (when authorised) sends tool calls and tool results between your Claude client and our Memory API. Anthropic processes those payloads under its own policy. | Tool call arguments, tool results. Only when you have authorised the connector and are actively using it. |
| OpenAI | The Mnemoverse Memory connector in ChatGPT (when authorised) sends tool calls and tool results between your ChatGPT client and our Memory API. OpenAI processes those payloads under its own policy. | Tool call arguments, tool results. Only when you have authorised the connector and are actively using it. |
| Transactional email provider | Account, security, and support email. | Email address, message content. |
| Error and performance monitoring | Capturing errors and request-level performance metrics from the Memory API and the authorization server. | Error stack traces, request metadata (path, status, latency); not the contents of memory atoms or query text. |
The Anthropic and OpenAI rows describe the connector path you opt into by authorising the connector in those clients; they are not data-sharing arrangements we initiated independently. If you do not connect, no data flows through that path.
11.7 Security
The Memory API enforces multi-tenant isolation through database-level row-level security: every read and write is scoped to the authenticated user and (where applicable) project, and a query that attempts to read another tenant's data is rejected by the database engine itself, not by application logic alone. Memory atoms are encrypted at rest by the underlying storage layer; OAuth tokens are stored hashed at the authorization server. Access tokens have a short lifetime and use audience-binding so a token issued to one resource cannot be replayed against another.
11.8 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.