Basalt Studio logo
Basalt Studio.Basalt Studio.
Back

MCP will be the death of low-code automation, and other spooky stories

Eliott Ardisson

Eliott Ardisson

Founder & CEO - Basalt Studio

Updated
insights

MCP promises to reshape how AI agents connect to business systems — but is it ready to replace low-code automation, or just the latest infrastructure hype?

ai agents
automation
programmatic

TL;DR

  • MCP (Model Context Protocol) standardizes how AI agents connect to external systems, potentially reducing reliance on middleware-heavy low-code platforms — but it is not a replacement for them today.
  • Security vulnerabilities in early MCP implementations are real and documented: command injection, path traversal, and SSRF flaws appear across a meaningful share of tested servers.
  • Token costs in MCP-driven agents can spiral fast. Naive implementations pull far more data than needed, and the billing consequences are significant.
  • Low-code platforms like n8n are absorbing MCP as a capability, not being killed by it. The hybrid approach is where most practical automation is headed.
  • For most founder-led SMBs, the right move right now is a targeted hybrid strategy — deterministic automation for predictable workflows, MCP agents for complex, context-dependent ones.

What MCP Actually Is (And What It Isn’t)

The Model Context Protocol is a standardized communication layer that lets AI agents interact with external systems — databases, SaaS tools, internal APIs — through a consistent interface rather than custom-built connectors.

The most accessible analogy is USB-C for AI systems. Before USB-C, every device manufacturer had its own port and cable standard. MCP proposes something similar for AI-to-system communication: one protocol, many compatible endpoints. An AI agent built on this standard can call a calendar tool, a CRM, and a document store using the same underlying mechanism — without each integration being hand-coded.

The protocol separates into three functional layers:

  • Resources: read access to data — files, database records, API responses
  • Tools: write operations the agent can perform — sending a message, updating a record, triggering a process
  • Prompts: reusable instruction templates for common tasks

Anthropic introduced the spec in late 2024, and OpenAI’s subsequent signal of support caused adoption to accelerate quickly. That acceleration is part of why we’re having this conversation at all — the ecosystem moved fast, and fast-moving ecosystems accumulate debt.

What MCP is not: a fully production-hardened, enterprise-grade standard. Not yet. Understanding that distinction matters before you start reorganizing your automation stack around it.


Why Low-Code Platforms Actually Have Something to Worry About

Let’s steelman the “death of low-code” thesis before we take it apart.

Visual workflow builders — tools like n8n, Make, and Zapier — built their value proposition on abstraction. They handle API authentication, data formatting, error retries, and webhook management so that operations teams don’t need to write code. For a recruitment agency wanting to push new applicants from a web form into their ATS and trigger a Slack notification, this is exactly right. The workflow is linear, predictable, and doesn’t require judgment.

MCP threatens this model in specific ways. If an AI agent can hold a natural-language goal in mind — “whenever we receive a new inbound lead, qualify it against our ICP, check if we have any existing contact history, and draft a personalized first-touch email for the sales rep to review” — and execute that across three systems using MCP tool calls, that’s not a workflow a visual builder handles well. It requires context, branching logic, and interpretation. The visual builder breaks or becomes a sprawling 40-node flow that one person understands.

More fundamentally, MCP decouples the intelligence layer from the integration layer. Low-code platforms are both at once: they are the logic and the connectivity. If the logic migrates to a language model and the connectivity migrates to MCP servers, the platform in the middle becomes structurally redundant for a meaningful class of use cases.

That is a real competitive threat. It is not, however, the whole picture.


The Security Problems Are Not Theoretical

One of the underreported dimensions of the MCP conversation is how compromised the early implementation landscape looks from a security standpoint.

Independent security research published in early 2025 identified command injection vulnerabilities in a significant proportion of tested MCP server implementations. Path traversal flaws — where an agent’s file access isn’t properly scoped — and Server-Side Request Forgery vulnerabilities, which can be used to probe internal network infrastructure, appeared across a substantial share of servers as well.

These are not exotic attack vectors. Command injection and SSRF are on the OWASP Top Ten. They appear in MCP implementations not because the protocol itself is inherently broken, but because:

  1. The protocol prioritized functionality in its first release cycle, with security patterns following behind
  2. Many MCP servers were built by developers rushing to ship before the ecosystem froze around other approaches
  3. Authentication and authorization mechanisms vary significantly across vendor implementations, creating inconsistent security postures

There’s a structural irony here that practitioners have already noticed. When your MCP agent needs to reach a sensitive internal API, the pragmatic mitigation is to put an API gateway in front of your MCP server — precisely the middleware abstraction the protocol was meant to eliminate.

For SMBs operating in regulated verticals — accounting practices, legal firms, HR agencies handling personal data — this is not an academic concern. Before deploying MCP agents against systems that touch client data, a proper security review of every server in the chain is necessary work, not optional due diligence.


Token Costs: The Bill You Didn’t Model

The economics of MCP-driven automation are meaningfully different from traditional workflow automation, and not always in a favorable direction.

Traditional low-code automation has largely predictable costs. You pay per task execution or per workflow run. The cost scales linearly with volume and is easy to budget.

MCP-based AI agents introduce token consumption as a core cost driver, and token costs compound in ways that are non-obvious until you’re looking at an invoice.

Consider a straightforward scenario: a legal firm deploys an MCP agent to handle intake qualification. A prospective client submits a query, the agent retrieves the firm’s matter history from a document store, checks conflict-of-interest records, assesses the query against practice area criteria, and drafts a response for the attorney to review.

If the document retrieval is poorly scoped — pulling full case files instead of targeted summaries — the context window fills with data the model doesn’t need. If the model reasons through multiple approaches before settling on one, those intermediate tokens are billed even though they’re invisible to the end user. If the agent makes five tool calls in sequence and passes growing context forward with each one, the token count multiplies.

In our work helping founder-led businesses scope MCP deployments, the single most common issue we see at the architecture stage is underestimating data retrieval scope. The agent asks for “all relevant records” and the MCP server obliges. Building hard retrieval limits, semantic search ahead of raw retrieval, and output caching into the agent architecture isn’t optional — it’s the difference between a workflow that costs a few cents per run and one that costs dollars.

McKinsey research on AI adoption in SMBs consistently flags cost governance as a top operational challenge once initial pilots move toward scale. MCP amplifies this dynamic because the cost is less visible than traditional SaaS subscription fees.


Low-Code Is Adapting, Not Dying

The “MCP kills low-code” framing makes for a good headline, but the actual market behavior tells a different story.

n8n, which is widely deployed in the SMB and technical user market, has shipped MCP support as an extension of its existing node-based architecture. This isn’t surrender — it’s a sensible read of where the market is heading. n8n is positioning itself as the orchestration layer that can run both deterministic workflows and MCP-connected agents from a single environment. That’s a viable product position.

The underlying logic is sound. Not every business process benefits from AI reasoning. A high-volume process — nightly invoice exports, automated appointment reminders, lead routing by geography — runs faster, cheaper, and more reliably as a traditional automation. The value of deterministic behavior in these contexts isn’t a limitation to be engineered around; it’s the point.

MCP adds genuine value in a different class of problems:

  • Workflows with high exception rates that require interpretation rather than rule lookup
  • Cross-system orchestration where the right action depends on context from multiple sources
  • User-facing processes where natural language interaction improves adoption
  • Decision-support tasks where the output is a recommendation, not a transaction

Framing the choice as MCP versus low-code automation misses the more useful question: which workflows in your operation fall into which category? For most founder-led SMBs, the honest answer is that most of their automatable processes are closer to the deterministic end, with a subset of high-value, complex workflows that would genuinely benefit from an AI agent layer.


What Production Readiness Actually Looks Like Right Now

If you’re evaluating MCP for a live deployment today, here is a clear-eyed assessment of what you’re working with.

The protocol is still maturing. Vendor implementations are inconsistent, which means an MCP server that works correctly with one client may behave differently with another. Debugging tooling is thin — when a traditional n8n workflow fails, the error log tells you exactly which node broke and why. When an MCP agent fails, the failure is often opaque, and diagnosing it requires understanding both the model’s reasoning and the server’s response schema.

The vendor ecosystem, while growing fast, is not yet close to the breadth of integrations available in mature automation platforms. For common tools — CRMs, email, calendars, document stores — MCP server coverage is reasonable. For vertical-specific software used in HVAC, legal, or property management, coverage is thin or nonexistent.

Skills requirements are also genuinely elevated. Deploying a reliable MCP agent in production requires understanding prompt engineering, tool schema design, retrieval architecture, cost controls, and security scoping simultaneously. This is not a profile that exists organically in most SMB teams.

None of this means MCP is not worth engaging with. It means the realistic deployment horizon for production-grade, business-critical MCP agents is somewhere in the 12-to-24-month range for most organizations, not immediate.


A Practical Framework for Deciding What to Build

The right mental model isn’t “adopt MCP” or “stay with low-code.” It’s a routing decision you make workflow by workflow.

Characteristics that point toward traditional automation:

  • High volume, low variability (hundreds of runs per day, mostly identical)
  • Strict audit trail requirements — regulated industries, financial processes
  • Latency sensitivity — sub-second execution matters
  • Cost predictability is a hard requirement
  • The logic is fully specifiable in advance

Characteristics that point toward an MCP agent:

  • The workflow requires reading context from multiple sources before deciding what to do
  • Exception handling makes up a large share of actual processing time
  • The business logic changes frequently enough that maintaining rule-based workflows is expensive
  • The output is a judgment or draft, not a deterministic transaction

Characteristics that point toward a hybrid:

  • You have both types of processes and want a single environment to manage them
  • You want to pilot AI agent capabilities without replacing proven automation
  • Your team is learning the operational patterns of AI agents before committing fully

In our work at Basalt Studio helping founder-led firms implement automation, the most consistent finding is that the hybrid approach carries the lowest deployment risk. It lets teams build intuition for where AI agents add real value before reorganizing their entire stack around an immature protocol.


Where MCP Is Likely Headed

The honest forecast is that MCP will matter significantly — just not on the timeline the hype cycle implies.

As the protocol stabilizes and security standards consolidate, the developer experience will improve. Tooling for debugging, monitoring, and cost governance will follow adoption. Industry-specific MCP server libraries will emerge for verticals like legal, real estate, and professional services. And AI platforms will increasingly abstract away the raw protocol, the way cloud providers abstracted away bare metal infrastructure.

The organizations best positioned to benefit will be those that spend the next twelve months building operational intuition — understanding which of their processes are genuinely amenable to agent-based automation, building internal capability around prompt design and cost governance, and making targeted pilots rather than wholesale migrations.

MCP will not kill low-code automation. It will, over time, reshape what low-code platforms are built to do. That’s a meaningful shift, but it’s a transition, not a cliff edge.


If you’re trying to figure out where MCP fits in your automation roadmap — or whether it does at all — a focused strategy conversation is usually the fastest way to cut through the noise. Book an AI strategy call and we can work through your specific workflows and what actually makes sense to build right now.