
The TL;DR
Prompt engineering optimizes a single instruction. Context engineering manages everything else the model sees, and MCP is becoming the protocol that delivers it.
-
• The Boundary Moved, Not the Skill
Writing a clear instruction still matters, but the job now spans everything an agent sees at every step, not just one prompt.
-
• MCP Is Becoming the Delivery Layer
Tools, memory, and retrieval used to mean custom integration work per data source. MCP delivers all three through one connection.
-
• A Stateless Spec Shipped July 28
MCP’s fourth spec revision since 2025 dropped session state from the protocol core, changing how context delivery scales in production.
MCP shipped three spec revisions in 2025 alone, and a fourth shipped July 28, 2026. The tool and memory layer sitting underneath every agent has needed that many changes just to keep up.
Prompt engineering and context engineering get treated as one upgrade, one term simply replacing the other, when they’re actually two different disciplines with two different failure modes. A well-worded prompt can still return a hallucinated answer, and an agent with clean, well-tested instructions can still lose track of what it was doing three tool calls into a task. Neither gets fixed by rewriting the prompt, because the prompt was never where the problem lived.
This piece covers what each discipline actually does, where prompt engineering runs out on its own, and how Model Context Protocol has become the layer that delivers tools, memory, and retrieval well enough to make context engineering possible at all.
What Is Prompt Engineering
Prompt engineering is the practice of writing and structuring instructions so a model produces a specific, reliable output. The skill lives entirely inside one exchange. Give a model a clear enough instruction, and assuming it already has what it needs to answer, prompt engineering alone gets the job done. That assumption is exactly where it runs out for agents, which need more than one exchange to finish a task.
The clearest evidence for why this works comes from a 2022 Google paper on chain-of-thought prompting. Asking a 540-billion-parameter model to write out its reasoning before answering, no retraining involved, pushed its accuracy on the GSM8K math benchmark past a version of GPT-3 that had been fine-tuned specifically for that task.
Quick facts
- Covers system prompts, few-shot examples, chain-of-thought framing, and output-format rules
- Few-shot prompting traces back to OpenAI’s 2020 GPT-3 paper, which showed a frozen model completing new tasks from a handful of in-prompt examples with no weight updates at all
- Stays highly effective for classification, extraction, and other bounded, well-scoped tasks
- Runs out once a task needs information the prompt itself can’t hold
What Is Context Engineering
Context engineering is the discipline of designing and managing everything a model sees before it responds, not just the instruction it’s given. That includes system instructions, tool definitions, retrieved documents, conversation history, and anything written to memory in an earlier step.
Anthropic’s applied AI team frames the underlying job as finding the smallest set of high-signal tokens that produces the outcome you want, not the largest set of possibly relevant ones. Context, in this framing, is a finite resource with the same kind of diminishing returns human working memory runs into.
Quick facts
- Named in June 2025, when Shopify’s CEO floated “context engineering” over “prompt engineering” and Andrej Karpathy amplified it days later
- Anthropic formally called it the natural progression of prompt engineering in a September 2025 engineering post
- 82% of 250 surveyed IT and data leaders said prompt engineering alone can no longer power production AI, per DataHub’s State of Context Management Report 2026
- 89% of the same group planned to invest in context management infrastructure within the next twelve months
Context Engineering vs Prompt Engineering
This comparison is based on three factors, how many model calls a task takes, whether anything needs to persist between those calls, and whether the model has to reach outside the conversation to finish the job. A single call with no external dependency stays solidly in prompt engineering territory. Add multiple turns, state that has to survive between them, or a tool call, and context engineering takes over.
| Comparison | Prompt Engineering | Context Engineering |
|---|---|---|
| Core question | How should this be phrased? | What does the model need to know? |
| Scope | One exchange | Every step an agent takes |
| Typical failure | Wrong tone, ignored instruction | Hallucination, stale data, broken tool calls |
| Where the work happens | The prompt text itself | System prompt, tools, memory, retrieval, and history |
| Standardized by | No shared protocol needed | MCP handles the tools and protocol layer |
| 2026 status | Still useful, now table stakes | The skill teams are hiring for and building infrastructure around |
Neither replaces the other. A sharp prompt still matters once the right context is assembled, it just stops being the whole job.
The Context Delivery Stack
Most of what context engineering touches falls into three parts, tools, memory, and retrieval. Call it the context delivery stack. MCP already shapes how the first one is delivered, and it’s starting to shape the other two.

Tools and Protocols
Before MCP, giving an agent access to five services meant writing five custom integrations, each with its own auth, error handling, and maintenance burden, the same tax teams have always paid connecting an agent straight to a traditional API. Model Context Protocol standardizes that into one protocol instead. A server exposes tools, resources, and prompt templates, and any client can discover and call them without hardcoded glue code.
The catch is scale. An agent connected to dozens of servers can end up with hundreds of tool definitions sitting in context before it does anything, working against the smallest-high-signal-set goal context engineering is supposed to serve. Teams manage that by starting with a shortlist of servers covering search, code execution, and file access rather than connecting everything the marketplace lists on day one.
Memory
MCP doesn’t define a memory primitive on its own. What it gives an agent is a way to call tools that read and write memory, which is a different thing. Anthropic’s own agents lean on structured note-taking for this, writing progress to a file outside the context window and reading it back after a summarization pass clears the conversation. Their Claude Playing Pokémon demo showed the pattern holding up over thousands of game steps, with the agent tracking training progress and map layouts it had never been told to record in any particular format.
Retrieval
Retrieval decides what gets pulled into context and when. Anthropic’s guidance favors a “just in time” approach for agents, where the model holds lightweight references such as file paths or stored queries and loads the full content only when a step actually needs it, rather than front-loading everything a task might touch. The tradeoff is speed, since a runtime lookup costs more time than data that was already sitting in context.
Getting retrieval wrong has a name now. Chroma’s research on context rot found that model accuracy degrades as input length grows, well before the context window is actually full, and that the pattern holds across every frontier model the study tested. A tightly curated context beats a large one stuffed with marginally relevant material almost every time.
MCP formally covers one of these three today. The table below shows where the other two currently get built instead.
How the July 2026 MCP Spec Changes Context Delivery
Three parts of the protocol change here. Session handling, tool list caching, and how extensions ship all shift at once.
| MCP Layer | Before 2026-07-28 | After 2026-07-28 |
|---|---|---|
| Session |
The initialize handshake plus an Mcp-Session-Id header pins a client to one server instance
|
Removed. Every request carries what it needs and can land on any instance |
| Tool list caching | No standard freshness signal |
tools/list results carry a ttlMs cache lifetime
|
| Extensions | Informal, no shared governance track | First-class, with MCP Apps and a redesigned Tasks system as the first two official extensions under the new framework |
MCP’s largest revision since launch shipped July 28, 2026. Every request now carries what it needs to be handled by any available server, so a gateway or provider can scale MCP traffic across ordinary load balancers instead of running sticky sessions and shared session stores. For context engineering, the practical effect is that the tool and protocol layer stops being the fragile part. That starts to matter once an agent calls a dozen tools per task instead of one, the kind of pressure that has driven every MCP revision since the protocol’s first stable release.

Nothing broke the moment it shipped. The deprecation policy guarantees a twelve-month window, and existing 2025-11-25 clients and servers keep working without changes. Still worth checking before you update.
- Built against the experimental Tasks API. That lifecycle moved into the new Tasks extension, where MCP Apps and Tasks now ship as the protocol’s first two official extensions, and tasks/list is gone entirely.
- Code matching on the -32002 error code. Missing-resource errors now return the standard JSON-RPC -32602 instead.
- Running a server behind sticky sessions. That infrastructure can simplify to a plain load balancer once targeting the new spec, though the move touches authorization, retries, and caching behavior worth testing before anything ships.
- Consuming servers through a client or gateway. Confirm which spec version it targets. Beta SDKs for Python, TypeScript, Go, and C# shipped June 29, 2026, ahead of the final spec, so testing against 2026-07-28 has been possible since before launch.
Manage AI Agent Context at Scale
Five patterns show up repeatedly once teams move past small demos, each fixing a different piece of the sprawl problem.
- Compaction: Anthropic’s Claude Code summarizes a conversation as it nears the context limit, keeps architectural decisions and open bugs, and drops redundant tool output before starting a fresh window with that summary in place.
- Write, select, compress, isolate: LangChain splits the job into four moves. Write saves context outside the window so it survives. Select pulls the right piece back in when a step needs it. Compress reduces what’s already in context to the tokens that still matter. Isolate keeps separate agents from stepping on each other’s context.
- Sub-agent architectures: Anthropic’s multi-agent research systems hand deep exploration to specialized sub-agents that each work with tens of thousands of tokens on their own, then return only a condensed summary, often 1,000 to 2,000 tokens, to the lead agent. The detailed search context stays isolated instead of piling into one shared window.
- Tool masking: Manus found that adding or removing tools mid-task breaks the KV-cache and leaves the model confused by tool definitions that were there one turn and gone the next. Their fix keeps the full tool set stable in context and masks which ones are selectable at each step instead, through a state machine that restricts choices during decoding rather than changing what’s available.
- Cache-aware design: Manus treats KV-cache hit rate as the single most important metric for a production agent, since the input-to-output token ratio in an agent loop runs around 100 to 1 for them. Keeping a stable prompt prefix, and appending rather than editing earlier context, keeps that cache warm. Cached tokens on Claude Sonnet run roughly a tenth the price of uncached ones, one piece of a wider shift toward cheaper models absorbing more tool calls per task without blowing through budget.
Which Approach Should You Choose?
The right starting point depends on what’s actually running today. Four scenarios cover most of it.
Solo Builders and Single-Turn Tools
A classifier, extractor, or content generator that answers from what’s already in the prompt doesn’t need a memory layer or tool orchestration.
- Sharpening the prompt itself, through few-shot examples and output constraints, is still the most effective fix here.
- Add context engineering discipline only once the task starts needing data the prompt can’t hold on its own.
Teams Building Multi-Step Agents
Once a task spans multiple tool calls, prompt quality stops being the bottleneck.
- Reach for compaction and structured note-taking before reaching for a bigger context window.
- Budget for context rot. A smaller, curated context reliably beats a larger, noisier one.
Teams Running Agents Against Many Tools and Services
Connecting a dozen services one at a time is the same integration burden covered above, and it only gets heavier as the list grows.
- The July 28 spec makes that kind of delivery scale the way ordinary web infrastructure already does, one gateway instead of a dozen one-off connections.
- MCP360 puts more than 100 of those services behind one API key, loaded on demand through search_tools and execute_tool instead of declared up front, so the next data source is a call away rather than another connector to build.
- That kind of shared layer becomes worth setting up once tool sprawl itself starts eating context budget rather than saving it, and the build rarely costs less than the buy once engineering time and upkeep get counted.
Frequently Asked Questions
What is context engineering?
Context engineering means managing everything a model sees before it responds, including system instructions, tool definitions, retrieved documents, conversation history, and memory. It covers the full working set an agent uses at each step.
How is context engineering different from prompt engineering?
Prompt engineering focuses on wording a single instruction so a model responds well in one exchange. Context engineering manages everything around that instruction across every step an agent takes. A weak prompt causes tone problems or a skipped instruction. A weak context causes hallucinations, stale data, or a broken tool call three steps into a task.
What changed in the MCP spec that shipped on July 28, 2026?
The July 28, 2026 update changes three parts of the protocol at once. It removes the old session handshake, adds a ttlMs cache lifetime to tool list results, and makes extensions official, with MCP Apps and a redesigned Tasks system as the first two. Existing 2025-11-25 servers and clients keep working through a twelve-month deprecation window.
Why did MCP remove session state from the protocol?
MCP dropped session state so any request can be handled by any available server instance instead of one pinned connection. A gateway can then route MCP traffic across ordinary load balancers instead of running sticky sessions.
Does MCP handle agent memory on its own?
No. MCP exposes memory only through custom tools that read and write it, but the protocol has no built-in memory primitive. Structured note-taking outside the context window, then reading it back later, is a common workaround.
What is context rot?
Context rot is the drop in model accuracy that happens as input length grows, even before the context window is full. It shows up across every major model tested, and a smaller, curated context usually beats a larger, noisier one.
How does MCP360 help avoid tool sprawl when connecting to many MCP servers?
Connecting to many MCP servers at once can pile hundreds of tool definitions into context before an agent does anything useful. MCP360 groups more than 100 tools behind one API key and loads them on demand through its search_tools and execute_tool meta-tools, so an agent only pulls in the specific tool a task actually needs.
When should a team move from prompt engineering to context engineering?
A single-turn task like classification or extraction, where the prompt already holds everything needed, is best solved with tighter wording and few-shot examples. Once an agent runs several tool calls per task or juggles multiple MCP servers, patterns like compaction and cache-aware design start to matter more than any prompt rewrite.
Conclusion
Agents are only going to call more tools, hold more memory, and run longer between human checkpoints. Every one of those steps adds another place for context to go stale, get lost, or crowd out what the model actually needed to see.
When an agent breaks, check the context before touching the prompt. Ask what the model actually saw at the moment it failed, and whether the tools, memory, or retrieval feeding it were the real point of failure. MCP makes that question answerable instead of a guessing game, and the July 28 spec just made the tool layer sturdy enough to stop being the thing that breaks first.
Start with the shortlist of servers a task actually needs, connect once, and let the next one get added without another integration to ship.
Article by
RajniAI & Tech | Senior Content Writer
Rajni is a senior content writer covering AI agents, automation, and no-code tools. She writes across the AI space, from chatbots and customer support to MCP and agent workflows, focused on how businesses actually put these tools to work.




