Last week, TikTok launched its own MCP server for ad automation at TikTok World 2026. The week before, GitHub did it. Before that, Notion, then Productive. Every major SaaS vendor is now shipping a Model Context Protocol endpoint — and nobody is talking about what this means for IT teams in German SMEs. We see it with our clients every day: one agent experiment turns into twenty MCP connectors within two quarters. We call it MCP sprawl, and 2026 is the year it hits everyone.
What MCP actually is — short and honest
Model Context Protocol is an open standard Anthropic introduced in late 2024. The idea: instead of marrying every LLM to every API individually, MCP defines a single uniform protocol. An agent speaks MCP, a server speaks MCP, done. On paper, this is the clean answer to the integration chaos of the last two years.
In practice, 2026 has turned it into something else. Anthropic launched it, but everyone adopted it: OpenAI, Google, Microsoft, AWS Bedrock — and for a few months now, every self-respecting SaaS vendor. TikTok for ads. GitHub for repos. Notion for knowledge. Stripe for payments. Jira, Linear, Productive for tickets. Salesforce, HubSpot, Pipedrive for CRM. Slack, Teams, Discord for chat.
It feels like 2015, when suddenly every tool had a Zapier integration. With one crucial difference: back then, a Zap was a deterministic pipeline. Today, every MCP call burns LLM tokens, carries a hallucination risk, and opens a new auth surface.
Why it's exploding now
Three things converged in 2026:
- SaaS vendors realised "LLM-ready" is a sales argument. If you don't ship an MCP endpoint in 2026, you drop out of agent marketplaces. This isn't a technical push anymore, it's marketing.
- Hyperscalers baked MCP into their platforms. Google Cloud Next 2026 plastered "Agents are the architecture now" everywhere. AWS shipped AgentCore with native MCP gateway support. Azure is following. That turns MCP from an Anthropic side project into infrastructure.
- Models are getting tool-hungrier. A modern agent doesn't call one API per task anymore — it calls five to fifteen. Multiply that by twenty connected tools and you're at four- to five-digit API calls per employee per day in no time.
What MCP sprawl looks like in practice
In a typical SME stack, here's what we see in 2026:
- One MCP server per ticketing tool (Jira, Linear, or Productive)
- One for code hosting (GitHub, GitLab)
- One for knowledge (Notion, Confluence)
- One per CRM (HubSpot, Salesforce)
- One for accounting (Lexware, DATEV, sevDesk)
- One for cloud (AWS, Azure, Hetzner, Forge)
- One per marketing tool (Ads, Analytics, Mail)
- One per internal system (ERP, inventory, helpdesk)
Realistically you end up with 15 to 25 connectors — and that's without anything exotic. Every connector has its own auth model (OAuth, API key, service account, personal access token), its own rate-limit logic, its own telemetry, and its own token cost per call. Nobody has a central view.
The three problems nobody discusses
1. Token costs scale more quietly than you think
Every MCP server feeds its tool definitions as JSON schema into the model's context. A single endpoint often needs 500 to 2,000 input tokens just to be "available". With twenty servers, that's quickly 30,000 tokens per conversation start — before the agent has done anything. It eats your context window, costs money per call, and slows the model down.
With clients running without proper tool routing, we see token costs quadruple within eight weeks of MCP adoption. Nobody knows where it comes from, because each server's telemetry lives in isolation.
2. Auth sprawl is compliance Russian roulette
Twenty connectors mean twenty secrets. When a developer tries out MCP servers, the GitHub token ends up in plaintext in a config file, the Productive token in an environment variable on their laptop, the HubSpot OAuth refresh token in a browser profile. Nobody knows which token has which scopes, nobody can rotate them, nobody can revoke them.
When the breach comes — and it will — you have no answer to the only question that matters: "Which data could be seen by which agent during which time window?"
3. Observability ends at the server boundary
Every MCP server logs in isolation. GitHub logs your git calls, Productive logs your task calls, Notion logs your page calls. What nobody logs: the chain. Which agent called which server in what order, with what reasoning, on whose behalf? That's exactly what you need the moment an agent does something wrong. And it will do something wrong.
How we approach this with our clients
For a few months now, we've been building an architecture that addresses exactly these three problems — and we have it running in production with several clients. Three components that we consider mandatory for 2026:
A central agent gateway
Instead of every agent talking to every MCP server directly, there's exactly one endpoint: our agent gateway. It speaks MCP upward (to the agents) and routes downward to the individual servers. That gives us one place to filter tool definitions, log calls, and enforce policies. Token consumption of tool schemas drops because we only load the genuinely relevant tools per agent session.
A central token vault
No secrets in configs, none in environment variables, none on developer laptops. Instead, a token vault that issues short-lived credentials per connection. The agent never sees the actual GitHub PAT — it gets a vault reference. Rotation, revocation, and audit log run centrally. In an incident, we can actually answer what happened.
A policy engine that goes beyond on/off
Most MCP servers have binary access models: your token either has access or it doesn't. That's not enough in 2026. We use a fine-grained policy engine that can express statements like "agent X can read tickets in project Y but cannot post comments" or "this agent can only read repos between 8am and 6pm, and only those tagged public". Sounds overengineered — until your first incident.
Tracing across every hop
Every agent call, every tool call, every sub-call lands in a single tracing system. With cost attribution per action, token spend per step, latency per hop. That lets us see not just that an agent is expensive — we see where in which pipeline it gets expensive. That's the difference between "we now spend €12,000 a month" and "we now spend €12,000 a month because this one triage agent runs every ticket through the CRM twice".
What SMEs should do now
Three pragmatic steps before MCP sprawl hits you:
- Inventory before it's too late. Which tools are already MCP-ready today or will be within the next three months? Which teams would use them? Who holds the credentials? That's an hour of work for most SMEs — and it's the one hour you can't save.
- Make one gateway decision, not twenty connector decisions. Instead of letting every team "quickly" integrate an MCP server, agree on an architectural standard: all agents go through one gateway. That's a governance decision, not a tech stack.
- Token telemetry is mandatory, not optional. If you can't measure what each agent spends on each tool call, you're flying blind. Doesn't matter which tracing tool — just pick one.
Bottom line
MCP is a good idea. The standard is clean, adoption is strong, the ecosystem is growing. But every good idea that jumps from "new" to "everywhere" within twelve months produces a sprawl problem. And you don't solve sprawl problems by adding more connectors — you solve them with architecture.
Whoever simply "plugs in" the next twenty MCP servers in 2026 is building a maintenance burden that catches up with them in 2027. Whoever asks the gateway, vault, and policy questions early has a lead in a year that's hard to close.
We're watching this play out live. And we're talking about it honestly, because nobody else is.
