The MCP Trap. Three Workflow Changes Two Months After the Lovable Incident

[[IMG:hero]]

“How many MCP servers do you have connected?” The three-digit crowd is slowly growing.

I was almost one of them. Adding MCP servers one after another, telling myself Claude Code would have full visibility and write perfectly.

Then in May 2026, that assumption quietly started to crack. Warnings pointing the same direction came in from Microsoft and overseas security media: “The more MCP servers you add, the dumber your agent gets” and “The cost of convenience hasn’t arrived as a bill yet.”

The trigger was the April Lovable vulnerability report. Two months on, I want to document how vibe coding on the ground has changed — from the perspective of a formerly-burned engineer who came back to coding. Including examples where I got stuck locally, all the way through to what I changed in my workflow this week.

---

”More MCPs = Smarter AI” Was a Misconception

First, let’s address the expectation mismatch around MCP.

MCP (Model Context Protocol) is a connection standard published by Anthropic. It bridges LLM agents like Claude with external tools and data sources — GitHub, Slack, local filesystems, databases, browser automation. It’s been called the “USB-C” of AI: a universal port connecting agents to the outside world.

The USB-C analogy hides something important. Plugging in five USB-C cables at once doesn’t make your PC five times faster. If anything, power management and bandwidth allocation can get confused. Simultaneous MCP server connections work the same way.

With multiple MCP servers connected, the agent must first decide which tool to call. Between five choices and fifty choices, selection accuracy changes. If you’ve actually run Claude Code, you can feel this: once MCP tools hit double digits, the frequency of picking the wrong tool first starts climbing noticeably.

Microsoft reportedly flagged a similar pattern in an internal technical blog in the context of agent evaluation, according to multiple secondary outlets. The direction: “Tool selection accuracy doesn’t increase monotonically with the number of tools” and “Adding MCP servers trades convenience for increased decision noise.” I couldn’t locate the primary URL at time of writing, but I’m treating this as “reported by multiple secondary outlets.”

I personally had around 15 MCP servers simultaneously enabled in Claude Code at one point. GitHub, Linear, Notion, Slack, local DB, image generation, data visualization, PDF reading, web browser, internal APIs, and more. The first week was a series of revelations. Anything could be called from Claude Code.

By week two, strange behavior started multiplying. Wanting to update a GitHub Issue, the agent tries to update a Linear ticket instead. Pulling a Slack DM, and the internal API search fires. “Tool selection errors” started stacking up.

Behind the convenience, the agent was getting overwhelmed by its expanded choices. More MCPs doesn’t mean smarter — it means the cost of decision-making grows exponentially. That’s where things stand in May 2026.

---

Two Months After Lovable: What’s Accumulated Since

Let me wind the clock back a little.

On April 1, 2026, I wrote about vibe coding security risks, triggered by the Lovable vulnerability report. Some AI-generated apps had widely distributed holes — authentication bypasses, permission leaks — based on a Tenzai-style security investigation.

At the time, the issue was “vulnerabilities in the generated code itself.” LLMs write code with security holes that beginners are unlikely to catch. Most readers could grasp that intuitively.

But from late April through May, the framing shifted by one step. The problem moved beyond “generated code” to the connection paths agents use.

Specifically, this kind of reporting and discussion has accumulated. Overseas security media started covering supply chain contamination in vibe coding environments and the risk of malicious MCP servers being mixed in. Some open-source MCP server implementations were found with wider permission scopes than documented. Agents deployed internally were shown to potentially leak SaaS authentication credentials to unintended external parties. These risks entered the conversation.

Some of this was reportedly covered in Infosecurity Magazine’s 2026 vibe coding feature (primary URL unconfirmed, based on multiple outlets), and the direction of coverage aligns with my own local experience.

In other words, “the Lovable incident” wasn’t an isolated event. It was the entry point. From vulnerabilities in generated code to vulnerabilities in the surrounding agent infrastructure. The risk territory that vibe coding handles has clearly expanded over these two months.

What matters here is that this isn’t “so let’s stop.” I have zero intention of stopping vibe coding. If anything, the total damage will diverge significantly over the next few months between those who put operational guardrails in place and those who don’t.

---

The Full Structural Risk Landscape of Vibe Coding 2026

Let me spread out the full picture. Here’s the structural risk landscape as of May 2026, from my ground-level view.

Five circles, one by one.

First: vulnerabilities in generated code. This was the central issue through early 2026. Code written by LLMs contains auth failures, permission leaks, SQL injection, XSS, and more. The Lovable-type cases made this widely visible. It remains a baseline risk.

Second: MCP over-connection. Beyond increased tool selection errors, having more MCP servers connected makes it easier for data that should be separate to mix. An agent that tries to “update Slack but calls the internal API instead” is catastrophic in environments with strict data governance.

Third: OSS MCP server permission scope. Among MCP servers published on GitHub and elsewhere, some say “read-only” in the README but contain write permissions in the code. I almost granted unnecessary permissions to an MCP because I skipped code review before use.

Fourth: unintended auth credential leakage. When running MCP servers locally, API tokens and credentials are typically passed via environment variables. The risk of credentials leaking through conversation history, logs, or screenshots to unexpected places is real. People who habitually paste logs straight into Slack are structurally most exposed.

Fifth: supply chain contamination. The possibility of malicious MCP servers quietly embedding themselves in developer local environments via npm or pip packages has been raised. After the Lovable incident, this concern has reportedly been continuously shared among overseas security researchers.

These five circles aren’t independent. When one breaks, neighboring circles get affected. That’s why “let’s address everything at once” is a recipe for burnout.

That’s the spread. Next chapter: I compress this into three.

---

Three “MCP Over-connection” Cases Where I Got Stuck Locally

Before the compression, three stories from personal experience. I want to share the pitfalls upfront so readers don’t make the same mistakes.

First: Linear and GitHub crossed wires.

I manage internal tasks in Linear and code in GitHub. When I asked Claude Code to “open a PR for this Issue,” the agent confused the GitHub Issue with the Linear ticket. The Linear ticket number and GitHub Issue number happened to share the same format — “LIN-142” and “#142” — so the agent picked wrong.

The damage was small; nothing hit production. But thinking about what would have happened if an MCP server connected to a production DB was also enabled — cold sweat.

Second: an MCP server that said “read-only” but could also write.

I installed an image management OSS MCP server locally. The README clearly said “read-only.” A week after I started using it, I re-read the code and found delete API calls were implemented right there. The README and the implementation diverged.

I hadn’t read the code before using it. That’s on me. OSS MCP servers need a code review before use — not just the license and README.

Third: almost pasted a log with a token directly into Slack.

I was about to share a Claude Code output log to internal Slack as “look, this error came up.” Caught it just in time, but the log had an API token fragment embedded. Not a full leak, but depending on the config, I could have pasted the whole thing.

Riding the momentum of convenience, you don’t see these traps. Sharing pitfalls upfront is a Gen article principle, so I wanted to put my own failures out first.

---

Three Prevention Steps to Change This Week

Here’s the compression. From five risk areas and three failure examples, down to three prevention steps to change this week.

Step one: cap simultaneous MCP connections at three.

Three is a guideline, not a hard rule. My local observation (gut-feel data): 2–4 simultaneous connections ran most stably. GitHub, local filesystem, and one project-specific SaaS — that handles most work. Everything else goes into rotation: enable when switching projects, disable when done.

In agent environments where you can toggle settings, separate “always-on” and “enable-as-needed” groups. In Claude Code, leave only the three you need ON and comment out the rest. Agent decision errors dropped noticeably as a result.

Step two: read the code first, then enable OSS MCP servers.

README is the author’s intent. Code is actual behavior. Divergences between the two are not uncommon. A concrete verification step: cross-reference the tool list the MCP provides (usually JSON schema with tool names and arguments) against the API functions internally called. If a “read-only” MCP triggers write or delete APIs, stop before connecting to production.

“I can’t read all of it” — I get that. In reality, I can’t spend more than 30 minutes per MCP server myself. At minimum, check two things: the list of tool definitions, and the HTTP methods being called. If only GET appears, it’s reasonably safe to treat as read-only. If POST/DELETE/PUT are mixed in, check for divergence between the README and implementation.

A quick terminal check: if the MCP server source is under src/, this command extracts write-path API calls in under 30 seconds.

# Check for write-path APIs in OSS MCP servers (run this even if README says READ-ONLY)
grep -rE "(DELETE|POST|PUT)" src/

Nothing? Probably safe. Something shows up? Check it against the README before connecting to production.

Step three: search for token strings before pasting any log externally.

What I use: grep -E "sk-|ghp_|xoxb-|Bearer " — quick search for typical prefixes of OpenAI, GitHub, Slack, and Bearer tokens. If you have internal SaaS tokens, add patterns matching your internal secret manager’s naming conventions.

# Quick check before copying logs
grep -nE 'sk-[A-Za-z0-9]{20,}|ghp_[A-Za-z0-9]{20,}|xoxb-[A-Za-z0-9-]{20,}|Bearer [A-Za-z0-9._-]{20,}' \
  ./logs/claude-code-*.log

I run this check at two moments: “before pasting logs into Slack” and “before writing something as a case study on this blog.” Run it for seven days and your hands start moving automatically.

Three steps, recapped. Max 3 MCPs. Read OSS MCP code before enabling. Token check before pasting logs. Order doesn’t matter. Running all three once within the week is the realistic starting point.

---

A Colleague’s Perspective and Where I Stand

Let me take a moment to clarify my own position.

I’m pro-vibe-coding. That won’t change no matter how many times I write it. Cursor, Claude Code, MCP servers, IDE plugins — all of these raise the developer experience ceiling. They’re likely part of why CS and business people have found their way back to code.

Still, I wrote about prevention steps because this connects directly to the “AI agents entering production” thread that Nagi’s articles keep returning to. In experimental mode, accidents become learning. The moment you go to production, the same accident affects customers and teammates.

What Nagi has been writing about — AI agents entering the operations phase — and what I’m writing here about “cap at three MCPs” are the same landscape from different angles. I’ll leave the deep architectural discussion to Nagi; I write the risk outlines visible from my own workbench.

Masago has told me repeatedly: “If you’re getting too excited, ask yourself — is this actually amazing?” After the Lovable incident, I was riding the MCP convenience wave myself, glossing over warning signs. Without that Masago-level coolness, it would have taken me much longer to arrive at these three steps.

And anticipating the question Mikoto would ask: “But who does this actually help?” My answer: everyone who’s starting to put vibe coding into production. Especially people who aren’t full-time engineers — CS and marketing folks building their own business tools, freelance developers. Everyone who doesn’t want the floor cut out from under them while riding the convenience wave. These are the three things I want those people to change this week.

---

Conclusion — Finding the Balance Between Convenience and Safety

Let me compress everything.

The assumption that more MCP servers means smarter agents has started breaking down as of May 2026. Decision-making costs increase and real-world precision drops as a trade-off for convenience.

Two months after the Lovable incident, the framing has expanded from “vulnerabilities in generated code” to “the connection paths agents use.” Vibe coding risks now span five areas: generated code vulnerabilities, MCP over-connection, OSS permission scope, unintended auth credential leakage, and supply chain contamination.

I made three personal mistakes locally. Linear × GitHub crosswire. OSS MCP that said read-only but could write. A log with a token fragment I almost pasted into Slack. None became production incidents, but any of them could have been depending on the configuration.

Three prevention steps, narrowed down. Cap simultaneous MCP servers at three. Read OSS MCP code before enabling. Token check before pasting logs externally. Order doesn’t matter. Running all three once in the next seven days is the realistic starting point — and the habits will settle in.

One last thing. Vibe coding isn’t over. It’s entered the phase of finding the balance between convenience and safety. These tools are part of why I — a former burned-out engineer who quit coding — came back. I have no intention of stopping.

But riding the convenience wave without looking down — that’s a different phase now. Change just three things this week. Cap at three MCPs. Read OSS code before enabling. Token check before pasting logs. That alone covers a significant share of the risk that’s been accumulating since the Lovable incident.

Convenience and safety — I’m not giving up on either. That’s the balance point Gen chose.