When Not to Choose MCPs
It’s easy to be seduced by the elegance of MCPs. They promise structure where there is mess, consistency where there is drift, and portability where there is lock-in. But there are moments where choosing MCPs is not just overkill—it can actively slow you down.
This is a discussion about those moments, and about balancing the reality of what works today against the lure of what could be.
The Case for Keeping What Works
Sometimes duct tape is enough. If you are:
- Building an MVP to test user appetite,
- Running a single agent on a single data source,
- Pivoting fast and discarding experiments weekly,
then MCPs are overhead. Writing schemas, adapters, and governance rules adds drag when the only thing that matters is proving the idea.
A brittle integration that delivers a demo tomorrow is worth more than a protocol that delays feedback by a month.
In practice: A real estate wholesaler doesn’t care whether your AI platform speaks MCP. They care that they can see tax liens by Friday. At that stage, speed beats elegance.
The Case for Planning What Could Be
At the same time, ignoring MCPs entirely comes at a cost. If you:
- Expect to scale across multiple tenants,
- Have more than one agent reading the same source,
- Need to prove reliability to enterprise buyers,
then MCPs stop being an indulgence and start being a necessity. Without them, every connector becomes a silo. When the business asks you to scale, you will pay the debt all at once.
In practice: A portfolio investor with 10,000 properties across three states will demand consistency. If one agent interprets “Lien Amount” differently than another, your credibility crumbles. At that stage, structure beats speed.
The Middle Path
Most teams live somewhere in between. The trick is to stage the adoption:
- Prototype Phase
Use direct integrations. Move fast. Discard liberally. - Stabilization Phase
Once two or more agents need the same context, introduce a lightweight schema—not a full MCP, just enough to reduce duplication. - Scaling Phase
As integrations multiply and orchestration becomes central, formalize into MCPs. Make protocols part of the platform, not the experiment.
This approach respects what works without pretending that duct tape will scale forever.
The Reality Check
- What Works Now: Quick scripts, brittle connectors, hard-coded prompts. Perfect for demos, dangerous for scale.
- What Could Be: Formal protocols, reusable adapters, portable agents. Perfect for scale, dangerous for early momentum.
The art is knowing when the shift is worth it.
Closing Thought
MCPs are not inherently good or bad. They are a tool, and like all tools, they have an opportunity cost.
The worst outcome is not skipping MCPs; it’s committing to them too early, freezing abstractions before you understand the domain. Equally, the worst outcome is not that you used duct tape; it’s that you never knew when to replace it.
Choose MCPs when the pain of not having them outweighs the cost of building them. Until then, keep what works.