MCP-Injector — Protocol-aware fault injection — What does it mean?
The news. On October 23, 2026, researchers from the University of Luxembourg, Tilburg University, GSSI and the University of Naples posted a paper introducing MCP-Injector. They mined 57,240 issue and pull-request threads from 1,774 open-source MCP repositories to decide which faults to inject, then ran a 1,350-cell experiment. Read the paper →
Picture a chef who has only ever cooked with perfect deliveries. Every benchmark so far has been a day when the supplier arrives on time with the right boxes. MCP-Injector is a stand-in standing at the loading dock: the chef thinks it is talking to the supplier, the supplier thinks it is talking to the chef, and in between the stand-in can hold a box, swap its contents, or send nothing at all.
Technically it is a proxy on the MCP tool-call path. It acts as an MCP server toward the agent and as an MCP client toward the real server, so neither the agent nor the tools need to change, and one configuration flag turns it off. Each call passes four stages: it observes the tool name and arguments, decides which fault to apply from a seeded random stream, acts by forwarding the call and optionally mutating the response, and records a structured log entry. Timing faults and explicit errors are produced on the request side; content faults mutate the real answer on the way back. Because decisions come from a seed, the same schedule can be replayed against a different agent.
| Operator | Class | What the agent sees |
|---|---|---|
| Minor mistake | Content | The real answer with random characters replaced |
| Incorrect output | Content | A well-formed answer with words substituted |
| Invalid output | Content | A value coerced to the wrong type, for example a string where a number belongs |
| Explicit error | Content | An MCP error message instead of a result |
| Delayed response | Timing | The right answer after an artificial sleep (30 seconds in the paper) |
| Silent drop | Timing | No response at all: an indefinite hang |
The interesting design choice is where the fault mix comes from. Rather than hand-writing scenarios, the authors classified the mined threads by failure mode and by persistence. The resulting profile is permanent-heavy: about 91% permanent, 8% intermittent, and under 1% transient, with explicit errors alone making up 71% of injected faults and silent content errors another 19%. The authors call it a stress profile, not a production failure rate, because GitHub issues over-represent faults that are persistent and easy to reproduce. For the kitchen, that means the freezer is usually broken for the whole shift, not a single late truck.
| Persistence | Behavior at the tool-call boundary | Share of the paper's fault profile |
|---|---|---|
| Permanent | Fires on every matching call once activated | 91.3% (paper, stress profile) |
| Intermittent | Holds a faulty state for a random number of calls, then releases | 8.0% (paper, stress profile) |
| Transient | Fires on one call, then resets | 0.75% (paper, stress profile) |
Now the worked example, using the paper's numbers. Fix the benchmark (25 tasks from MCP-Bench, three seeds) and compare the same agents with and without faults. Task-completion score falls from 8.08 to 3.23 out of 10, so the average agent keeps 3.23 / 8.08, about 40%, of its fault-free quality. Most runs still finish: pooled completion falls only to roughly 91% to 96% depending on the model, so the damage is mostly a quality loss, not a crash. The paper reports that 56% of faulted runs were partially degraded: the chef serves a dish, but a poorer one. Restricted to runs that completed under both conditions, the drop is still 57%.
A second calculation shows why retries are a weak defense here. In the paper's profile, only the transient and intermittent entries (roughly 9 of every 100 injected faults) can plausibly clear on a second attempt; the other 91 are permanent, where a retry meets the same broken freezer. (This is our inference from the persistence mix, not a measurement in the paper.)
The headline result is about scale. The 120B backbone completed fewer faulted tasks than the 20B one: 91.1% versus 95.6%. Decomposed, half of that 4.4-point gap is already there without faults (96.9% versus 99.1%, a 2.2-point gap), and the other half is a larger fault-attributable drop (5.8 points versus 3.6). The model-size effect on the resilience ratio is indistinguishable from zero (p = 0.96), though the confidence interval is wide, so this shows no detectable resilience benefit from scale for these two gpt-oss models, not proof that scale never helps.
The agent stack mattered more, with a caveat. LangChain had the highest faulted completion (95% to 97%) and OpenAI Agents SDK the lowest (88% to 95%). After a failure, the custom MCPBench planner tended to switch to a different tool, while the LangChain and OpenAI loops tended to fall back and stop calling tools. The authors call the stack effect suggestive, because the intervals nearly touch zero and no multiplicity correction was applied. The practical reading is that how the framework hands a tool error back to the model may matter at least as much as how large the model is.
Goes deeper in: AI Agents → Tool Use & Function Calling → MCP, Two Ways
Related explainers
- MCPEvol-Bench — another way MCP tools break an agent: the interface changes underneath it
- Measuring this in production belongs with online vs offline evals, and responding to it with the first 15 minutes of an incident