Most teams shipping AI to production are still building on a stack designed for 2023. Custom chat UIs. Orchestration frameworks. RAG pipelines. Vector databases. Agent observability layers. An AI platform team to keep it all running. At Warmtebouw we skipped all of it and shipped nine MCP servers in three months for non-technical business users across ERP, BIM, fleet, energy, and operational systems.

This is the case that MCP isn't a piece of your AI platform — it is your AI platform, and most of the layers above it are overhead you don't need at mid-market scale.

---

The model is the agent. The framework is overhead.

The framing "you need an agent framework" obscures a simpler truth: the model is the agent. It reads tool descriptions. It chooses which tool to call. It sequences the calls. It interprets the results. That's textbook agentic behaviour, built into every frontier model that speaks MCP.

What companies sell you on top of that is framework around the agent: orchestration logic, retrieval pipelines, prompt managers, observability layers. Each of those products is solving a real problem in some context. But in a mid-sized business with a knowable set of important data sources, those contexts mostly don't apply.

Each row on the right is a paid product category. Each row on the left is the model, the protocol, or work I did once and reuse.

What "build for MCP" looks like in practice

A well-designed MCP server doesn't ask the model to figure out what the data means. It tells the model what the data means in the tool description itself.

The contrast plays out at every level. A bad tool says: "query data from the ERP." A good tool says: "always start with summaryOnly=true. Active projects accumulate thousands of records. Type codes determine which fields are populated. Use get_budget for planned costs, this tool for actuals."

The first version forces the model to invent a query strategy on every call. The second hands the model a query strategy on every call. The difference between those two servers, in production, is whether business users actually use the result.

This is the work teams skip when they reach for frameworks. The complexity is mostly self-inflicted. It exists because nobody wrote down what the tools mean. The same gap is why 97% of MCP tool descriptions analysed in production contain at least one critical smell.

One server can compose many sources

The most common objection ("but you need orchestration to combine data from multiple systems") assumes orchestration has to live in a separate framework. It doesn't.

One of my MCP servers combines five heterogeneous sources behind one interface: a third-party meter-data aggregator, a public weather API, a government building registry, the company ERP, and an IoT building-automation platform. No agent dance. No retrieval pipeline. Just typed tools with descriptions explaining when each source applies and how they relate.

The model figures out the composition because the tool descriptions tell it the relationships. The pattern works across nine production servers covering ERP, BIM, fleet, calculations, building automation, energy, and operational logs. Effectively the entire operational surface of one business, addressable through tool descriptions, consumable by any MCP-speaking model.

Tools abstract everything below them

The model never sees how the data is fetched. Inside one MCP server, individual tools call whatever the underlying system speaks: REST for SaaS products, GraphQL for internal APIs, direct SQL against the data warehouse, JSON files on disk, SOAP envelopes for legacy systems. The tool returns typed records; the protocol heterogeneity stays inside the tool.

That's the abstraction layer the data-fabric and iPaaS industries charge premium prices to build. MCP tools already do it, one tool at a time, in whatever language the data actually lives in, with no central pipeline. The choice of backend doesn't propagate; pick whatever fits the underlying system, and the model interface stays identical.

Even SQL becomes tractable. Direct SQL from an LLM is dangerous because the model can be tricked into destructive queries. But SQL inside a typed MCP tool (where the server builds SQL from schema-validated parameters, the connection runs as a read-only role, and the corporate IdP gates who can call it) is just a regular function call. Any value that doesn't match the tool's JSON schema is rejected at the protocol boundary before the tool's code runs at all.

This isn't theoretical. One of my servers is 100% SQL behind a query endpoint, covering calculation data. Every tool translates a typed agent request into a SQL query: the model passes schema-validated parameters in, the server constructs and runs the query, typed records come back out. The model never sees SQL. The connection runs as a read-only role, and access is gated by the same IdP roles that govern every other system.

I built it in one day. The calculation expert who owns the underlying data validated it, and it already exposes every dataset that team needs. Once you've internalised the pattern, applying it to a new domain is a day's work, not a quarter's project.

Why mid-market is the sweet spot

This argument has bounds. At Fortune 500 scale (hundreds of heterogeneous systems, multi-tenant SaaS, mountains of unstructured documents) you might need retrieval pipelines and orchestration. The complexity is real because the scope is real.

But mid-sized businesses have something Fortune 500 doesn't: a knowable set of important data sources. Five to twenty key systems. A handful of domain experts who can sit with you for an afternoon and tell you what the data actually means. That's the entire prerequisite for a well-built MCP server.

If your company fits in one office building and has fewer than twenty important systems, you're who this is for. You almost certainly don't need most of what the AI industry is trying to sell you.

What "the platform" actually is

Notice what's missing from the table above: a platform. There's no "AI platform" in the stack. Just a frontier model, MCP servers, and the corporate identity layer the business already pays for. Swap the model (Claude today, Gemini tomorrow, GPT next quarter) and the rest of the stack stays identical.

That last piece is what turns nine MCP servers into something an enterprise can run. Not an AI-specific identity layer. The one the company already operates. In a Microsoft shop, that's Entra ID with RBAC. In other shops, Okta, Google Cloud Identity, or any OAuth 2.1 provider. MCP servers authenticate against the existing IdP, scope tool access by role, and log every call to the same audit trail every other corporate system already uses.

The implications:

• A field engineer sees only their own time bookings and assigned projects.
• A controller sees aggregated financials, not raw payroll.
• A guest user sees nothing.

Every action is attributable to a named identity in the same audit log as every other system. That's the entire enterprise AI security model. No prompt-firewall vendor. No AI-specific governance platform. No model gateway. Just the access-control infrastructure the company already runs, enforced at the MCP-tool boundary. Even prompt injection becomes bounded. A tricked model can only call tools the authenticated user is already authorised to call.

Anthropic's 2026 MCP roadmap leads with enterprise authentication and identity-provider integration. The protocol is moving in this direction because the pattern works: tool-level RBAC against the corporate IdP turns "the AI security problem" into a solved authentication problem. Which it always was.

Wire MCP servers through enterprise identity and MCP isn't connected to the platform. MCP is the platform.

The work that matters

What the framework industry sells is scaffolding. What actually moves outcomes is the specific, domain-bound work of writing good tool descriptions: choosing the right granularity, documenting which tool fits which question, adding query strategies, capturing failure modes from production usage and feeding them back.

None of that can be outsourced to a vendor, because nobody outside your business knows what your data means. But all of it is reachable in a few weeks per domain, with one engineer and one domain expert. That's the trade you're being told doesn't exist.

The question that replaces "which framework should I pick?"

If you're starting MCP work today, the most useful question isn't "which framework do I need?" It's "what's the smallest useful tool I can write for the one person whose week would get better tomorrow if it worked?"

Build that. Watch them use it. Write down what they tried that didn't work. Update the tool description. Ship the next one.

Three months of that across a real business produces nine production servers and zero framework dependencies. That's the story: not that frameworks are bad, but that for most mid-sized companies, they're the wrong problem to be solving first.

The model is the agent. The IdP is the security boundary. MCP is the platform. Build for the platform, not around it.

---

This piece is part of a series on shipping MCP to production in mid-market companies. If you want the practical case for why this architecture is reachable for smaller companies, see Enterprise AI Without an Enterprise Budget. For the maturity ladder I see across MCP servers in production, see Six Levels of MCP Servers.

Originally published on davidgolverdingen.nl. I write about MCP architecture, agent design, and what it takes to ship AI to non-technical users in mid-market companies.