What 'Context' Actually Means in MCP

The Model Context Protocol gives server implementers three primitives: resources, tools, and prompts. Most MCP servers ship by exposing a flat list of resources — "here are the files I can serve you, AI client, pick whichever ones you want."

This is the obvious thing to do. It's also the wrong thing to do.

Why a flat resource list fails

The MCP client — a language model — is not great at deciding which of 47 resources to request. It doesn't know the contents in advance. It has to make a guess based on filename and a one-line description. Often it guesses wrong, retrieves too much, and burns context window on irrelevant material.

The user experience this produces: "I connected the MCP server but the AI doesn't seem to use the right context." That's a server-design failure, not a model failure. The server gave the model too much choice and too little guidance.

Tools beat resources for context delivery

The better pattern is to expose a small set of opinionated tools that take task-shaped parameters and internally route to the right resources.

Memplex exposes three:

• search_context(query, scope, task_hint, destination, token_budget) — returns a scoped pack of relevant memories with full lineage
• get_project_context(project_id, freshness_window, destination) — returns the current state of a project (recent decisions, active artifacts, open questions)
• explain_inclusion(memory_id) — returns the routing trace for why a memory was included in a previous response

The client passes the task; the server figures out which resources matter. The decision logic — what counts as relevant, what scope is allowed, how stale is too stale — lives where it belongs, in the server.

Context has scope, not just content

The other thing most MCP servers ignore: scope. "What context can this client see right now?" is a different question from "What context exists?"

Same user, different tasks, different scopes:

• Debugging a deployment issue in Cursor — full project access, recent files, deploy logs
• Asking ChatGPT a quick personal question — no work context, ever
• Working in a client-facing tool — only context tagged for external sharing

A well-designed MCP server treats scope as a first-class request parameter. Memplex resolves nine variables before returning a single byte: actor, destination, scope, task, project, token budget, source ACLs, destination policy, freshness.

Context has lineage

Every byte of context the model sees should have a clear answer to "where did this come from, and how do I know it's true?"

Memplex attaches to every memory: a source artifact link (paragraph-level where the source supports it), a confidence score, and a lifecycle state — raw, extracted, suggested, accepted, verified, pinned, or revoked. Retrieval can filter on any of them. The model gets the lineage in the response and can cite it in its answer.

This is the difference between AI that says "the team decided X" (confident hallucination) and AI that says "the team decided X, per the design doc dated March 4, last reviewed by Sean" (grounded answer).

Context has shape per destination

A 200K-token context window can handle a different pack than a 32K window. A client that doesn't render markdown should get plain text. A destination with strict sensitivity policy should see redacted versions of borderline content.

The server should reshape the response per destination. Token budget, format hint, sensitivity policy — all first-class. The alternative is "return everything, let the client truncate," which wastes bandwidth and produces inconsistent results.

What we want to see in the MCP ecosystem

MCP is young. The protocol patterns are still being established. We'd argue for:

• Tool-led servers over resource-led servers for context delivery
• Required provenance on retrieval responses — make lineage a standard field
• Scope and task as first-class request parameters, not implicit
• Token budget negotiation as a standard handshake
• Trace tools like explain_inclusion as a baseline

These aren't Memplex-specific. They're the patterns we think any production AI memory server has to support. The protocol gives us room. The question is whether the ecosystem uses it.