Agent Memory

Connect with MCP

Read and write memory from MCP clients such as Claude Code, Claude Desktop, VS Code, and Cursor.

Agent Memory exposes memory operations as Model Context Protocol (MCP) tools. MCP clients such as Claude Code, Claude Desktop, VS Code, Cursor, Cline, and Codex use these tools to read and write memory.

There are two transports:

TransportWhen
Streamable HTTP (/v1/mcp)The recommended path. The service is remote or shared; no database details are sent to the client.
stdio (AgentMemory.Mcp)The client wants to start the process itself. In local mode it connects directly to the database; in remote mode, to the HTTP API.

HTTP MCP addresses

AddressWhere memory is written
$API/v1/mcpThe credential's workspace, shared pool (no application).
$API/v1/workspaces/<workspaceId>/mcpA specific workspace. Your credential must have access to that workspace.

Application-specific memory

To work with memory specific to one application, create an application-bound key in the console (API Keys → select an application).

Authentication

With an API key (works in every client)

Add the address and header to the client's MCP configuration:

{
  "mcpServers": {
    "agent-memory": {
      "url": "https://memory.empecta.com/v1/mcp",
      "headers": { "Authorization": "Bearer amk_..." }
    }
  }
}

The console's Install page generates a ready-made configuration for the client you choose; when a key is created, a copyable mcpServers snippet is also shown.

Keyless sign-in

Connecting with just the address and signing in through the browser (OAuth) is on the roadmap. For now, connect with an API key.

Claude Code plugin

The Claude Code plugin is published in the public repository erkansezgin/agentmemory-claude-plugin. Install it with:

/plugin marketplace add erkansezgin/agentmemory-claude-plugin
/plugin install agentmemory@agentmemory

The plugin registers the HTTP MCP server using two environment variables:

VariableDefault
AGENT_MEMORY_URLhttps://memory.empecta.com/v1/mcp
AGENT_MEMORY_API_KEY— (required)

stdio server

{
  "mcpServers": {
    "agent-memory": {
      "command": "dotnet",
      "args": ["run", "--project", "/full/path/agent-memory-poc/AgentMemory.Mcp"],
      "env": {
        "MCP_MODE": "remote",
        "MCP_API_URL": "https://memory.empecta.com",
        "MCP_API_TOKEN": "amk_...",
        "MCP_WORKSPACE_ID": "<your-workspace-id>"
      }
    }
  }
}
VariableMeaning
MCP_MODElocal (default; the process connects directly to PostgreSQL/Redis, intended for a developer machine) or remote (to the HTTP API with a token).
MCP_API_URL, MCP_API_TOKENRequired in remote mode. The token can be an API key.
MCP_WORKSPACE_IDThe workspace to work in.
MCP_TENANT_IDThe tenant in local mode (default: the development tenant). In remote mode the tenant comes from the token.
MCP_AGENT_IDAgent name. In remote mode it is claimed only if provided; the key must be bound to that agent.
MCP_APPLICATION_IDOptional application.
MCP_RUN_IDThe run ID used for all calls from the process (default: random per process).

In the stdio server, identity comes from configuration: the tools have no agentId, facet, or runId parameters, and no server instructions (instructions) are sent. local mode is a trusted developer process that performs no permission checks; in shared environments use remote mode or the HTTP transport.

Tools

The HTTP server offers 20 tools. Tools that take an ID accept, in addition to the full GUID, the short ID from search output (a prefix of at least 8 characters that is unique within the workspace).

ToolWhat it doesRequired permission
search_memoryFetches context at the start of a task. Parameters: query, runId, userId, facet, includeSuperseded, explain, tokenBudget, mode, rerank. The output ends with (receipt <id>).read
add_memoryWrites persistent information. Parameters: content, type, runId, visibility, userId, facet, sourceKind, sourceRef, observedAt, validFrom, validTo, supersedes, idempotencyKey.write (promote for visibility=tenant)
get_memoryReads a record by ID (including version). Use it for artifact_ref records.read
explain_memoryExplains a record's source, lineage, superseding records, contradictions, dependents, usage, and confidence.read
update_memoryCorrects content in place; if you pass version, it does not write when a change happened in between.write
supersede_memoryLinks which of two existing records is current (memoryId the old one, supersededBy the new one).write
share_memoryWidens visibility (agent, user, workspace, tenant).share + ownership
delete_memoryDeletes; requires cascade=true if there are derived records.delete
erasure_statusTells whether deletion has completed in derived copies.read
get_operationShows the status of the operation from add_memory output.read
consolidateDistills a run into episodes, facts, and procedures (runId, goal).curate
report_outcomeReports the task outcome (runId, receiptId, buildSuccess, testPassRate, deploySuccess, errorCount, warningCount, userRating, notes).feedback
record_retrieval_feedbackReports used/ignored records and procedures.feedback
list_proceduresLists/searches learned procedures.read
search_episodesFinds similar past tasks.read
get_blocks, curate_blockReads blocks; edits a block line by line (add, replace, remove).read / curate
search_filesSearches documented file summaries.read
get_user_profileReads an end-user profile.read + act for users
get_changesetsLists the workspace's change feed with a cursor.read

Tools return results as plain text. Errors arrive not as MCP protocol errors but as text starting with Error: …; your agent only needs to read this text.

Example add_memory response:

Operation 72afb4fb6c63427082a26b74390445ff. Memory stored: ad9a5c41-f032-4274-b2f6-df98d34ef542

If the same content already exists, the response is Memory merged into existing entry <id> ….

When does the agent use memory?

The model calls MCP tools and decides when to call them. The HTTP server passes the following loop to the connected client as server instructions:

  1. At task start, search_memory — recall earlier decisions, corrections, and approved patterns.
  2. During the task, add_memory — when something lasting happens, write it with the right type, and use the same runId throughout the task.
  3. At task end, consolidate(runId).
  4. Once the outcome is known, report_outcome(runId, receiptId).

Some clients apply server instructions weakly. For the most reliable results, add the same rule to the client's project instructions as well (for example AGENTS.md, .cursorrules, .clinerules, .github/copilot-instructions.md, Claude project instructions):

This project has a persistent memory MCP server connected. Use it as a loop:
- Call search_memory at the start of every task; recall earlier decisions, corrections,
  violations and approved patterns, and follow them.
- When you make a decision, when the user corrects you, when a rule is broken, or when a
  solution is approved, save it with add_memory using the right type. Use the same runId
  throughout the task.
- When the task is done, call consolidate(runId); once the outcome is known, send report_outcome.

Limits

  • In MCP, search_memory does not offer reading as of a past point in time (as-of) or topN; use REST POST /v1/memory/retrieve for these.
  • The consolidate tool does not take custom extraction instructions; consolidation with instructions is available in REST.
  • Valid values for sourceKind: agent, user, document, import.
  • Every tool call counts toward the monthly operation quota.

On this page