One Memory Service, Many Agent Hosts
The practical question for agentmemory is not whether it supports one preferred coding agent. It is how one lifecycle—capture, search, evolution, and inspection—can remain coherent while different hosts speak through hooks, REST, MCP, plugins, and skills. This chapter explains what each interface owns, why the standalone MCP shim can look smaller than the server, and what local-first persistence requires when the runtime has to survive a restart.
Different doors into the same lifecycle
Agentmemory has several interfaces because “agent integration” is not one technical operation. A hook is good at noticing that something happened. A REST endpoint is good at accepting a structured request from a script or service. MCP is good at telling an agent which tools, resources, and prompts are available. A plugin or skill is good at fitting those capabilities into the host's native workflow.
The distinction begins with hooks. A host lifecycle hook can send a session start, prompt, tool result, failure, compaction, or session-end event without requiring the model to remember a special command. That is the automatic capture path. It is intentionally lightweight and best effort: the hook posts to the local service, uses a short timeout, and lets the coding action continue if the service is unavailable. Hooks therefore answer “what did the host do?” They do not by themselves answer “what memory should the agent request now?”
REST is the broad programmatic door. A script can start or end a session, submit an observation, request context, search memories, save a deliberate memory, import data, or inspect health. Because these routes are registered as iii HTTP triggers, they enter the same functions and state model as MCP calls. A Python tool, a shell integration, or an agent host that does not implement MCP can still use the lifecycle through HTTP.
MCP is the agent-facing discovery door. The server advertises tools such as recall, save, smart search, sessions, graph queries, consolidation, lessons, diagnostics, and governance operations. It also exposes resources for status, project profiles, recent sessions, latest memories, graph statistics, and team profiles, plus prompts for recalling context, handing off a session, and detecting patterns. The important point is not the number of names. MCP gives an agent a typed, discoverable way to ask for a capability instead of hard-coding an HTTP path and response shape.
Skills solve a different problem. Making a tool available does not mean a model will know when to use it. The project distinguishes connect, which wires the MCP server into an agent's configuration, from installing native skills, which teaches the host when a recall, remember, handoff, or forget action is appropriate. A plugin can package hooks, the MCP server, and skills together so that the host sees both the lifecycle events and the decision guidance. This is why a working MCP connection can still produce poor continuity: the tools exist, but automatic capture or agent behavior may not be wired.
The interfaces are complementary rather than interchangeable. A deployment might use hooks for silent capture, MCP for interactive recall, REST for health checks and automation, and the viewer for human inspection. The memory state remains one service state as long as those paths point to the same running instance and data directory.
Why the MCP tool count can be misleading
The published @agentmemory/mcp package is a stdio shim, not a second full implementation of every server feature. When it can reach an agentmemory server through AGENTMEMORY_URL, it proxies calls to the running server and can expose the full 54-tool surface described by the current registry. That path includes the less frequently used coordination, lesson, graph, slot, sentinel, and diagnostic capabilities.
When no server is reachable, the shim falls back to a reduced local set of seven tools.