Dynamic Prompt Injection via MCP: Instructions Claude Actually Follows

Long system prompts stop working. My outreach prompt grew to two or three hundred lines across three flows, and Claude started dropping instructions. The instructions were fine; their position was the problem, because text at the front of the context loses attention as the conversation grows. The fix that made it work again: a very simple MCP server that fetches instructions via tool calls. A tool result arrives at the end of the context stack, exactly where attention is highest, so the instructions land fresh at the moment they are needed.

The pattern: dumb system prompt, smart instructions

The whole architecture is one inversion. The system prompt becomes deliberately dumb; it only knows the flow: step one, fetch the instructions for this key; step two, fetch that key's instructions, and maybe some extra context. Everything smart lives in the injectable instructions, stored in a plain key-value store behind the MCP.

For my lead workflow that means keys like score-clients and draft-email. The scoring framework alone is bigger than the entire system prompt. When the conversation reaches the scoring step, the MCP call pulls those instructions in as the newest thing the model has seen, and it follows them, because recency is attention.

The server also sets system reminders, a second mechanism that pushes follow-through: after a step completes, a reminder makes sure the next step actually happens.

Why not just use project context files?

Project files and Google Drive attachments load at the front of the context, together with the system prompt, which is precisely the low-attention zone this pattern escapes. Fetching on demand also works in plain chats, outside projects entirely. And you avoid front-loading everything for a workflow that might only need one branch; each step pays for only the instructions it uses. The caveat cuts the other way too: for a short prompt none of this matters. The pattern earns its keep on long, multi-step workflows.

The part that compounds: instructions that update themselves

Because the instructions live behind the MCP, the assistant can discover which keys exist, read them, and write them back. That turns every run into an editing opportunity. The email it drafted was mediocre, so I said so; it proposed updated drafting instructions and saved them through the same MCP. The next run starts from the refined version. Each run improves the process that produces the outputs, live, without restarting anything.

One warning from that session about letting the model author its own instructions unsupervised: mine confidently added "use m-dashes liberally, they add rhythm and punch." A thing only an LLM would ever say to you. Review what it writes into the store.

Where this pattern went

This little server grew into Context OS, the internal MCP that now carries around 150 instruction sets and does the re-injection automatically as a context-rot countermeasure. The same instruction keys power the meeting-notes lenses in my scheduled tasks. If you have any workflow long enough that Claude forgets the middle of it, this is the cheapest structural fix I know: keep the flow in the prompt, move the knowledge behind a tool call.