otherapi_key

Mem0

Mem0 is an universal, self-improving memory layer for LLM applications.

Verdict

Mem0 gives your team persistent memory across AI conversations. When you @mention it in a Space, the AI can store context about projects, users, or past decisions, then recall that information in future chats. This matters when your team runs recurring workflows — sprint planning, customer support, onboarding — where the AI needs to remember preferences, history, or open threads. Mem0 organizes memory by agent, user, app, or run, so different contexts stay separate. Setup requires an API key and understanding which memory scope fits your workflow. The 43 tools cover creating agents, storing memories, managing organizations, and retrieving context, but you'll need to design your memory structure upfront.

Common use cases

  • Remember customer preferences across support threads
  • Track project decisions during sprint planning
  • Store onboarding notes for new hires
  • Recall past meeting action items
  • Maintain context for recurring standup summaries

Integration

Vendor
Mem0
Category
other
Auth
API_KEY
Tools
43
Composio slug
mem0

Tools

  • Add member to project

    Adds an existing user to a project (identified by `project id` within organization `org id`), assigning a valid system role.

  • Add new memory records

    Stores new memory records from a list of messages, optionally inferring structured content; requires association via `agent id`, `user id`, `app id`, or `run id`.

  • Add organization member

    Adds a new member, who must be a registered user, to an organization, assigning them a specific role.

  • Create a new agent

    Creates a new agent with a unique `agent id` and an optional `name`; additional metadata may be assigned by the system.

  • Create a new agent run

    Creates a new agent run in the mem0.ai system.

  • Create a new application

    Creates a new application, allowing metadata to be passed in the request body (not an explicit field in this action's request model); ensure `app id` is unique to avoid potential errors or unintended updates.

  • Create a new organization entry

    Creates a new organization entry using the provided name and returns its details.

  • Create a new user

    Creates a new user with the specified unique `user id` and supports associating `metadata` (not part of the request schema fields).

  • Create an export job with schema

    Initiates an asynchronous job to export memories, structured by a schema provided in the request body and allowing optional filters.

  • Create memory entry

    Lists/searches existing memory entries with filtering and pagination; critically, this action retrieves memories and does *not* create new ones, despite its name.

  • Create project

    Creates a new project with a given name within an organization that must already exist.

  • Delete an organization
    destructive

    Permanently deletes an existing organization identified by its unique id.

  • Delete entity by type and id
    destructive

    Call to permanently and irreversibly hard-delete an existing entity (user, agent, app, or run) and all its associated data, using its type and id.

  • Delete memories
    destructive

    Deletes memories matching specified filter criteria; omitting all filters may result in deleting all memories. required: at least one of agent id, user id, app id, or run id must be provided.

  • Delete memory batch with uuids
    destructive

    Deletes a batch of up to 1000 existing memories, identified by their uuids, in a single api call.

  • Delete memory by id
    destructive

    Permanently deletes a specific memory by its unique id; ensure the `memory id` exists as this operation is irreversible.

  • Delete project
    destructive

    Permanently deletes a specific project and all its associated data from an organization; this action cannot be undone and requires the project to exist within the specified organization.

  • Delete project member
    destructive

    Removes an existing member, specified by username, from a project, immediately revoking their project-specific access; the user is not removed from the organization.

  • Export data based on filters

    Retrieves memory export data, optionally filtered by various identifiers (e.g., user id); without filters, it may return all accessible or recent exports based on default behavior.

  • Fetch details of a specific organization

    Fetches comprehensive details for an organization using its `org id`; the `org id` must be valid and for an existing organization.

  • Get entity by id

    Fetches detailed information for an existing entity (user, agent, app, or run) identified by its type and unique id.

  • Get list of entity filters

    Retrieves predefined filter definitions for entities (e.g., by type, creation/modification date); returns definitions only, not filtered entity data.

  • Get organization members

    Fetches a list of members for a specified, existing organization.

  • Get project details

    Fetches comprehensive details for a specified project within an organization.

  • Get project members

    Retrieves all members for a specified project within an organization.

  • Get projects

    Retrieves all projects for a given organization `org id` to which the caller has access.

  • Get user memory stats

    Retrieves a summary of the authenticated user's memory activity, including total memories created, search events, and add events.

  • List entities

    Retrieves a list of entities, optionally filtered by organization or project (prefer `org id`/`project id` over deprecated `org name`/`project name`), noting results may be summaries and subject to limits.

  • List organizations

    Retrieves a summary list of organizations for administrative oversight; returns summary data (names, ids), not exhaustive details, despite 'detailed' in the name.

  • Perform semantic search on memories

    Searches memories semantically using a natural language query (required if `only metadata based search` is false) and/or metadata filters. required: at least one of agent id, user id, app id, or run id must be provided. when `only metadata

  • Remove a member from the organization
    destructive

    Removes a member, specified by their username, from an existing organization of which they are currently a member.

  • Retrieve all events for the currently logged in user

    Retrieves a paginated list of events for the authenticated user, filterable and paginable via url query parameters. this is a read-only operation that does not modify data. supported query parameters (applied directly to the request url): -

  • Retrieve entity-specific memories

    Retrieves all memories (e.g., user preferences, chat history) for a specific entity from the mem0 platform, using its `entity type` and `entity id`; ensure the entity exists.

  • Retrieve list of memory events

    Retrieves a chronological list of all memory events (e.g., user inputs, ai responses) from the mem0 platform, providing interaction history and context for ai assistants.

  • Retrieve memory by id

    Retrieves a complete memory entry by its unique identifier; `memory id` must be valid and for an existing memory.

  • Retrieve memory history by id

    Retrieves the complete version history for an existing memory, using its unique `memory id`, to inspect its evolution or audit changes.

  • Retrieve memory list

    Retrieves a list of memories, supporting pagination and diverse filtering (e.g., by ids, metadata, keywords, date ranges); ensure dates are iso 8601 and `page`/`page size` (if used) are positive integers. required: at least one of agent id,

  • Search memories with filters

    Semantically searches memories using a natural language query and mandatory structured filters, offering options to rerank results and select specific fields; any provided `org id` or `project id` must reference a valid existing entity.

  • Update memory batch with uuid

    Updates text for up to 1000 memories in a single batch, using their uuids.

  • Update memory text content

    Updates the text content of an existing memory, identified by its `memory id`.

  • Update organization member role

    Updates the role of an existing member to a new valid role within an existing organization.

  • Update project

    Updates a project by `project id` within an `org id`, modifying only provided fields (name, description, custom instructions, custom categories); list fields are fully replaced (cleared by `[]`), other omitted/null fields remain unchanged.

  • Update project member role

    Updates the role of a specific member within a designated project, ensuring the new role is valid and recognized by the system.

Setup

Setup guide

  1. 11. In Switchy, open Settings and navigate to Integrations. 2. Search for Mem0 and click Connect. 3. Go to your Mem0 dashboard at mem0.ai, generate an API key under Account Settings, and copy it. 4. Paste the API key into Switchy's connection dialog and click Authorize. 5. Switchy confirms the connection and lists available tools. 6. Open any Space, type '@Mem0 create a new agent with agent id onboarding-bot', and send. 7. Mem0 responds with the agent details, confirming the integration works. 8. To store a memory, try '@Mem0 add new memory records for agent id onboarding-bot with messages about our Q1 goals'. 9. Later, retrieve that context by asking '@Mem0 what do you remember about Q1 goals for onboarding-bot'. 10. Repeat for other memory scopes — user, app, or run — depending on how your team segments context.

What teammates see: by default, memories from Mem0 are scoped to the Space (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.

Works well with

Top models

Compatibility data appears once enough Spaces have used this MCP together with a given model.

How Switchy teams use it

Not enough Spaces yet to publish anonymised usage stats (we require ≥ 50 Spaces per week).

Starter prompts

Create Agent Memory

@Mem0 create a new agent with agent id sprint-assistant and name it Sprint Planning Bot
Open in a Space →

Store Project Context

@Mem0 add new memory records for agent id sprint-assistant with messages summarizing our Q2 roadmap priorities and blockers
Open in a Space →

Retrieve Past Decisions

@Mem0 what do you remember about Q2 roadmap priorities for sprint-assistant
Open in a Space →

Organize Team Members

@Mem0 add organization member with user id alice@example.com to our org and assign them the editor role
Open in a Space →

Track Customer History

@Mem0 add new memory records for user id customer-12345 with messages about their billing issue and preferred contact method
Open in a Space →

Example outputs

Illustrative - representative of the model's voice and quality, not literal recordings.

Prompt

@Mem0 search all memories related to our Q4 product roadmap discussions and list the key decisions we've captured

Output

Found 7 memory records tagged with 'Q4 roadmap'. Key decisions include: (1) prioritizing mobile app performance over new features, captured from your Oct 12 planning session; (2) delaying the analytics dashboard to Q1 2025, noted in the Oct 18 stakeholder call; (3) allocating 2 engineers to API stability work, from your Oct 25 retrospective. These memories span 3 different agent runs and include context from 4 team members. All records were last updated within the past 3 weeks.

Notes

This example shows Mem0's core strength: retrieving contextual memory across multiple conversations and agents. The search scope depends on your organization's memory retention settings and which user/agent/app IDs you've associated with past records. Results reflect what your team has explicitly stored, not inferred content.

Prompt

@Mem0 store this decision: we're switching our CI/CD pipeline from Jenkins to GitHub Actions starting next sprint, with migration complete by Nov 30

Output

Memory record created successfully. Stored decision: 'CI/CD pipeline migration from Jenkins to GitHub Actions, target completion Nov 30'. Associated with your user ID and tagged with the current agent run. This memory is now searchable by your team and will surface in future conversations when discussing deployment infrastructure or sprint planning. Record ID: mem_8x4k2p9w, created at 2024-10-28 14:32 UTC.

Notes

Demonstrates Mem0's write capability for capturing decisions in real-time. Requires an active agent_id, user_id, app_id, or run_id to anchor the memory. The stored content becomes part of your team's shared context, but you control visibility through organization and project membership settings. No automatic expiration unless configured.

Prompt

@Mem0 create a new agent called 'sprint-planner' and associate it with our engineering project so it can access our velocity and backlog memories

Output

Agent 'sprint-planner' created with ID: agent_7h3m9k2x. To associate it with your engineering project, you'll need to add it as a project member using the project ID (requires separate action). Once linked, this agent can query memories tagged with that project context, including historical velocity data and backlog discussions. Note: the agent itself doesn't automatically inherit permissions—you must explicitly grant project access and define which memory scopes it can read or write.

Notes

Shows Mem0's organizational structure for multi-agent workflows. Creating an agent is straightforward, but connecting it to projects and defining memory access requires additional API calls (add member to project, set role permissions). This example highlights the setup overhead: Mem0 is powerful for teams managing multiple AI agents with distinct memory contexts, but initial configuration is multi-step.

Use-case deep-dives

Customer support context handoff

When Mem0 wins for multi-agent support workflows

A 6-person support team runs three AI agents—one for ticket triage, one for knowledge lookup, one for draft replies. Mem0's memory records let each agent store what it learned about a customer across sessions, so the next agent in the chain doesn't start cold. The "add new memory records" tool ties context to user IDs or run IDs, meaning your triage agent can flag a VIP customer and the reply agent sees that flag two hours later. The 43-tool surface is overkill if you're just storing chat history; this MCP pays off when you're orchestrating multiple agents that need to share learned context, not just replay transcripts. If your support flow is single-agent or you don't need cross-session memory, a simpler vector store is faster to wire up.

Multi-tenant SaaS onboarding automation

Mem0 handles org-scoped memory for product-led growth teams

A 10-person PLG team at a B2B SaaS company uses AI agents to personalize onboarding flows for each customer org. Mem0's organization and project membership tools let you partition memory by tenant—one org's onboarding preferences don't leak into another's. The "create a new organization entry" and "add organization member" tools map cleanly to your product's account structure, so the agent remembers which features a customer explored during trial and surfaces them again at renewal. This MCP is the right call when you're building multi-tenant AI features and need memory isolation baked in. If you're a single-tenant app or your agents don't need org-level scoping, the auth overhead (API key plus org/project IDs) adds friction you don't need.

Sales team CRM context enrichment

When Mem0 bridges AI agents and existing CRM data

A 4-person sales team uses an AI agent to draft follow-up emails after discovery calls. Mem0's user and metadata tools let the agent store deal-stage notes, competitor mentions, and pain points tied to each prospect's user ID, then retrieve that context when the rep asks for a proposal draft two weeks later. The "create a new user" and "add new memory records" tools mean your agent builds a lightweight memory layer on top of your CRM without replacing it—Switchy's workspace pulls Mem0 context and your CRM data into the same thread. This setup wins when your CRM is rigid and your reps need AI that remembers nuance the CRM fields can't capture. If your CRM already has flexible notes or your team doesn't do multi-touch sales, Mem0's 43-tool API is heavier than you need.

Frequently asked

What does the Mem0 MCP do in Switchy?

It connects Switchy to Mem0's memory layer, letting your AI agents store and retrieve context across conversations. You can create agents, manage memory records tied to users or runs, and organize everything under projects and organizations. Think of it as persistent memory for your team's AI workflows — the agent remembers what happened last week without you pasting chat history.

Do I need a Mem0 API key to use this MCP?

Yes. You authenticate with an API key from your Mem0 account. Grab it from the Mem0 dashboard, paste it into Switchy's connection flow, and you're done. No OAuth dance, no admin approval — just the key. If your team shares one Mem0 org, one person can connect it and everyone in the Switchy workspace sees the same memory store.

Can the Mem0 MCP delete or update existing memories?

The representative tools shown focus on adding new memory records, creating agents, and managing org structure. If you need to edit or purge specific memories, check Mem0's full API — this MCP exposes 43 tools total, so update and delete operations may be in the full list. For now, assume it's optimized for writing new context, not surgical edits.

How is this different from just calling Mem0's API directly?

The MCP wraps Mem0's API so your AI agents in Switchy can call it mid-conversation without you writing code. Instead of building a script to POST memory records, the agent decides when to store context and does it automatically. You trade raw API flexibility for conversational convenience — the agent becomes the integration layer.

Who on my team should connect the Mem0 MCP?

Whoever owns your Mem0 account and has the API key. Once connected in Switchy, all workspace members can use the memory tools in their agent chats. If you're running multiple projects, consider whether you want one shared memory org or separate Mem0 accounts per team — the MCP doesn't enforce isolation, so plan your org structure in Mem0 first.

Data last verified 607 hours ago.Sources aggregated hourly to weekly. See docs/architecture/model-directory.md.