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:
| Transport | When |
|---|---|
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
| Address | Where memory is written |
|---|---|
$API/v1/mcp | The credential's workspace, shared pool (no application). |
$API/v1/workspaces/<workspaceId>/mcp | A 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@agentmemoryThe plugin registers the HTTP MCP server using two environment variables:
| Variable | Default |
|---|---|
AGENT_MEMORY_URL | https://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>"
}
}
}
}| Variable | Meaning |
|---|---|
MCP_MODE | local (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_TOKEN | Required in remote mode. The token can be an API key. |
MCP_WORKSPACE_ID | The workspace to work in. |
MCP_TENANT_ID | The tenant in local mode (default: the development tenant). In remote mode the tenant comes from the token. |
MCP_AGENT_ID | Agent name. In remote mode it is claimed only if provided; the key must be bound to that agent. |
MCP_APPLICATION_ID | Optional application. |
MCP_RUN_ID | The 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).
| Tool | What it does | Required permission |
|---|---|---|
search_memory | Fetches 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_memory | Writes persistent information. Parameters: content, type, runId, visibility, userId, facet, sourceKind, sourceRef, observedAt, validFrom, validTo, supersedes, idempotencyKey. | write (promote for visibility=tenant) |
get_memory | Reads a record by ID (including version). Use it for artifact_ref records. | read |
explain_memory | Explains a record's source, lineage, superseding records, contradictions, dependents, usage, and confidence. | read |
update_memory | Corrects content in place; if you pass version, it does not write when a change happened in between. | write |
supersede_memory | Links which of two existing records is current (memoryId the old one, supersededBy the new one). | write |
share_memory | Widens visibility (agent, user, workspace, tenant). | share + ownership |
delete_memory | Deletes; requires cascade=true if there are derived records. | delete |
erasure_status | Tells whether deletion has completed in derived copies. | read |
get_operation | Shows the status of the operation from add_memory output. | read |
consolidate | Distills a run into episodes, facts, and procedures (runId, goal). | curate |
report_outcome | Reports the task outcome (runId, receiptId, buildSuccess, testPassRate, deploySuccess, errorCount, warningCount, userRating, notes). | feedback |
record_retrieval_feedback | Reports used/ignored records and procedures. | feedback |
list_procedures | Lists/searches learned procedures. | read |
search_episodes | Finds similar past tasks. | read |
get_blocks, curate_block | Reads blocks; edits a block line by line (add, replace, remove). | read / curate |
search_files | Searches documented file summaries. | read |
get_user_profile | Reads an end-user profile. | read + act for users |
get_changesets | Lists 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-df98d34ef542If 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:
- At task start,
search_memory— recall earlier decisions, corrections, and approved patterns. - During the task,
add_memory— when something lasting happens, write it with the right type, and use the samerunIdthroughout the task. - At task end,
consolidate(runId). - 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_memorydoes not offer reading as of a past point in time (as-of) ortopN; use RESTPOST /v1/memory/retrievefor these. - The
consolidatetool 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.