MCP for the Rest of Us

There’s a ritual around building a manual report. Export the spreadsheet, upload it somewhere else. Transform the data, analyze it, output and then compare that output against another export from somewhere else. It feels like alchemy, in a way. If done correctly, the product can be magical. But almost always it’s a bit of a time sink.

Some of this current wave of LLMs have changed things up for us, certainly. Claude, at the very least, is the Junior Analyst you need to consolidate the above paragraph into a much quicker process. But that process has its own time costs, where every piece of data you forgot to include or missing date ranges you didn’t think to set now eats up the time it shouldn’t. Plus, token expenditure now has to be added to our pool of worries.

Problems across the board, but never more poignant than with smaller teams and owner operators: where every dollar and hour spent is a tactical exercise.

To call the LLM space rapidly evolving would be a significant understatement. Benchmarks, reasoning scores, which one “thinks” best… all of this changes daily. We’ve crossed into a space of high capability, and in day-to-day business work, the model is rarely the bottleneck.

It’s working blind. We’ve been hand-feeding our models the world through a straw.

The Model Context Protocol, or MCP, is what changed that. It didn’t make our models smarter — it made them more informed. For real analytical work, and beyond, that’s the difference that matters.

This is the version of the MCP story for people running actual small businesses, not a protocol tour or an enterprise governance deck. Just what it changes for you, and where it falls short.

The model was never the bottleneck

To summarize the point, disappointments people have with business AI are really a visibility problem, not an intelligence one.

You ask for an analysis and you get something that sounds plausible and lands a little hollow, because the model only ever saw the slice you pasted in. It didn’t see the booking that got cancelled, or the refund that posted Tuesday, or the note in a different sheet that changes the whole conclusion. It reasoned well over an incomplete picture and handed you a confident, incomplete answer.

For two years the instinct has been to fix this by prompting harder: longer instructions, more careful context, more pasting. But that’s just optimizing the straw. The real fix is to stop hand-feeding the model and let it see the source.

What MCP actually is, in one breath

MCP is a standard way to plug an AI assistant into your real tools and data. Think USB-C: one kind of port, and suddenly a lot of different things connect without a custom adapter for each one.

Before it, wiring a model up to your database, your files, or your booking system meant a bespoke integration for every connection, each one expensive to build and yours to maintain forever. MCP gives those connections a common language, so the model can read the actual file or query the actual database instead of waiting on a copy-paste.

Anthropic introduced it in late 2024, and by the end of 2025 it had been handed to a neutral foundation and picked up across the major AI vendors. The ecosystem is real: the core software libraries see roughly 97 million downloads a month. How many connectors exist depends entirely on who’s counting. The official curated registry lists a couple thousand, Anthropic’s own late-2025 figure was north of ten thousand active servers, and community trackers run higher still. (For a sense of how young this all is, Anthropic’s own reference set actively maintains seven of them. The rest got handed off to vendors.)

That’s about as much protocol explanation as you need. The interesting part is what it does.

Before: engineers, a pile of APIs, ETL pipelines to move data around, a warehouse to put it in, custom integrations to wire the model to all of it, and someone on payroll to keep the whole thing from breaking. That was a capability you got only if you could afford an engineering team. Everyone else got a chatbot they pasted into.

After: a connector, some permissions, and a workflow.

That contrast is the real story, and it’s a bigger one than the protocol. MCP dropped the cost of integration far enough that the connected-AI pattern, which used to be a structural advantage for the well-resourced, is now within reach of a two-person shop. And that simplicity goes beyond a cost and capability perspective — it’s also less parts to break in the machine. More structural integrity and easier problems to troubleshoot should anything go wrong.

One honest caveat, because it’s the one that actually bites. MCP lowers the cost of connecting to your data. It does nothing for the quality of that data. Point a model at a messy, undocumented, half-abandoned pile of spreadsheets and you’ll get confidently analyzed garbage. The unlock is real, but it has a floor: you still need data worth connecting to.

What this looks like at actual small scale

We run a Monday-morning briefing for a beverage distribution company in the Tri-State area, and it’s the clearest before-and-after we have.

Before, Monday meant someone opening the product system in one tab, the accounting software in another, and last week’s spreadsheet in a third, then assembling a picture by hand. How did delivery track against forecast? Which zones underperformed? Did that midweek rate change do anything? An hour of tab-switching later you’d have a rough answer and not much time left to act on it.

After, the model reads the live numbers itself through MCP, connected to the data warehouse where all of their various platform data was aggregated, and writes the briefing. Delivery against forecast, revenue by zone, the anomalies worth a human’s attention, what moved since last week. One recent briefing flagged a quiet midweek dip at the premium zones that the headline delivery number had been hiding, which is exactly the kind of thing that used to slip past in the Monday scramble.

The result isn’t that the AI got smarter. It’s that the analysis is built on everything, instead of on whatever someone had time to pull. The decisions improve because the picture is complete, the hour of assembly goes away, and the operator sees things they used to miss.

In this case, Claude knew what data it needed, had the freedom to query the data warehouse to get it… the model didn’t get cleverer between the before and the after. It just stopped guessing at the parts it couldn’t see.

Informed beats smart-but-guessing

If the whole argument fits in one line, it’s this: a model is only as good as what you let it look at.

Give it the complete, current picture and the answers get better, not because the model improved but because it’s finally working from the whole thing. You get fewer conclusions built on missing context, and fewer confident guesses dressed up as analysis. And because the model can pull what it needs and then keep going (read the next file, run the next query), you stop being the bottleneck who has to anticipate every piece of context up front.

Connected isn’t the same as correct

Here’s what the cheerleaders tend to skip, and the reason we’d never tell a client to switch every connector on and walk away.

Connecting a model to live systems introduces a failure mode that’s worse than a wrong answer: a confident answer built on a hole, with nothing in the output to signal the hole is there. A few we actively watch for:

• Silent partial retrieval. A query times out or returns half the rows, the model doesn’t flag it, and you get a clean-looking analysis of incomplete data.
• Wrong source. The model reads the draft spreadsheet instead of the production one, or last quarter’s export instead of this quarter’s, and everything downstream is quietly off.
• Permission gaps. The model can only see part of the picture because of how access was scoped, and produces a complete-sounding conclusion from a partial view.

There’s also a subtler cost worth knowing about. Every connected tool spends some of the model’s working memory just describing itself, and connect enough of them and those descriptions can eat close to half the available context before any real work begins. That’s its own argument for connecting a few things well rather than everything at once, and it’s real enough that companies operating at scale have pulled connectors back over it.

None of this is a reason to avoid MCP. It’s a reason to treat connected output the way you’d treat a sharp new hire’s first report: useful, often excellent, and not something you sign off on without knowing where the numbers came from.

Read only is perfectly fine

Everything above is about one use of MCP: letting a model reason over your data. Analysis, briefings, decision support. Inside that lane, “context, not capability” holds all the way down.

There’s a second use, which is letting the model act: write to your systems, run code, kick off multi-step jobs on its own. That’s a genuinely different decision with a different risk profile, and it deserves to be made deliberately rather than switched on by accident alongside read access. Everything in this article is about giving the model better eyes, not new hands.

How a small operator should actually start

The sane sequence is boring, and it works:

1. Connect one thing, the single source that would most improve one analysis.
2. Solve one problem with it, end to end.
3. Prove the value. Confirm the output is right and that someone actually trusts it.
4. Expand carefully, one connection at a time, permissions scoped as narrowly as the job allows.

That’s it. The mistake we see most often is the opposite of timidity: connecting everything at once, drowning the model in sources it has to choose between, and creating more places for a wrong answer to hide.

Connecting everything is how you get noise. Connecting the right one thing is how you get a Monday briefing that writes itself. Working out which one, and making sure the numbers underneath it hold up, is most of the actual work, and it’s worth getting right before you scale anything.

That’s the part we do. If you’re staring at a stack of tabs every Monday, wondering why the AI everyone’s so excited about still can’t tell you how your own business is doing, the answer usually isn’t a smarter model. It’s a connected one, pointed at the right thing, with someone watching the seams.