Why MCP Gateways Alone Don't Solve the Real Problem

02.04.2026

Dunkel Cloud

AI agents touching production systems need two things.

First, they need a secure execution layer: authentication, authorization, credential isolation, audit logging, output controls, and a runtime that fails closed when something is wrong.

Second, they need a cheap way to expose backends: not just one or two hand-built integrations, but dozens or hundreds of real systems that can become usable tools without turning every API into a miniature software project.

Most current MCP discussions focus almost entirely on the first problem.

That is understandable. The first problem is scary. If an agent can call production tools, the blast radius is real. Credentials leak. PII slips through. Audit trails go missing. One hallucinated call can become an actual incident.

So yes, gateways matter.

They are the missing control plane between the model and the systems that matter.

But they do not solve the deeper scaling problem.

That problem sits one layer earlier.

The real bottleneck is not how we proxy tool calls.

The real bottleneck is that we still make backend creation far too expensive.

That is why MCP gateways alone do not solve the real problem.

MCP solved the interface problem

MCP matters because it gives the ecosystem a common way to discover and invoke tools. That is already a major step forward. It reduces one class of integration pain immediately: clients and hosts no longer need a custom protocol for every tool provider.

That is real progress.

But it is only one part of the stack.

A protocol standard is not the same thing as a scalable integration model.

HTTP did not eliminate the need to design APIs. OpenAPI did not eliminate the need to build services. Kubernetes did not eliminate the need to write good applications.

In the same way, MCP does not eliminate the work required to expose real systems as useful, safe, maintainable tools.

It standardizes invocation. It does not make integrations cheap.

That distinction is easy to miss in early demos because the first few tools are always the easiest ones. A simple GitHub wrapper. A lightweight Stripe example. One internal endpoint turned into a proof of concept.

That is enough to make the protocol look like the whole story.

It is not.

The hard part begins when the question changes from “Can we expose a tool?” to “Can we expose fifty backends without building fifty small software products?”

Gateways solve runtime control, not integration economics

A serious MCP deployment needs a runtime that sits between agents and backends.

That runtime should verify the caller, enforce authorization, inject credentials at execution time, log every call, and apply output controls before sensitive data reaches the model or the user. It should fail closed. If a check fails, nothing runs.

That is exactly what a gateway is for.

And this is where ToolMesh fits: a self-hosted execution layer between agents and infrastructure, enforcing authorization, secret injection, audit logging, and output policies on every tool call. That layer is not optional if your agent touches production systems. It is the difference between a neat demo and a production architecture.

But a gateway only governs what already exists.

It can secure tool calls. It can centralize policy. It can make execution observable.

What it cannot do, by itself, is change the cost structure of building the tools in the first place.

That is the trap many teams are walking into right now.

They improve the control layer and assume the scalability problem is solved.

In reality, they have secured the top of the funnel while leaving the creation bottleneck untouched.

The real N×M problem is upstream

People often describe the N×M problem in MCP as a compatibility issue: many clients, many backends, too many custom pairings.

MCP reduces part of that, which is good.

But the more painful N×M problem lives upstream.

It lives in the repeated work required to expose backend after backend after backend.

For every API, teams end up rebuilding the same bundle of concerns:

auth handling
parameter mapping
pagination
retries
error normalization
schema shaping
deployment packaging
runtime ownership
maintenance when the API changes

Sometimes that work is wrapped in a custom MCP server. Sometimes it becomes a thin adapter. Sometimes it is disguised as a “small integration.”

But it is the same pattern every time.

That is why wrapper-heavy approaches feel fine at the beginning and terrible at scale.

The first integration is exciting. The fifth is manageable. The twelfth is a prioritization problem. By the twentieth, teams start exposing only the endpoints they absolutely need.

Everything else falls into the backlog.

The result is familiar: a landscape of partial wrappers, incomplete coverage, duplicated boilerplate, multiple runtimes, and a long tail of APIs that never become available to agents at all.

That is not a gateway failure. It is a backend creation failure.

Better proxies do not make backend creation trivial

This is the core point.

A better proxy can improve security, consistency, and observability.

It cannot make a wrapper stop being a wrapper.

If every new backend still begins with “someone has to build and operate a custom MCP server”, the economics are still broken.

You can put a beautifully engineered gateway in front of that world and it will absolutely improve production readiness.

But the system will still scale badly because the unit of work is still too expensive.

Each additional backend still means more code, more packaging, more deployment, more ownership, and more surface area to maintain.

So the real question is not:

“How do we put a better proxy in front of MCP servers?”

The real question is:

“How do we make exposing a backend so cheap that the long tail of useful systems actually gets connected?”

That is the point where the conversation needs to shift.

The MCP stack is missing a description layer

Once you separate the problem cleanly, the architecture becomes obvious.

The MCP era needs three layers:

a protocol layer for discovery and invocation
an execution layer for governance and runtime control
a description layer that makes backends cheap to expose

The first layer is MCP. The second layer is the gateway. The missing third layer is where most ecosystems are still immature.

Without that third layer, every backend remains a custom engineering exercise. With it, backend exposure becomes a declarative problem.

And that changes everything.

Because descriptions scale differently from code.

A good description layer moves repeated logic out of bespoke wrappers and into shared runtime behavior. It turns backend exposure from a hand-built server into a compact, reviewable, declarative artifact.

That is the architectural shift the MCP ecosystem needs if it wants to move beyond a handful of polished demos.

DADL is the missing piece

This is exactly where DADL matters.

DADL, the Dunkel API Description Language, takes a different approach from wrapper-first integration. Instead of writing a custom MCP server for each REST API, the backend is described declaratively in YAML, while the runtime handles the standard mechanics that would otherwise be rebuilt again and again: authentication, pagination, retries, and error mapping.

That is not just a nicer developer experience. It is a different cost model.

Without a description layer, the default unit of work is: build a server. With a description layer, the unit of work becomes: describe the backend, review it, and let the runtime execute it safely.

That is a radically better scaling curve.

It means teams can expose more of the real API surface instead of stopping after a narrow “good enough” subset. It means they do not need a separate runtime, dependency tree, Docker image, and maintenance burden for every integration. It means common integration logic lives where it belongs: in one shared execution environment.

And because DADL is intentionally compact and close to the structure of existing API specs, it also opens the door to something even more important: modern LLMs can often generate a usable first version from an existing API definition.

That is where the category really changes.

Because once the model can help generate the description, and the runtime can safely execute it, the cost of connecting a new backend drops by an order of magnitude.

That is how you start to unlock the long tail.

Why this is the OpenAPI moment for MCP

The best analogy here is not “another gateway” or “another wrapper framework.”

It is OpenAPI.

OpenAPI did not replace HTTP. It made HTTP ecosystems programmable. It made APIs describable in a way that tools, docs, code generators, and platforms could all understand.

That shift was not glamorous, but it changed the economics of API work.

The MCP ecosystem needs the same kind of shift now.

MCP already standardizes how tools are called. What it still lacks, in many architectures, is a standard way to describe real backends so that tooling and runtime layers can do the boring work once instead of forcing teams to reimplement it forever.

That is why DADL is best understood as OpenAPI for the MCP era.

Not because it replaces MCP. Not because it replaces a gateway. But because it fills the missing abstraction layer between raw backend APIs and secure, governable tool execution.

Why developers should care

For developers, this is mostly about escaping integration drudgery.

Most wrapper code is not differentiated engineering. It is repetitive adaptation work that absorbs time, expands maintenance burden, and creates more runtime sprawl than value.

A declarative backend layer changes that.

Instead of spending engineering time on the same auth and pagination logic for the tenth time, teams can focus on what actually matters: domain behavior, workflows, guardrails, and the product logic built on top of those tools.

Just as importantly, lower integration cost increases API coverage.

That matters a lot.

Agent systems often underperform not because the model is weak, but because the available tool surface is too thin. The backend may support fifty useful operations, but only six are exposed because wrapping the rest is too expensive.

When backend creation becomes cheap, the tool layer can start to resemble the actual system instead of the budget constraints of the integration team.

Why architects should care

For architects, the value is even clearer.

A three-layer model separates concerns in the right way.

MCP handles communication. The gateway handles trust, control, and auditability. The description layer handles backend scale.

That means policy stops depending on how a particular wrapper was written. Credentials stay outside model context. Audit becomes consistent. Security becomes systemic instead of accidental.

And new integrations can be added without creating a new snowflake service every time.

That is the kind of architecture enterprises actually want.

Not a zoo of semi-maintained MCP servers. Not a future where every new backend implies another runtime to patch and observe.

They want a stable execution layer and a cheap path for bringing more systems under that layer.

That is exactly why gateways alone are not enough.

The future is not gateway versus description layer

It is gateway plus description layer.

This is not an either-or choice.

You need MCP because the ecosystem needs a common protocol. You need a gateway because production tool calls need governance. And you need a description layer because no organization can afford to scale backend exposure through endless hand-built wrappers.

That is the stack.

MCP standardizes invocation. ToolMesh secures execution. DADL makes backend creation cheap enough to scale.

Once you see the problem this way, the market noise gets easier to ignore.

The winners in this space will not be the teams with the prettiest proxy story. They will be the teams that solve both sides of the equation:

secure execution for real systems
trivial creation for real backends

The real problem

So yes, build the gateway. You need it.

But do not mistake runtime control for integration scale.

The real problem is not that MCP needs better proxies. The real problem is that the ecosystem still treats backend exposure as custom software work when it should be a declarative operation.

As long as that remains true, the long tail of useful systems will stay disconnected, and agent infrastructure will keep hitting the same ceiling.

That ceiling does not break when we proxy harder.

It breaks when backend creation becomes trivial.

That is why MCP gateways alone do not solve the real problem.

And that is why DADL matters.

Not as a convenience feature. Not as a sidecar format. But as the missing description layer that turns secure agent tooling from a handcrafted practice into a scalable system.

In that sense, the real breakthrough is not just safer tool calls.

It is finally making backend creation cheap enough for the MCP era to scale.