An agent that "remembers" your project between sessions is not remembering anything. Something handed it a file, and it read the file. The interesting question is not how the model stores knowledge, it is who decides what gets handed over, and the Model Context Protocol answers that question in a sentence most people skip.
The sentence that settles it
The MCP specification describes resources, the mechanism by which a server exposes data to a model, and it states their design intent plainly:
Resources in MCP are designed to be application-driven, with host applications determining how to incorporate context based on their needs.
Read what that assigns and to whom. The server offers. The host application decides. The model receives whatever survived that decision.
The specification then declines to standardise the decision itself: implementations are free to expose resources through any interface pattern that suits them, and the protocol itself does not mandate any specific user interaction model. It suggests possibilities, a picker in a tree or list view, a search field, or automatic inclusion based on heuristics or the model's own selection, without requiring any of them.
So two agents speaking the same protocol, connected to the same server, can end up with completely different context. That is not a flaw. It is the protocol refusing to make a product decision on your behalf.
What a resource is, concretely
A resource is data identified by a URI: a file, a database schema, application-specific information. Servers that support them must declare a resources capability, and may advertise two optional features:
listChanged, whether the server emits a notification when the list of available resources changes.subscribe, whether it supports update notifications for specific resources a client asked to watch.
A server may advertise either, both, or neither. Clients discover what exists with resources/list and read content with resources/read.
One constraint in the specification is worth pausing on, because it rules out a whole category of clever design. The set of resources a server returns must not vary per-connection or as a side effect of other requests on the connection. It may change over time, and it may vary by the authorization presented on the request, since credentials are per-request input rather than connection state.
In other words: a server cannot quietly show you a different catalogue because of what you asked earlier in the session. What varies is what your credentials permit, not what your history implies.
The annotations are the actual memory policy
If there is a place where "memory" gets decided, it is here. Resources carry optional annotations that hint to clients how to use them:
audience: who the content is for,"user","assistant", or both.priority: a number from 0.0 to 1.0. The specification is unusually direct about the ends of that scale: 1 means most important, effectively required, while 0 means least important, entirely optional.lastModified: an ISO 8601 timestamp.
Clients use these to filter by audience, to prioritise which resources to include in context, and to sort by recency.
That is the whole mechanism. What an agent "remembers" is what scored high enough on someone else's priority field to survive the context budget. There is no recall, no forgetting, no consolidation. There is a ranked list and a limit.
Two error rules that reveal the design philosophy
The specification's error handling says something about how seriously it takes ambiguity.
A missing resource must return a JSON-RPC error, code -32602. And then this: servers must not return an empty contents array for a non-existent resource, because an empty array is ambiguous, it could mean the resource exists but has no content, or that it doesn't exist at all.
A protocol that spells out why an empty array is unacceptable is a protocol designed by people who have debugged agents. Silent emptiness is how an agent ends up confidently reasoning about a file it never read.
The security rules you inherit by using it
Because resources are addressed by URI and often map to files, the specification carries explicit obligations. Servers must validate all resource URIs. They must sanitise file paths to prevent directory traversal attacks when serving file:// resources. Access controls should be implemented for sensitive resources, and permissions should be checked before operations.
These are not exotic requirements, and that is the point. Exposing your filesystem to a model through a protocol does not change what a path traversal is. It only increases the number of things holding the rope.
What this changes in how you think about agents
Stop asking what the model remembers. Ask which resources the host application decided to include, at what priority, and under which credentials. That is the entire answer, and it lives in the application, not in the model.
Persistence is a file, not a faculty. An agent that recalls your conventions across sessions is reading a document that something chose to expose again. Change the exposure and the memory changes, instantly and completely.
Priority is where the real design happens. A 0.0 to 1.0 field decides what survives a limited context. That number, set by whoever wrote the server, does more to shape agent behaviour than most prompt engineering.
The word "memory" imports expectations from human cognition that the mechanism does not support. What MCP actually specifies is a catalogue, an access policy, and a ranking. Knowing that is the difference between designing an agent's context deliberately and being surprised by it.
The description of MCP resources here, including the application-driven design intent, the statement that the protocol does not mandate a user interaction model, the resources capability with listChanged and subscribe, the constraint that the resource set must not vary per-connection while it may vary by authorization, the audience, priority and lastModified annotations, the -32602 error code, the prohibition on returning an empty contents array, and the URI validation and path sanitisation requirements, is taken from the Model Context Protocol specification, checked at the time of writing. The specification evolves; verify against the current revision before relying on a specific detail.
