ToolMesh | Blog

Populating NetBox from Real Infrastructure with ToolMesh

Thu, 16 Apr 2026 00:00:00 GMT

A typical scenario: three cloud providers, two hypervisors, a handful of edge sites. Somewhere around 200 devices and VMs, give or take. You spin up NetBox, stare at the empty dashboard, and realize the real work hasn’t started. Writing import scripts for five different APIs is a week of work you don’t want to do — so NetBox sits empty, and the spreadsheet wins again.

This post shows how to skip that week. We walk through using ToolMesh to pull live infrastructure data from multiple sources and push it into NetBox via the NetBox DADL connector. For the business case and broader “why,” read the companion post on dunkel.cloud. Here we focus on the how.

Architecture Overview

The data flow:

Hetzner Cloud ───┐
Linode        ───┤
Xen Orchestra ───┼── ToolMesh ── NetBox DADL ── NetBox API
Unifi         ───┤
Tailscale     ───┘

Each source system has its own API, its own authentication, and its own data model. ToolMesh acts as the gateway: it authenticates against each source using stored credentials, normalizes the responses, and writes the results into NetBox through the NetBox DADL definition.

DADL (Declarative API Definition Language) is a YAML-based format that describes REST APIs as tool definitions. Instead of writing a custom MCP server wrapper for each API, you describe the endpoints, parameters, and authentication in one file. ToolMesh turns that description into callable tools at runtime — handling credential injection, authorization, and audit logging automatically. The NetBox DADL covers most of the NetBox REST API; each source DADL covers one cloud or appliance. No custom glue code sits between them.

Mapping: Source Objects to NetBox Objects

The core challenge is translating between data models. A Hetzner “server” becomes a NetBox “device.” A Linode “instance” also becomes a device, but the field names differ. Here is how the main objects map:

Source	Source Object	NetBox Object	Key Fields
Hetzner Cloud	Server	Device	name, server_type → device_type, datacenter → site
Hetzner Cloud	Network	Prefix	ip_range → prefix, name → description
Linode	Instance	Device	label → name, type → device_type, region → site
Linode	IPv4/IPv6	IP Address	address → address, linode_id → assigned device
Xen Orchestra	VM	Virtual Machine	name_label → name, power_state → status
Xen Orchestra	Network	VLAN	name_label → name, MTU
Unifi	Device	Device	name, model → device_type, site → site
Tailscale	Node	Device	hostname → name, addresses → IP Addresses

Concretely, a single Hetzner server comes back looking like this:

{
  "id": 42891337,
  "name": "web-fra-01",
  "server_type": { "name": "cx22", "cores": 2, "memory": 4 },
  "datacenter": { "name": "fsn1-dc14", "location": { "name": "fsn1" } },
  "public_net": { "ipv4": { "ip": "95.217.xx.xx" } },
  "status": "running"
}

After ToolMesh runs it through the NetBox DADL, that single source object produces three linked NetBox records: a Site (fsn1), a DeviceType (cx22, 2 cores, 4 GB), and a Device (web-fra-01) with a primary IP attached. The Site and DeviceType are created once and reused on every subsequent Hetzner server in the same datacenter.

Mappings are not hardcoded. The field translation logic lives in the orchestration layer between the source DADL and the NetBox DADL. You can override mappings, add custom fields, or skip objects entirely — if your servers encode a role in the hostname (web-fra-01, db-fra-02), a small transform sets device_role accordingly. Dependencies are resolved automatically: prerequisite objects get created before the main record.

The Trust Escalation Model

Blindly syncing cloud inventory into a production NetBox is a reasonable thing to be nervous about. The approach we recommend is graduated trust — start with zero risk and escalate as confidence grows. None of this is a bespoke CLI; it all runs as natural-language prompts to Claude (or any agent) with ToolMesh connected. The examples below are the actual prompts.

Phase 1: Initial Import (empty database). Before any devices can be created, NetBox needs a minimal scaffold: at least one Site (devices must belong to one), a Manufacturer for device types, and ideally a Tenant for organizational grouping. Give Claude the facts about your infrastructure and let it set things up:

Set up NetBox for my company. Our tenant is “Acme GmbH”. I run infrastructure in two regions: Linode Frankfurt (eu-central) and Linode Amsterdam (nl-ams) — create those as Sites under a region called “Europe”. The Manufacturer for all Linode instances is “Akamai/Linode”. Once that’s in place, import all my Linode instances as Devices, create the matching Device Types (g6-standard-2, g6-standard-4, etc.) on the fly, and attach their public IPv4 and IPv6 addresses. NetBox is empty, so no dry-run needed — just do it and show me a summary when done.

Claude calls the Linode tools to list instances, the NetBox tools to create sites, tenant, manufacturer, device types, devices, and IPs in the right order. The summary at the end tells you how many of each were created.

Phase 2: Read-only Diff. Once NetBox has data, the next check asks what would change without touching anything:

Compare my current Linode instances with what’s in NetBox. Don’t change anything — just tell me the differences in plain English.

The response is prose, not a machine diff:

I compared 23 Linode instances against the 22 devices in NetBox tagged source=linode. Four differences:

New instance: db-ams-04 exists at Linode (region nl-ams, type g6-standard-4, created yesterday) but isn’t in NetBox yet.

IP change: web-ams-01 has a new primary IPv4 in NetBox (172.104.x.12) but Linode now reports 172.104.x.47. Looks like it was rebuilt.

Status drift: worker-ams-03 is marked active in NetBox, but Linode reports it as offline (powered off 6 days ago).

Missing at source: legacy-bastion-ams exists in NetBox but is no longer at Linode. Probably decommissioned — worth confirming before I touch it.

Want me to apply 1–3 and flag 4 for your review?

This is where most of the trust gets built. You see exactly what would happen, in language you can audit at a glance.

Phase 3: Reconcile with Confirmation. Apply the changes with a human in the loop on anything destructive:

Go ahead with 1, 2, and 3. For anything that deletes or marks a device as decommissioned, ask me first.

Creates and updates happen straight away; the legacy bastion triggers a confirmation prompt (“Delete legacy-bastion-ams from NetBox, or mark it decommissioning and keep the record? [delete / decommission / skip]”) before anything irreversible happens. Destructive operations always require explicit confirmation, even once the workflow is automated.

Phase 4: Scheduled Sync. Once the mapping is trustworthy, hand the workflow to a scheduled agent:

Every hour, pull the current Linode state and reconcile it with NetBox. Apply additions and field updates automatically. For anything that would delete a device or change its status to decommissioned, open a ticket in our tracker instead of acting — I’ll review those manually.

ToolMesh runs the prompt on the schedule, the agent does the same work it did interactively, and destructive actions stay gated on human review. New servers appear in NetBox minutes after provisioning. Every tool call lands in the audit log, so you can always ask later what got changed, when, and why.

What’s Next

The NetBox DADL connector covers most of the NetBox 4.x REST API. Source connectors for Hetzner Cloud, Linode, Xen Orchestra, Unifi, and Tailscale are available today. If you run infrastructure that is not covered yet, a new DADL file takes minutes, not days — check the DADL registry for existing definitions or contribute on GitHub.

The real payoff lands after the import. A populated NetBox is not just documentation — it becomes the substrate an AI agent can reason over. “Which servers in Falkenstein are running kernel 5.x and need a reboot window next Tuesday?” is a NetBox query plus a ToolMesh tool call, not a week of shell scripts. That is why we started here: NetBox is the map, ToolMesh is how agents read and redraw it safely.

For the strategic angle, read the full analysis on dunkel.cloud.

Introducing ToolMesh — The Missing Control Layer for AI Agents

Tue, 07 Apr 2026 00:00:00 GMT

AI agents are reaching production systems faster than security and governance can keep up. Teams connect agents to CRMs, cloud APIs, internal databases, ticketing systems, and IoT devices — but the infrastructure between the agent and those systems is still held together with environment variables and good intentions.

The typical setup looks like this: an MCP server has direct access to API keys, every connected agent gets full access to every tool, and there is no record of what was called, when, or by whom. That works for a prototype. It does not work when the agent talks to Stripe, your HR system, and your cloud provider in the same session.

The problem compounds in enterprises. Organizations run dozens of backend systems across teams and departments. Each one needs its own integration, its own credentials, its own access policy. Without a central control layer, every new agent connection is a new unaudited trust relationship — and the attack surface grows with each one.

ToolMesh is our answer to that gap.

What ToolMesh is

ToolMesh is the missing control layer between AI agents and enterprise systems. It sits between AI agents and backend systems, turning uncontrolled tool calls into a governed, auditable process — and connecting any REST API or MCP server in minutes, not months.

Every tool call flows through a strict pipeline: Auth → AuthZ → Credential Injection → Execution → Output Gate → Audit. If any step does not explicitly allow the request, nothing happens. The model never sees raw secrets. Every call is logged. Output can be filtered before it reaches the agent.

It runs as a single binary or Docker container. It is Apache 2.0 licensed. There is no SaaS dependency.

The six pillars

ToolMesh is built around six concerns that most agent setups handle inconsistently or not at all.

1. Authentication

ToolMesh supports OAuth 2.1 with PKCE for interactive clients like Claude Desktop, API keys for programmatic access, and multi-user setups via a users.yaml configuration. Every request is authenticated before it enters the pipeline.

For quick starts, a single environment variable is enough. For production, you get per-user identity with roles, plans, and company context — without changing the architecture.

2. Authorization

Access control is per-tool and per-user, powered by OpenFGA. DADL tools declare an access level — read, write, admin, or dangerous — and policy files map those levels to roles. If the caller is not authorized for that specific tool, the request is denied before execution.

ToolMesh also tracks CallerClass: which AI client triggered the request. A local Claude Code session can have different permissions than a hosted agent or a CI bot hitting the same API. Same backend, different trust levels, enforced automatically.

3. Credential Store

This is the concern most setups quietly ignore. In a typical MCP configuration, API keys sit in client configs or environment variables — visible to the model, scattered across machines, impossible to rotate centrally.

ToolMesh injects credentials at runtime, server-side. The model sees the tool interface and the filtered result. It never sees the token, the key, or the session cookie. Credentials are referenced by name in the DADL file and resolved from the credential store at execution time.

The default store reads from environment variables. The architecture supports pluggable backends for centralized secret management (planned: Infisical, HashiCorp Vault).

4. Output Gate

Not every API response should reach the model unchanged. Customer records may contain PII. Internal systems may return metadata that is irrelevant or sensitive. Error messages may leak infrastructure details.

The Output Gate runs JavaScript policies (via the goja engine) that can validate inputs before execution and filter outputs afterward. Use cases range from PII redaction to compliance filtering to rejecting dangerous inputs entirely. Policies are reviewable code, not black boxes.

5. Execution

ToolMesh connects two types of backends:

DADL backends describe REST APIs declaratively in YAML. A .dadl file defines endpoints, parameters, authentication, error handling, pagination, and retry logic. ToolMesh turns that description into MCP tools at runtime — no custom server code needed. The public DADL registry currently includes definitions for 14 APIs covering 1,100+ tools across providers like GitHub, Cloudflare, GitLab, Stripe, DeepL, Hetzner Cloud, and others.

MCP server backends connect existing MCP servers via HTTP or STDIO transport. If you already have a working MCP server, ToolMesh wraps it with the same authorization, credential, and audit pipeline.

Both types go through the same fail-closed pipeline. The backend type is an implementation detail — the security guarantees are the same.

6. Audit Trail

Every tool call is recorded: who called it, which tool, with what parameters, what the result was, how long it took, and whether it succeeded. ToolMesh ships with two audit backends — structured logging via slog for simple setups, and an append-only SQLite store for queryable compliance audits.

When someone asks “what did that agent do last Tuesday,” you can answer with a SQL query instead of a shrug.

DADL: declare instead of code

The integration problem in agent tooling is not the protocol. MCP solved that. The problem is that every new API still requires a new MCP server — a new codebase, a new runtime, a new maintenance burden. Most teams stop after a handful of integrations because the per-API cost is too high.

DADL (Declarative API Description Language) takes a different approach. Instead of writing a custom server for each API, you describe the API in YAML:

backend:
  name: deepl
  type: rest
  base_url: https://api.deepl.com/v2

  auth:
    type: bearer
    credential: deepl_auth_key

  tools:
    translate:
      method: POST
      path: /translate
      access: write
      description: "Translate text into a target language"
      params:
        text: { type: array, in: body, required: true }
        target_lang: { type: string, in: body, required: true }

That is a complete tool definition. ToolMesh handles authentication, parameter mapping, error handling, retries, and credential injection at runtime.

Because DADL is compact and declarative, LLMs can generate working definitions from existing API documentation. Most of the 14 definitions in the registry were produced by Claude from API docs in under a minute, then reviewed and tuned. The format is designed to be AI-native: easy for machines to produce, easy for humans to review.

We wrote a separate deep-dive on this: Stop Rebuilding REST API Wrappers for MCP.

Code Mode: scaling that otherwise doesn’t work

Connect 15 MCP servers to a single AI agent? Without ToolMesh, that simply does not work — the context window fills up, the client chokes. With ToolMesh, it is not a problem.

Instead of exposing hundreds of individual MCP tools, ToolMesh exposes two meta-tools: list_tools and execute_code. The model gets a compact TypeScript interface description (~1,000 tokens instead of 50,000+) and writes JavaScript against it. One code block can chain multiple API calls in a single round-trip.

That is the difference between “doesn’t work” and “just runs.”

Self-hosted, open source

ToolMesh is Apache 2.0 licensed. The binary is self-contained — no external dependencies for the core feature set. docker compose up gets you a running instance with OAuth, audit logging, and a set of DADL backends.

There is no cloud dependency. Your credentials, your audit logs, your policies — all on your infrastructure. The core is and will remain open source.

Get started

The fastest path from zero to a working setup:

Clone the repo and run docker compose up
Configure your MCP client to point at ToolMesh
Make your first tool call

The Getting Started guide walks through this in detail. The Architecture overview explains how the pipeline works. The DADL registry has ready-to-use definitions for 14 APIs.

ToolMesh is on GitHub. Issues, feedback, and DADL contributions are welcome.

Stop Rebuilding REST API Wrappers for MCP

Fri, 03 Apr 2026 00:00:00 GMT

Every REST-to-MCP wrapper starts the same way. You pick an API, open the docs, and begin writing glue code. Authentication, parameter mapping, error handling, pagination, retries, response shaping. Two hundred lines later, you have one integration. Then you do it again for the next API.

The real cost is not the 200 lines. It is reimplementing execution policy — credential handling, access control, audit logging — around every single wrapper. That work is expensive, repetitive, and difficult to scale.

DADL takes a different approach: instead of writing a custom wrapper for every REST API, you describe the API declaratively. ToolMesh turns that description into tools and handles runtime concerns — including the ones most wrappers quietly ignore: credential isolation, authorization, and audit logging.

The wrapper you keep rebuilding

Here is a minimal MCP server for a single DeepL translation endpoint in TypeScript. Stripped down — no tests, no retries, no pagination, no rate limiting:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

const API_KEY = process.env.DEEPL_API_KEY;
if (!API_KEY) throw new Error("DEEPL_API_KEY required");

const server = new Server(
  { name: "deepl-mcp", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "translate",
      description:
        "Translate text into a target language. " +
        "Supports up to 50 texts per request.",
      inputSchema: {
        type: "object",
        properties: {
          text: {
            type: "array",
            items: { type: "string" },
            description: "Array of texts to translate",
          },
          target_lang: {
            type: "string",
            description: "Target language code (EN-US, DE, FR ...)",
          },
          source_lang: {
            type: "string",
            description: "Source language code. Omit for auto-detect",
          },
          formality: {
            type: "string",
            enum: [
              "default",
              "more",
              "less",
              "prefer_more",
              "prefer_less",
            ],
          },
        },
        required: ["text", "target_lang"],
      },
    },
  ],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name !== "translate") {
    throw new Error(`Unknown tool: ${request.params.name}`);
  }

  const { text, target_lang, source_lang, formality } =
    request.params.arguments;

  const body = { text, target_lang };
  if (source_lang) body.source_lang = source_lang;
  if (formality) body.formality = formality;

  const res = await fetch("https://api.deepl.com/v2/translate", {
    method: "POST",
    headers: {
      Authorization: `DeepL-Auth-Key ${API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  });

  if (!res.ok) {
    const err = await res.text();
    return {
      content: [{ type: "text", text: `DeepL error ${res.status}: ${err}` }],
      isError: true,
    };
  }

  const data = await res.json();
  return {
    content: [{ type: "text", text: JSON.stringify(data, null, 2) }],
  };
});

const transport = new StdioServerTransport();
await server.connect(transport);

That is 90 lines for a single endpoint — already stripped to the minimum. No retries. No rate limit handling. No pagination. No structured error mapping. And the API key lives in an environment variable, where credentials are often distributed across client and server configs without centralized governance.

A production-grade wrapper with multiple endpoints, proper error handling, retry logic, and rate limiting easily grows past 200 lines — plus a package.json, a build step, and a process to keep running.

Now multiply that by every API you want to connect.

The same integration in DADL

Here is the same DeepL translation tool described in DADL:

backend:
  name: deepl
  type: rest
  base_url: https://api.deepl.com/v2
  description: "DeepL translation API"

  auth:                              # ← credential injection handled by ToolMesh
    type: bearer
    credential: deepl_auth_key       #   references a server-side secret, never exposed to the model
    prefix: "DeepL-Auth-Key "

  defaults:
    errors:                          # ← retry and error handling for all tools
      retry_on: [429, 502, 503, 529]
      retry_strategy:
        max_retries: 3
        backoff: exponential
        initial_delay: 1s

  tools:
    translate:
      method: POST
      path: /translate
      access: write                  # ← access classification for authorization
      description: "Translate text into a target language"
      params:                        # ← parameter mapping: type, location, validation
        text:
          type: array
          in: body
          required: true
          description: "Array of texts to translate"
        target_lang:
          type: string
          in: body
          required: true
          description: "Target language code (EN-US, DE, FR)"
        source_lang:
          type: string
          in: body
          description: "Source language. Omit for auto-detect"
        formality:
          type: string
          in: body
          description: "default, more, less, prefer_more, prefer_less"

40 lines of YAML. No code. No build step. No custom server runtime to build and operate.

But shorter is not the point. The point is what happens at runtime.

The control layer you are not building

Most hand-rolled wrappers focus on one thing: making an API callable. They get the request out the door and the response back. That is necessary, but it is not sufficient for production.

The harder questions are: Who is allowed to call this tool? Where do the credentials live? What happens to sensitive data in the response? Is there an audit trail?

With a custom wrapper, those concerns either get bolted on after the fact or quietly ignored. With DADL and ToolMesh, they are the default:

Concern	Custom MCP wrapper	DADL + ToolMesh
Credentials	In client config, visible to the model	Injected server-side at runtime, never exposed
Authorization	Typically none — full access for everyone	Per-tool, per-user access control
Audit logging	Not built in	Every call logged and queryable
Output filtering	Not built in	Policies can redact sensitive data before it reaches the model
Retries	You implement backoff logic	Declared in `retry_strategy`, handled by runtime
Pagination	You build cursor/offset logic	Configured via `pagination.strategy`
Error handling	You parse responses manually	Structured via `errors.message_path`
Deployment	Build, package, run a process	Drop a `.dadl` file into ToolMesh

DADL describes what this API is. ToolMesh handles how calls to it are executed and controlled. That separation is the architectural shift that matters — not just the line count.

You do not write it — your LLM does

DADL was designed to be AI-native. The format is compact, declarative, and close to the structure of existing API specifications.

That means you can hand your LLM an OpenAPI spec, a Swagger definition, or even raw API documentation and ask it to produce a DADL file. In most cases, the result is usable on the first pass. Review it, adjust edge cases, deploy.

Compare that to asking an LLM to generate a complete MCP server. The model has to produce working code — imports, type definitions, error handling, transport setup, build configuration. Every line is a potential bug. The output needs testing, debugging, and manual validation before it goes anywhere near production.

With DADL, the LLM produces a data structure. If a field is wrong, you fix one line of YAML. If a parameter is missing, you add three lines. When something breaks, it is more often a reviewable spec issue than an opaque runtime exception buried in generated integration code.

That is the real unlock. DADL is not just easier for humans to write. It is dramatically easier for AI to produce correctly.

How this scales

The DeepL example above covers a single endpoint. Real APIs have dozens.

The full DeepL DADL definition covers 13 tools — translate, document upload, document status, glossaries, text improvement, language lists, usage tracking — in under 500 lines of YAML. The GitHub definition covers 202 tools: repositories, issues, pull requests, commits, code search, and more. Building that as a hand-coded MCP server is not a weekend project. It is a product.

As of today, the DADL registry contains 11 backend definitions with 985 tools across APIs like GitHub, Cloudflare, Hetzner Cloud, Linode, GitLab, and others. Each one is a single reviewable YAML file.

As the number of tools grows, there is another scaling concern: context window overhead. ToolMesh addresses this with Code Mode, where the model works through two meta-tools — list_tools and execute_code — instead of carrying hundreds of tool definitions directly in context. That keeps tool discovery efficient regardless of how many backends are connected.

What DADL does not do

DADL is a declarative format for describing REST APIs. It is not a workflow engine, not a general-purpose programming language, and not a replacement for every kind of MCP server.

If your integration needs custom business logic, complex multi-step orchestration, or non-REST protocols, a custom server is still the right choice. ToolMesh can work with those too — it connects both DADL-described backends and existing MCP servers.

But for the large class of integrations that are fundamentally “call a REST API with the right auth and parameters” — and that is most of them — a custom wrapper is a poor default. It duplicates infrastructure concerns, spreads control logic across codebases, and creates maintenance work that adds no unique value.

The shift

The MCP ecosystem solved the protocol problem. Clients and hosts speak the same language.

But protocol standardization did not make backend integration cheap. Every new API still meant a new server, a new codebase, a new runtime, a new maintenance burden. That is why most teams stop after a handful of integrations and the long tail of useful APIs stays disconnected.

DADL changes the unit of work. Instead of “build a server,” the task becomes “describe the API.” Instead of a software project per integration, you get a reviewable YAML file per backend — executed through a runtime that handles security, credentials, and governance centrally.

That is not just less code. It is less variance, less risk, and a fundamentally better default for connecting AI agents to real systems.

Explore the DADL registry, check out the ToolMesh documentation, or browse the source on GitHub.

Why MCP Gateways Alone Don't Solve the Real Problem

Thu, 02 Apr 2026 00:00:00 GMT

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.