MemoryOS MCP Server

MemoryOS MCP lets an agent call MemoryOS as tools instead of importing the SDK directly into the main application process. Use MCP when you want MemoryOS isolated from your core backend, or when your agent runtime already supports the Model Context Protocol. The normal tenant tools use your workspace API key and existing external_user_id values. They do not require Memory Passport or a consent screen.

The consent and universal MCP tools belong to the frozen Memory Passport private beta. They are disabled by default and are not part of the supported MCP integration path.

Placeholder: create a MemoryOS API key from the workspace dashboard

Install

pip install memoryo-mcp

For local development from this repository:

cd memoryos-mcp
pip install -e .

Configure

Use a workspace API key from the MemoryOS dashboard.

MEMORYOS_API_KEY=mem_live_xxx
MEMORYOS_API_URL=https://api.memoryo.dev

Run

memoryo-mcp

Claude Desktop example:

{
  "mcpServers": {
    "memoryos": {
      "command": "memoryo-mcp",
      "env": {
        "MEMORYOS_API_KEY": "mem_live_xxx",
        "MEMORYOS_API_URL": "https://api.memoryo.dev"
      }
    }
  }
}

What the agent can call

The MCP server exposes first-class tools for the normal MemoryOS flow:

memoryos_add_memory
memoryos_get_context
memoryos_list_memories
memoryos_delete_memory
memoryos_get_job_status

It also exposes domain tools. Cross-agent tools may remain present in an SDK build for private-beta compatibility, but their backend endpoints are disabled by default:

memoryos_get_domain_schema
memoryos_set_domain_schema
memoryos_get_edtech_profile
memoryos_set_support_type
memoryos_list_support_customers
memoryos_get_support_stats
memoryos_create_consent_url
memoryos_universal_get_context
memoryos_universal_add_memory

For newly released endpoints, memoryos_api_request provides an allowlisted escape hatch across MemoryOS API paths.

One server for every schema

You do not run separate MCP servers for General, EdTech, and Customer Support. The tool call stays the same:

{
  "external_user_id": "cust_123",
  "query": "what should I know before replying?"
}

MemoryOS applies the correct engine based on your workspace setting:

General Engine -> general memory context
EdTech Schema -> general context + tutoring profile
Customer Support Schema -> general context + support profile

For historical tenant retrieval, pass a timezone-aware ISO 8601 as_of value to memoryos_get_context, for example 2026-08-01T12:00:00Z. For retry-safe universal writes, pass idempotency_key to memoryos_universal_add_memory. The key is sent in the universal request body, matching the API contract.

Memory authority boundary

memoryos_add_memory and memoryos_remember accept conversation content as an assertion from the MCP client. MemoryOS records that provenance and applies the client-assertion authority tier; the MCP client cannot choose a higher tier in tool arguments or metadata. Pass conversation_id when your agent has a stable conversation identifier. MemoryOS records it with the queued job for provenance and auditability.

memoryos_add_memory(
    external_user_id="cust_123",
    conversation_id="support-thread-884",
    messages=[
        {"role": "user", "content": "I prefer a one-line diagnosis first."},
        {"role": "assistant", "content": "I will lead with a one-line diagnosis."},
    ],
)

Standalone MCP text is not MemoryOS-attested user evidence. It cannot silently overwrite a higher-authority user-confirmed memory. If it contradicts trusted memory, MemoryOS keeps the trusted memory active and quarantines the assertion for review or clarification. Do not place tool output, fetched documents, or retrieved text into a message as if it were user input. Those sources may support an observation, but they do not prove user consent or confirmation.

Support agent boundary

For customer support, MCP gives the agent remembered context. Your support platform still provides live tools.

MemoryOS MCP:
  what does this customer prefer?
  what open issue did they mention earlier?
  what context should the agent not ask again?

Your backend tools:
  get_order()
  create_refund()
  get_invoice()
  update_ticket()

The agent should not claim a refund, invoice, or account change was completed unless your own backend tool actually completed it.

​Install

​Configure

​Run

​What the agent can call

​One server for every schema

​Memory authority boundary

​Support agent boundary

Install

Configure

Run

What the agent can call

One server for every schema

Memory authority boundary

Support agent boundary