Something is happening in almost every technical conversation I’m in right now.
A leader comes out of a meeting and says, “We need to add MCP support.” A vendor hears it from a customer and starts scheduling sprints. A product manager writes a ticket. An engineer opens the spec.
And then the engineer starts asking questions.
*What exactly are we building? Who’s consuming this? What problem does it solve?*
And somewhere in that process — if the team is honest — they realize the requirement wasn’t really “add MCP support.” It was: ”make this work better with AI.”
Those are not the same thing.
MCP (Model Context Protocol) has become shorthand for “AI-compatible.” When a business leader says “we need MCP,” what they usually mean is: our customers are building with AI, our competitors are talking about AI integrations, and we don’t want to be left behind.
That’s a legitimate business concern. But the solution isn’t always a new protocol.
What customers actually want — what’s underneath the buzzword — is usually one of these:
- “I want to ask your product questions in plain language and get useful answers.”
- “I want my AI agent to be able to use your data without me writing a ton of custom code”
- “I want your system to understand what I’m trying to do, not just what I literally typed”
That’s not MCP. That’s intelligence. And intelligence can live in a lot of places.
---
Here’s the architectural decision that actually matters — and almost nobody is framing it this way:
Does the AI reasoning live on the client, or does it live in your API?
Client-side MCP is the right answer when:
- You’re building an AI agent that orchestrates across systems you don’t own
- The tools it needs to call belong to different vendors, different domains
- No single system can own the reasoning because the reasoning spans all of them
- You need the model to discover capabilities at runtime and compose them dynamically
Server-side intelligence (a “smart API”) is the right answer when:
- You own the data and the domain
- You want your product to understand intent, not just respond to exact queries
- Your customers want to ask questions and get answers — not build agents
- You want to control the quality, cost, and consistency of AI responses
Most of the “we need MCP” requirements I see are actually in the second category. The customers want the product to be smarter. They don’t need a protocol — they need the API to think.
---
What a Smart API Actually Looks Like
A dumb API takes what you give it and returns exactly what you asked for. You pass `skill=rust` and get Rust projects. You pass `category=featured` and get featured items. Precise, predictable, brittle.
A smart API understands intent. You pass “How have operation logs at TX01 been looking over the weekend?” and it figures out what that means — searches the right fields, weights the right signals, returns something useful. The intelligence is baked in server-side. The client just asks questions.
The difference in the caller’s experience is enormous. Instead of building a query builder, they write a sentence. Instead of learning your schema, they describe what they need.
That’s not MCP. That’s a well-designed API with AI reasoning at the right layer.
The failure mode I keep seeing:
A team gets the “we need MCP” requirement. They build an MCP server on top of their existing API. The MCP server exposes the same dumb endpoints — same brittle filters, same exact-match queries — just wrapped in tool definitions.
Now an AI agent can discover those tools. But the tools still don’t think. The model has to compensate — writing complex queries, chaining calls, handling errors — because the underlying API has no intelligence of its own.
The result: a fragile, expensive integration that requires a sophisticated AI client just to do basic things. The MCP didn’t fix the problem. It just moved it upstream and cost more tokens to get the same results.
The fix isn’t more protocol. It’s better API design.
To be clear: MCP is a real tool that solves a real problem. If you’re building an AI agent that needs to reach across Salesforce, GitHub, Jira, your internal docs, and a third-party analytics platform — you need MCP. That agent can’t know in advance what tools exist or how to compose them. The protocol handles that.
But that’s a specific use case. It’s not “make our product work with AI.”
The decision tree is actually pretty simple:
Do you own the domain and the data the AI needs to reason over?
→ Yes: Build intelligence into your API. Make it understand intent. Let clients ask questions.
→ No (you’re bridging systems you don’t control): MCP is the right layer.
Is your customer building an autonomous agent that needs to discover and compose tools dynamically?
→ Yes: MCP makes sense.
→ No (they just want AI-powered features): Make your API smarter.
Next time someone says “we need MCP,” the right response isn’t to start building. It’s to ask: what are customers actually trying to do?
If the answer is “interact with our product using AI” — that’s a product design problem, not a protocol problem. Solve it by putting intelligence in the right place.
If the answer is “build agents that orchestrate across multiple systems including ours” — now you’re in MCP territory.
The teams getting this right are the ones having that conversation before writing a line of code. They’re not asking “how do we implement MCP?” They’re asking “where does the reasoning belong?” And then they build accordingly.
That’s a harder question. It requires understanding your customers, your architecture, and the actual shape of the problem.
But it’s the right question. And it leads to systems that actually work — whether they use MCP or not.
Want to see how the hotdogs are made? I built a live interactive demo on my portfolio that walks through all three paths — dumb API, smart API, and MCP — with real running code you can execute yourself or through your favorite AI tools.
And if you want the full gory details — actual endpoint code, MCP tool definitions, token costs, the works — that’s the next post. Subscribe so you don’t miss it.
---
Want to think through where the reasoning belongs in your system? That’s exactly the kind of conversation I have with teams at Blue Ridge Systems.
No pitch — just a conversation. brc-ai.net/contact
---
*If this framing was useful, share it. This conversation is happening in a lot of rooms right now, and most of them are starting with the wrong question.*
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.