The New Shiny Thing: Why Claude + MCP Isn't the Architecture Your Business Needs

A friend excitedly told me earlier this week that he'd just connected Claude to his Shopify store using MCP — Anthropic's Model Context Protocol — and the agent could discover tools and automate real workflows without writing custom integration code.

And honestly, it does feel like magic. That's exactly the problem.

After implementing AI automations for clients across manufacturing, insurance, and financial services, I've learned that "feels like magic" is the most expensive phrase in technology. Magic means you don't understand the cost structure. And what you don't understand, you can't control.

What MCP Actually Does Under the Hood

Let me explain what's happening when that agent "discovers" Shopify tools — because the mechanism matters more than the marketing.

MCP works by loading complete tool definitions — schemas, parameter descriptions, authentication contexts — into the language model's context window on every single call. When the agent needs to figure out what it can do, it reads through these definitions the same way you'd read through a manual. Then it decides which tool to use, formulates the call, and executes it.

For a single integration like Shopify, this is manageable. The tool definitions might consume a few thousand tokens of context. The agent is smart enough to pick the right tool most of the time. It works.

The problem starts the moment you add a second integration. Then a third. Then a fourth.

The Context Window Tax

Here's what actually happens when a small business tries to build a real operational stack with MCP:

You connect Shopify for e-commerce. You add Slack for team communication. You connect Google Workspace for documents and email. You add your CRM. Maybe QuickBooks for accounting. Maybe a project management tool.

Each integration loads its full tool schema into the context window. Every single call. Not just the first time — every time the agent processes a request, it needs to re-read all those definitions to understand what tools are available.

A typical business SaaS tool exposes anywhere from 20 to 100+ API endpoints. Each endpoint has parameters, authentication requirements, response schemas, and usage constraints. When you stack five or six integrations, your context window — the working memory of the language model — is 70–80% full of tool definitions before the agent even reads your actual request.

That's not magic. That's a tax. And you're paying it on every interaction.

The Math Nobody Wants to Do

Let me walk through what this costs in practice.

Claude's API pricing charges per token — both input (what you send) and output (what it generates). The rates vary by model, but for the capable models you'd actually use for business automation, you're looking at meaningful per-token costs that add up fast at scale.

Now consider a simple workflow: a customer places an order, and your agent needs to check inventory in Shopify, create an invoice in QuickBooks, send a confirmation via Gmail, and post a notification in Slack.

That's four tool calls. Each one requires the full context window — including all the tool definitions for every connected service. Even if the agent only uses Shopify on the first call, it still reads the definitions for Slack, Google, QuickBooks, and everything else. You're paying for that reading on every single step.

At low volume — say, a handful of orders per day — the cost is tolerable. Maybe a few dollars. But the costs scale with usage, not with value delivered. Double your orders, double your token spend. Triple your integrations, and the per-interaction cost can triple too because the context window is carrying three times the tool definitions.

On top of the token costs, you're still paying for every SaaS subscription in the stack. Shopify ($39+/month), Slack, Google Workspace, your CRM, QuickBooks — the agent doesn't replace any of those subscriptions. It just adds a new layer of cost on top of all of them.

This Pattern Has a Name: The Multi-Agent Money Pit

If this sounds familiar, it should. It's the same pattern we saw in the early days of cloud computing.

Everyone rushed to go multi-cloud. AWS for compute, Azure for identity, Google Cloud for data. Each service worked well independently. But the integration layer — the glue holding it all together — became the most expensive, fragile, and difficult-to-maintain part of the entire architecture.

Eventually, the industry learned that consolidation beats distribution when your goal is operational efficiency. The companies that won were the ones that picked a platform and went deep, not the ones that stitched together the most services.

MCP is "multi-agent" following the same mistake. It makes it easy to connect many services. It does not make it efficient to run many services. There's a difference between "I can build this" and "I should build this."

Was MCP Built to Sell More Tokens?

I'm not suggesting Anthropic built MCP cynically. The protocol solves a real problem — tool discovery and interoperability — and solves it elegantly. MCP is genuinely good engineering.

But the economic incentive is worth noticing. Every MCP integration increases token consumption. Every additional tool in the context window means more tokens read on every call. The more integrations you build, the more tokens you burn. And Anthropic sells tokens.

This isn't a conspiracy. It's just incentive alignment — or more accurately, incentive misalignment with your business goals. Their revenue scales with your token usage. Your revenue scales with operational outcomes. Those are not the same thing.

When a platform vendor's business model benefits from you consuming more resources, you should at least ask whether the architecture they're promoting is optimized for your efficiency or their revenue.

The Alternative: Purpose-Built, Not Discovery-Based

There's a fundamentally different way to build AI automations for a business — and it's not new. It's just not as exciting to demo at a conference.

Instead of loading every tool definition into the context window and letting the agent figure out what to do, you build focused automations that know exactly what they need to do. The AI handles the intelligence — understanding natural language, making decisions, extracting meaning from unstructured data — while direct API calls handle the plumbing.

When a customer places an order:

A direct API call checks Shopify inventory. No context window overhead.
A direct API call creates the QuickBooks invoice. No tool discovery needed.
A direct API call sends the confirmation email. No schema loading.
The AI is only invoked where intelligence is actually required — understanding an ambiguous customer message, classifying a support ticket, summarizing a document.

The result: 90% less token consumption for the same workflow. Not because the AI is less capable, but because you're not asking it to read a phone book every time it needs to make a call.

And when you build on a consolidated platform rather than stitching together individual SaaS subscriptions, the cost structure flattens. You're paying for the platform, not for every integration multiplied by every token multiplied by every interaction.

Who MCP Actually Works For

I don't want to be unfair. MCP has legitimate use cases:

Developers building prototypes who need to test an idea quickly against multiple services. MCP's tool discovery is genuinely useful when you're exploring, not operating.
Enterprise teams with massive budgets where token costs are a rounding error on the infrastructure line item.
Single-integration scenarios where you're connecting one service and the context window overhead stays manageable.

Where MCP breaks down is exactly where most small and mid-market businesses live: multiple integrations, cost-sensitive operations, and a need for predictable monthly spend. If your annual revenue is between $5M and $100M, you almost certainly don't want your AI costs scaling linearly with usage while delivering diminishing returns on each additional token.

The "New Shiny Thing" Test

I've been in technology long enough to have seen every generation of "the new shiny thing." The pattern is always the same:

A genuinely impressive capability appears
Early adopters build exciting demos
The industry declares it "the future"
Businesses rush to adopt it
The operational reality sets in — cost, complexity, maintenance
The market corrects toward simpler, more efficient approaches

We're at step 4 with MCP right now. That Shopify demo is step 2. The LinkedIn excitement is step 3. The businesses signing up for multi-tool MCP architectures are step 4.

Steps 5 and 6 are coming. They always do.

The companies that will be in the strongest position are the ones that skipped straight to step 6 — building simple, focused, purpose-built automations that deliver operational outcomes at predictable costs. Not because they were smarter, but because someone helped them see past the magic to the math.

What to Do Instead

If you're exploring AI automations for your business — or you're a consultant building for clients — here's the question to start with:

"What is the specific operational outcome I need, and what is the simplest architecture that delivers it?"

Not "what's the most impressive demo?" Not "what did I see on LinkedIn?" Not "what does my developer want to build with?"

The answer to that question almost never involves loading six tool schemas into a context window and hoping the agent figures it out. It usually involves a focused automation that does one thing well, costs predictably, and actually runs in production without surprises.

At Hynds AI, that's what we help clients architect — AI solutions that avoid the token bloat and subscription stacking, delivering better results at a fraction of the cost. The approach isn't as exciting to demo. It's a lot more exciting to operate.

If you're evaluating AI architectures for your business, our AI Operations Readiness Assessment can help you identify where focused automation delivers the biggest impact — before you commit to an architecture that scales your costs faster than your results.