Comparison
Pathrule vs the MCP memory server
The reference memory server gives an agent a local knowledge graph of entities, relations and observations, and eight tools to write and read it. Pathrule speaks the same protocol, so the difference is not transport. It is that the reference server waits to be called, keeps one shared graph with no notion of where you are working, and cannot enforce anything.
What the reference server is for
It is the canonical example of an MCP server that holds state, and it is genuinely the fastest way to understand what MCP is. Entities carry observations, relations connect them in active voice, everything persists to a JSONL file you can open in an editor, and the whole thing runs from a single command with no account and no service.
For a solo experiment, for learning the protocol, or for a handful of facts you want an agent to remember across conversations, that is enough and nothing here argues otherwise.
Side by side
| Reference MCP memory server | Pathrule | |
|---|---|---|
| Transport | MCP | MCP, plus hooks in Pathrule Studio and the CLI |
| How knowledge arrives | The agent must call a tool: `search_nodes`, `read_graph` | Studio injects it at hook time, before the first tool call |
| Scope | One shared graph, no path or user scoping | Indexed by repository path, per workspace |
| What is stored | Entities, relations, observations | Memories, rules and skills, typed and prioritised |
| Enforcement | None | A strict rule can block a matching change |
| Team | A local JSONL file | Shared workspace with roles and review |
| Stale knowledge | Yours to notice | Raised as a proposed edit you approve |
Reference server claims are from its README in modelcontextprotocol/servers, read August 2026. If a row is wrong, tell us and we will fix it.
The differences that follow from that
A tool the agent must remember to call. Its README is explicit that agents must call the tools; nothing is automatic. So the agent has to decide to search before it acts, which is the same gap every query-driven memory has: the constraint you most need is the one nobody thought to look up.
One graph, no sense of place. There is no repository-path scoping and no isolation: it is a single shared graph for every interaction. That is fine for a few dozen facts and unworkable once two services in one monorepo disagree about what a valid change looks like.
Nothing can be a constraint. Observations are text an agent may read. A Pathrule rule carries a scope, a priority and an enforcement level, so the local hook can stop a matching change before it lands rather than leaving it to the model's judgement.
When the reference server is the right choice
Use it when you are learning MCP, when you want a dependency-free scratchpad for one agent on one machine, or when the knowledge really is a handful of entities rather than a team's accumulated conventions. It is a reference implementation doing exactly what a reference implementation should.
Reach for Pathrule when the knowledge has to be scoped to where the work is happening, when it has to reach a teammate's session and a second engine, when some of it must gate a change rather than suggest against one, and when you would rather the agent proposed what to keep than maintain a graph by hand.
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.
Frequently asked questions
Pathrule is an MCP server too. What is actually different?
The protocol is the same; the delivery is not. The reference server hands over knowledge when an agent calls a tool. Pathrule Studio runs the agent itself and registers hooks, so the slice that governs the path you are working in arrives before the first tool call, whether or not the agent would have asked. The CLI does the same for agents you drive from a shell.
Can I use the reference memory server alongside Pathrule?
Nothing stops you, but they overlap: both are places an agent keeps knowledge. Running both usually means two half-maintained stores, and the one with no path scoping is the one that decays. Pick per project.
Does Pathrule work if I can only use a hosted MCP endpoint?
Yes, with one limitation worth knowing. Pathrule Studio is the complete product; the CLI, the VS Code extension and the hosted Remote MCP endpoint are lighter ways in. Remote MCP exposes the same workspace, memories, rules and skills over OAuth, but it cannot read local files or run hooks, so it answers on request rather than delivering before the first tool call. Hook-time delivery comes with Studio or the CLI.
Does Pathrule store entities and relations like a graph?
It keeps a knowledge graph, but the index is the repository path rather than an entity name, and the content is typed: memories are facts, rules are constraints with scope and priority, skills are named procedures. That typing is what makes enforcement and ranking possible.