How MCP Changed How I Build AI Systems

I had 14 smart assistants running different parts of my DTC fashion brand. One handled product creation. Another managed pricing. Others took care of SEO, customer service, inventory, photography direction. Revenue per employee was up 38%. Manual work was down 42%. The results were real.

But behind the scenes, I had a mess.

The same basic task — "look up a product's details" — was built separately inside four different assistants. Each one had its own version. Same information, four copies of the instructions for how to get it.

When my online store changed how it shared data, I had to find and fix that task in four places. I missed one. One of my assistants started breaking on a Friday afternoon. It took me two hours to figure out the problem, because the issue wasn't with what that assistant was supposed to do. It was buried in a duplicated task I'd forgotten about.

This is what happens when AI systems grow without a shared foundation. Two or three assistants? Fine. Fourteen? You're spending more time fixing duplicate work than building anything new. The systems that were supposed to save time start eating it.

That's what forced me to rethink everything.

The Fix: One Toolbox Instead of Fourteen

The solution was something called MCP — Model Context Protocol. Forget the technical name. Here's what it actually is.

Think about USB. Before USB, every device had its own special cable. Your printer used one plug, your mouse used another, your keyboard used a third. USB gave everything the same connector. Plug anything into anything.

MCP does the same thing, but for AI tools. Instead of each assistant carrying its own copy of every task it needs, you build each task once and put it in a shared toolbox. Any assistant that needs to look up a product just reaches into the toolbox and grabs the same tool. One version, maintained in one place.

I built 19 tools organized into four toolboxes. Product information. Pricing and inventory. Content and SEO. Operations. Six different assistants all share these same tools.

Before, those 19 tasks had been copied and pasted across my assistants — totaling around 50 separate versions of things that should have existed once. Now each task lives in exactly one place.

Why This Matters for Speed

Here's where it gets practical.

Before this change, building a new AI assistant meant spending a full day just connecting it to all my data — my store, my pricing database, my content system. The actual smart part (telling the assistant what to do and how to think) might take an hour. The plumbing took eight.

Now I point a new assistant at the shared toolboxes and it immediately has access to everything. What used to take a full day takes about 20 minutes. I spend my time on the work that matters — the strategy, the decision-making logic — not rebuilding the same connections over and over.

And when something changes on my store's end, I update one tool in one place. All six assistants get the fix instantly. No hunting through code. No missed updates. No Friday afternoon surprises.

Last month I updated how my store connection works. One change, one place. All six assistants kept running without a hiccup.

What Goes Wrong (Because Something Always Does)

I want to be honest. This isn't magic. Things break.

When you make it easy to build tools, you build too many. I caught myself creating overly specific tools when one general-purpose tool would have worked fine. More tools means more confusion for the AI when it's deciding which one to grab.

The biggest lesson: the description you write for each tool matters more than the tool itself. It's not documentation for me. It's how the AI decides which tool fits the job. A vague description means the AI grabs the wrong tool. I now spend more time writing clear, specific descriptions than building the tools themselves.

I also learned that not every assistant needs access to every tool. My customer service assistant gets 12 tools. My SEO assistant gets 8. Fewer options means better decisions. Same reason a good restaurant has 30 items on the menu, not 300.

Who This Is For (And Who It Isn't)

This approach makes sense if you're running three or more AI systems that need the same underlying data. If you're adding new AI capabilities regularly and tired of rebuilding the same connections. If your team is spending more time maintaining AI systems than improving them.

It's overkill if you have one AI workflow doing one thing. Or if you're still experimenting.

I'll be direct: most companies I talk to aren't ready for this yet. They need to build their first two or three AI systems, feel the pain of duplication, and then this approach becomes obvious. Don't over-plan on day one. Build, feel the pain, then reorganize. The pain is the signal.

The bigger point isn't about any specific technology. It's about a way of thinking. AI capabilities should be shared tools, not isolated islands. Every new tool you build should make every existing assistant smarter. Companies that figure this out build systems that compound over time. Companies that don't end up with a graveyard of disconnected projects that can't share a customer record.

That's the kind of thinking I bring as a Chief AI Officer. Not "should we use AI?" but "how do we build AI systems that get stronger as they grow, instead of collapsing under their own weight?"

Thinking About AI for Your Business?

If this resonated — especially the part about maintaining duplicate work across disconnected AI systems — let's have a conversation. I do free 30-minute discovery calls where we look at your operations and identify where AI could actually move the needle. No slides, no pitch deck. Just an honest look at what would work for your specific situation.

Book a Discovery Call