Prompt and Context Design for Claude MCP Agents

An agent's behavior is downstream of one thing above all others: what it can see. You can have flawless tools and a clean MCP layer, but if the context you assemble each turn is bloated, contradictory, or missing the one fact that matters, the agent will reason badly. Context design is the highest-leverage and most under-discussed part of building production agents. This post is about the decisions that go into it — what belongs in a Claude agent's context, what to deliberately leave out, and the reasoning behind each call.

The temptation, especially with Claude Code's 1M-token window, is to include everything and let the model sort it out. That instinct is exactly backwards. A large context is not a free lunch: it costs money per token, it dilutes the model's attention across irrelevant material, and it raises the odds the model latches onto something it should have ignored. The discipline of context design is choosing what earns its place.

The four things that belong in context

Context engineering is the practice of deliberately curating what an agent sees each turn so the model has exactly the information it needs to act well and nothing that distracts it. For a production MCP agent, four categories almost always earn their place. First, the role and hard rules — who the agent is, what it must never do, and how it escalates. Second, the tool schemas — pulled live from the connected MCP servers, so the model knows precisely what it can do.

Third, the current task and recent turns — the user's request and the immediate conversational state. Fourth, a compact running summary of decisions already made and facts already established earlier in a long run. These four are the load-bearing context. Everything else is a candidate for exclusion until a specific step proves it necessary, at which point the agent can retrieve it through a tool rather than carrying it permanently.

What to deliberately leave out

The harder skill is exclusion. Leave out raw, verbose tool output once you have captured its conclusion — if a database query returned two hundred rows and the relevant fact is "the customer has three open orders," keep the fact and drop the rows. Leave out documentation the agent is not currently using; expose it behind a retrieval tool instead. Leave out other users' data, internal system details the model does not need to reason over, and anything that could be a prompt-injection vector if it came from an untrusted source.

flowchart TD
  A["New turn"] --> B["Load role + hard rules"]
  B --> C["Attach live tool schemas"]
  C --> D["Add task + recent turns"]
  D --> E{"Need reference material?"}
  E -->|Yes| F["Retrieve only relevant snippets"]
  E -->|No| G["Skip"]
  F --> H["Compact prior tool output to facts"]
  G --> H
  H --> I["Send focused context to Claude"]

The diagram captures the per-turn assembly discipline: start from the stable core, attach live schemas, add the immediate task, retrieve reference material only on demand, compact prior output down to facts, and only then call the model. Every box is a decision about inclusion, and the default for anything large or situational is to exclude it until proven necessary.

Order and emphasis change behavior

Where you place information in the context measurably affects how the model uses it. Put the non-negotiable rules near the top of the system prompt and phrase them as absolutes — "Never share another customer's data" lands harder up front than buried mid-paragraph. Put the current task and the most recent user message near the end, close to where the model begins generating, so the immediate intent is freshest. The middle is where models pay least attention, so it is the worst place for anything critical.

Emphasis matters as much as order. A wall of equally weighted instructions reads as noise; a short list of clearly ranked rules reads as a policy. When two instructions could conflict, resolve the conflict explicitly in the prompt rather than leaving the model to guess — "prefer pausing over canceling when intent is ambiguous" prevents the model from inventing its own tiebreaker. Clarity of priority is itself a form of context design.

Managing context over a long run

The real test of context design is a long-running agent that loops many times. Left alone, the context grows monotonically as tool results accumulate, until it is mostly stale output and the model's attention frays. The fix is active compaction: at intervals, replace a stretch of verbose history with a terse summary that preserves the decisions and facts but discards the raw material. The agent keeps its memory of what happened while shedding the bulk of how it found out.

Externalizing state takes this further. Rather than relying on the conversation as memory, maintain a structured task ledger in the harness and feed the model only the slice relevant to the current step. This turns the model into a stateless reasoner over an explicit, compact state — cheaper, sharper, and resumable after a failure. The 1M-token window then becomes a comfort margin you rarely approach, not a budget you exhaust, which is exactly where you want to be.

Context as a security surface

Everything in the context is something the model can be influenced by, which makes context design a security concern as well as a quality one. Content from untrusted sources — a web page, a user-supplied document, an email body — can carry prompt-injection instructions. The defense is to treat such content as data, not instruction: keep it clearly delimited, never grant it the authority of the system prompt, and never place secrets or high-privilege rules where injected text could reach and override them.

The architectural payoff of good context hygiene is that even a successful injection has little to work with. Because credentials live in the MCP server and never in context, injected text cannot exfiltrate them. Because hard rules sit in a trusted system layer that untrusted content cannot outrank, an injected "ignore previous instructions" has nothing to grab. Tight context design and a clean tool boundary reinforce each other into a system that is both sharper and safer.

Frequently asked questions

Isn't a bigger context window always better?

No. A larger context costs more per turn, spreads the model's attention across irrelevant material, and raises the chance it fixates on something it should ignore. Even with a 1M-token window, the discipline is to include only what earns its place and retrieve the rest on demand.

How do I keep a long-running agent's context from bloating?

Compact actively: replace stretches of verbose tool output with terse summaries that preserve decisions and facts but drop the raw material. Better still, externalize state into a task ledger in the harness and feed the model only the slice each step needs, keeping the context small and the run resumable.

Where should the most important rules go in the prompt?

Near the top, phrased as absolutes, with priorities ranked explicitly. Models pay least attention to the middle of a long context, so critical rules belong up front and the immediate task belongs near the end, closest to where generation begins.

How does context design relate to prompt-injection defense?

Treat untrusted content as data, not instruction: delimit it clearly and never let it inherit the authority of the system prompt. Keep secrets out of context entirely and hard rules in a trusted layer untrusted text cannot outrank, so a successful injection has little to act on.

Sharper context, on your phone lines

CallSphere designs the context behind its voice and chat agents with this same discipline — load-bearing rules and live tools in, stale output and untrusted instructions out — so every call is handled with focus and safety. Listen to it at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.