Category
MCP memory servers, and what they can carry
An MCP memory server is a Model Context Protocol server whose tools let an agent store and retrieve knowledge that outlives the session. The protocol settles how the agent talks to it. What it does not settle is when the knowledge arrives, and for a coding agent that is the part that decides whether the memory is ever used.
An MCP server that exposes memory as tools: write something down, read it back, and have it persist past the end of the conversation. Because it speaks the Model Context Protocol, any MCP client can connect to it without a bespoke integration, which is what makes memory portable across agents.
The protocol is a transport and a tool contract, not a memory model. Two MCP memory servers can agree on every message and still disagree about what a memory is, how it is scoped, and whether the agent has to ask for it. New to the protocol itself: what is the Model Context Protocol.
Why agents reach for MCP to persist context
Before MCP, every agent had its own file, its own configuration format and its own idea of an integration. Teaching four agents the same thing meant maintaining it four times. MCP replaced that with one contract: a server publishes typed tools, and any client that speaks the protocol can call them.
For memory this matters more than for most tool categories, because memory is the thing you least want locked inside one agent. A store reachable over MCP is reachable from whichever agent the team is using this quarter, which is why persistent context showed up early as an MCP use case.
What an MCP memory server is asked to do
Persist past the conversation. The minimum. Something written in one session is readable in the next, without the client holding it.
Come back typed. A memory, a rule and a procedure are different things. A server that returns one undifferentiated blob of text hands the agent the job of telling them apart.
Be reachable from any client. The reason to use the protocol at all. One store, many agents, no per-agent copy of the same knowledge.
Say what a request is scoped to. For a coding agent the scope that matters is the path being worked in. Without it every read returns the whole store and the client pays for the difference.
Recall on request, and delivery before the first tool call
This is the distinction worth being precise about, because it is invisible until it costs you something. An MCP tool is pull: the agent decides to call it. That is exactly right for a lookup the agent knows it needs, and it is the only thing a cloud-only connector can do, since it cannot see your filesystem or take part in the agent's startup.
A constraint the agent does not know exists is a different problem. It will not call a tool to ask whether coupons attach to the line item, because nothing in the prompt suggests the question. Pull memory is silent in exactly the case where being wrong is most expensive.
Push closes that gap. A runtime that starts the agent can read the working directory and inject the matching knowledge before the first tool call, so the constraint is in context whether or not the agent would have asked. Both are useful and they are not alternatives: the same store can be pushed at hook time and pulled by tool call in the same session.
Request-time recall vs hook-time delivery
| Recall on request (any MCP client) | Delivery at hook time (a local runtime) |
|---|---|
| The agent calls a tool when it decides it needs something. | The matching slice arrives before the first tool call, every turn. |
| Nothing arrives for a constraint the agent never suspected. | The constraint is in context whether or not the agent would have asked. |
| Scope is whatever the agent passes in the arguments. | Scope is the working directory the runtime can actually see. |
| Works from a cloud-only client with nothing installed. | Needs a runtime on the machine: Pathrule Studio or the CLI. |
| Context only. There is no pre-write event to hook. | A strict rule can block a violating change before it lands. |
Side by side with the protocol's own reference implementation: Pathrule vs the MCP memory server.
The reference server, and what it is for
The Model Context Protocol ships a memory server of its own: a knowledge graph of entities, relations and observations, persisted to a JSONL file, with tools to create and read them. It is a clear, honest reference implementation and it is genuinely the right choice when what you want is a place an agent can put things, on your own disk, with no account and no service.
It is a different job from a team context layer, and the comparison should not pretend otherwise. The reference server does not model paths, memberships, rule enforcement or delivery timing, because those were never its brief. What it settles is that the protocol can carry memory at all.
How Pathrule serves memory over MCP
Every Pathrule surface speaks the same MCP contract, so an agent sees the same tools and the same path-scoped context wherever it connects. The tools read a workspace and get context for a path, write content path-first (a missing node materializes on demand, so an agent never has to build the tree before writing to it), and log what happened, which is what lets knowledge be reviewed later rather than only written. Access is per workspace, gated by OAuth scopes and row-level security.
What differs between the two ways to run it is not the tool surface. It is what the runtime can reach.
Local server or hosted endpoint
Local, over stdio. Pathrule Studio and the CLI run the same server on your machine. That is the version that resolves your working directory, reads the local cache, works offline against it and runs hooks. One contract, every surface.
Hosted, at `mcp.pathrule.io/mcp`. An OAuth endpoint for clients that can only reach a connector, with the registry manifest beside it at
/server.json. Nothing to install. Remote MCP.The difference that matters. The hosted endpoint cannot read local files or run hooks, so it answers on request rather than before the first tool call. That is a property of being cloud-only, not a Pathrule limitation, and it is the reason Studio is the complete product and the endpoint is a lighter way in.
Memory, rules and skills over one contract
Pathrule's tool surface is not memory alone. The same server carries memories, rules and skills, typed rather than flattened into text, which is what lets a client tell a fact from a constraint from a procedure. Rules carry a scope, a priority and an enforcement level, and it is the local runtime, not the protocol, that can act on a strict one.
One more thing the contract buys: a capability connected once is written into every installed agent's configuration, instead of being wired up per agent. Long read: connect an MCP tool once for every AI engine.
Connecting a client
Sources
Official product documentation reviewed August 20, 2026.
- Model Context Protocol: reference memory server
Official tools, graph model and JSONL persistence for the reference server.
- Model Context Protocol: specification
Official protocol roles, transports and the client/server tool contract.
Frequently asked questions
What is an MCP memory server?
A Model Context Protocol server whose tools let an agent store knowledge and read it back in a later session. Because it speaks MCP, any MCP client can connect without a bespoke integration, which is what makes the memory portable across agents.
Does MCP define how memory should work?
No. MCP settles the transport and the tool contract, not the memory model. Two MCP memory servers can agree on every message and still disagree about what a memory is, how it is scoped and whether the agent has to ask for it.
Why is MCP memory not enough on its own for a coding agent?
Because an MCP tool is pull: the agent calls it when it decides it needs something. A constraint the agent does not know exists never gets asked about, so nothing arrives, and the failure is silent. Delivery before the first tool call is what covers that case, and it needs a runtime on the machine rather than a protocol feature.
How is Pathrule different from the MCP reference memory server?
The reference server is a knowledge graph of entities, relations and observations persisted to a JSONL file on one machine: a good place for an agent to put things. Pathrule adds path scope, team membership, typed rules with enforcement, and hook-time delivery before the first tool call. Full side by side: Pathrule vs the MCP memory server.
Do I need to install anything to use Pathrule over MCP?
Not for a cloud-only client. The hosted endpoint at mcp.pathrule.io/mcp connects over OAuth with nothing installed. To get hook-time delivery, local cache and offline reads you need a local runtime, which is Pathrule Studio or Pathrule CLI.
Can the hosted endpoint enforce a strict rule?
No. It has no pre-write event to hook, so it delivers rules as context and cannot block a change. Studio handles strict enforcement for the agents it runs, and Pathrule CLI registers the available hooks for standalone Claude Code, Cursor, Codex and GitHub Copilot. Windsurf and Remote MCP receive rules as context only.
Which MCP clients can connect to Pathrule?
Any client that speaks the protocol. Studio runs Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode natively; Pathrule CLI connects Cursor, Windsurf and GitHub Copilot; and cloud-only clients use the hosted endpoint. The MCP overview covers the roles, and the products page has the full surface matrix.
Is my source code sent to the MCP server?
No. Pathrule never reads, scans or uploads source files over any surface. The server carries the typed memories, rules and skills your team writes, plus the structural information needed to deliver them to the right path. Full breakdown on the Security page.