← All posts The Model Context Protocol is open. The reference implementations are on GitHub. Your engineers could stand up an MCP server over your database this afternoon. So when customers start asking whether their AI agents can connect to your product, the instinct is reasonable: why would we buy this? We’ll just build it.
You can. The question is whether you should, and the honest answer depends on the difference between an MCP server that demos and one you’d put in front of paying customers. This is that decision, laid out.
The build looks cheap because the demo is cheap #
Here’s the trap. Wiring an agent to a single database through MCP is genuinely a small project. It works in the demo. It works for the first design partner. It feels solved.
Then the caller becomes your customers’ agents (external, multi-tenant, autonomous) and the long tail arrives. None of what follows is exotic. All of it is load-bearing, and all of it is on you if you build.
What “production-grade” actually requires #
Multi-tenant isolation. Every query has to be scoped to the customer whose agent is asking, and that scoping has to be enforced at the boundary, not added as a filter the agent is trusted to include. Get this subtly wrong and one customer’s agent retrieves another customer’s data. This is the single highest-consequence part of the build, and it’s the part that’s easiest to get almost right.
Identity propagation. The agent acts on behalf of a specific end customer. That identity must travel from the agent, through the MCP layer, into the query, and be verified along the way. Auth for autonomous callers is its own discipline, distinct from the human login flows your product already has.
Governed metrics. An agent querying raw tables will misjoin and invent numbers that contradict your own product’s UI. Preventing that means a semantic layer (defined metrics, one source of truth) sitting between the agent and the database. Building and maintaining that layer is a real, ongoing investment.
Observability, rate limiting, and cost control. Agents don’t sleep and don’t self-throttle. They’ll issue orders of magnitude more queries than a human, at unpredictable times. You need per-tenant rate limits, query-cost guards, and a full audit trail of every tool call and result, which your enterprise customers will ask about in security review.
Keeping up with the protocol. MCP is young and moving. Whatever you build against today’s spec, you maintain against tomorrow’s, indefinitely.
The real cost comparison #
The build-vs-buy math isn’t “a week of engineering vs a subscription.” It’s:
Time to first customer. Weeks to a safe multi-tenant deployment if you build, versus days if you buy, directly relevant if you’re launching soon.Ongoing maintenance. A customer-facing MCP server is infrastructure. Someone owns it forever: security patches, spec upgrades, scaling, incident response.Opportunity cost. Every engineer-month on MCP plumbing is a month not spent on the product only you can build. Multi-tenant data access is undifferentiated heavy lifting: necessary, but not your moat.Risk exposure. A tenant-isolation or auth mistake here isn’t a bug ticket; it’s a data-leak incident with a customer’s name on it.
When building yourself is the right call #
Buying isn’t automatically correct. Building can make sense when:
- Agent access is a core part of your own differentiation and you want deep control over every layer.
- Your data model or compliance posture is unusual enough that no managed option fits.
- You have platform engineers to spare and this is squarely on your critical path.
If several of those are true, own it. Go in clear-eyed about the maintenance tail.
When buying is the right call #
For most teams, especially those with a launch date and a small platform team, buying wins because it collapses the timeline and moves the hardest, highest-risk parts off your plate. You want to answer “yes, your agents can connect to us” without turning it into a quarter of security-critical infrastructure work. That’s what Motley is for. SLayer, our open-source semantic layer, lets you define your metrics once on top of your warehouse. Motley is the hosted platform on top: it runs the governed, multi-tenant endpoint your customers’ agents call, with per-tenant isolation, identity handling, observability, and audit built in, and kept current as the protocol evolves. You get the capability now, and your engineers stay on the product only you can build.
Want the build-vs-buy cost model applied to your stack? Talk to us.