ToolMesh | Blog

Reconciling a UniFi site against NetBox in one prompt

Sat, 20 Jun 2026 00:00:00 GMT

A source of truth is only true until someone touches the network. Swap an access point, let DHCP hand out a new management address, add a unit in a back room, and the controller is immediately right while NetBox is quietly wrong. Nobody catches that by hand-diffing ten devices every week, so the documentation drifts and the trust in it drifts with it.

The usual answer is a sync script. We wanted to give one instruction instead:

No pipeline. No field mapping spelled out. When the network changes next month, the same sentence runs again.

What happens underneath

The agent talks to two backends through one gateway: it reads the live UniFi controller and reads and writes NetBox, and every call goes through the gateway’s audited, policy-gated surface rather than a shell or a stored admin token. In Code Mode it is a short script the model writes itself, and its shape is a comparison, not a bulk import:

const site = "23by5njv";                           // desc: "HOME"
const live = await toolmesh.unifi_list_devices({ site });

for (const ap of live) {
  const model = MODEL_MAP[ap.model] ?? ap.model;   // U7PG2 -> "UniFi AC Pro Gen2", etc.
  const [nb]  = await toolmesh.netbox_list_devices({ name: ap.name });

  if (!nb) {                                        // new device -> create
    await toolmesh.netbox_create_device({ name: ap.name, device_type: typeId(model), role: AP, site: LII });
    log("created", ap.name);
  } else if (mgmtIp(nb) !== ap.ip) {               // moved address -> update one field
    await toolmesh.netbox_update_device(nb.id, { primary_ip4: ipId(ap.ip) });
    log("updated mgmt IP", ap.name, mgmtIp(nb), "->", ap.ip);
  } else {
    log("ok", ap.name);                            // already matches -> write nothing
  }
}

Two things in there are worth pulling out, because they are where reconciliation is harder than import.

The model codes are not product names. To decide whether a UniFi device already matches its NetBox record, the comparison has to normalize what the controller reports. UniFi returns each device as an internal code: U7PG2 is the UAP-AC-Pro (the 7 has nothing to do with Wi-Fi 7), UAL6 is a U6 Lite, U7NHD a nanoHD, U6EXT a U6 Extender, U7PRO an actual U7 Pro, and US8P60 the US-8-60W switch. That translation table is the difference between “this AP is already correct” and a duplicate device created next to the real one.

“Leave correct records alone” is the load-bearing clause. Every branch above is a get-or-create-or-update. A matching device produces a write of nothing. That is what makes the sentence safe to run on a schedule against a NetBox that already has data, instead of a one-time import you never dare repeat.

What this run actually did

We ran it against the live controller. Here is the real result, not a constructed one:

reconcile HOME -> NetBox (site LII)
  AP-Kueche               U7NHD    192.168.100.43    ok
  AP-Praxis               U7NHD    192.168.100.46    ok
  AP-Labor                U7PG2    192.168.100.41    ok
  AP-Buero                U7NHD    192.168.100.44    ok
  AP-Garage               U7PG2    192.168.100.42    ok
  AP-U7-Pro Heizungsraum  U7PRO    192.168.100.154   ok
  AP-U6-Extender          U6EXT    192.168.100.199   ok
  AP-Mobil                UAL6     192.168.100.47    ok
  AP-Wohnzimmer           U7PG2    192.168.100.45    ok
  UbSwi-01                US8P60   192.168.100.183   ok
  -- 10 checked, 10 matched, 0 written.

Nine access points across five models and one PoE switch, every device already present, every management IP still matching, the IoT VLAN and the management prefix already in place. Net change to NetBox: zero.

That is the anticlimax that is actually the point. An agent that writes nothing when nothing has drifted is precisely the property that lets you point it at a CMDB you care about and run it again and again. You do not have to trust it not to clobber your data. You can watch it do nothing.

Drift is the case that earns its keep. If AP-Garage had come up on .142 instead of .42, the run would have printed one line, updated mgmt IP AP-Garage 192.168.100.42 -> 192.168.100.142, written that single record, and left the other nine reading ok. The audit log shows exactly which field changed, on which device, run by which account, with no diff to read through.

The definitions need the same scrutiny

Reconciling the devices keeps the inventory honest. The device-type definitions behind them do not get checked by a name-and-IP pass, and they drift in their own way. This run was a good moment to catch one: the U7 Pro in the boiler room was linked, correctly, to a device type whose slug matched, but that type was still labelled “AC Pro, 802.11ac”. The device matched, so the reconciliation would not flag it; the label was simply wrong, since the model code and the unit’s Wi-Fi 7 firmware say otherwise. We corrected it in the same session. A source of truth is only as good as the definitions it points at, and those deserve a deliberate look rather than an assumption.

”I have done this with Nornir for years”

You have, and it works. The difference is that there is no script here to maintain. The mapping table lives in the model’s context, the instruction is plain language, and “also reconcile the client list” or “skip the guest SSID” is a change to the sentence, not to a codebase and its tests. When Ubiquiti renames a model code in a controller update, you fix one line of a prompt.

Try it against your own controller

The UniFi and NetBox connectors are open: DADL, one YAML file per API, behind an Apache-2.0 gateway. Clone it and point it at your own controller and your own NetBox. If you would rather have it run as a managed instance, talk to us at vertrieb@dunkel.cloud. Questions and war stories are welcome in GitHub Discussions.

Tool Discovery for 4,800 MCP Tools — Without a Vector Database

Thu, 11 Jun 2026 00:00:00 GMT

On our production ToolMesh instance, asking discover_tools for everything NetBox-related returned about 320 KB of TypeScript declarations. That is roughly 80,000 tokens — for many models half the context window, spent before the agent has called a single tool. Asking for all tools would have produced output on the order of 2 MB.

Nobody designed it to do that. It grew into it.

How a discovery call gets to 320 KB

ToolMesh is a self-hosted MCP gateway that speaks Code Mode: backends are exposed as flat JavaScript functions (toolmesh.netbox_list_devices(...)), and a discover_tools meta-tool returns TypeScript signatures so the model can write correct calls. With a handful of backends, returning every matching signature is exactly right.

Our instance is no longer a handful. It runs 49 backends with 4,767 tools: NetBox alone contributes 608, two MikroTik switches 297 each, two OPNsense firewalls 292 each, GitHub 203, Cloudflare 200. Each full signature averages ~530 bytes — NetBox list endpoints carry a dozen or more filter parameters.

Three effects compound at this scale:

Full declarations are the only output mode. Every match renders with its complete parameter list.
The search regex matches names and descriptions. A pattern like device fans out across NetBox, UniFi, MikroTik, and Shelly at once.
Multi-instance backends share prefixes. Searching mikrotik returns both switches — 594 declarations.

So a perfectly reasonable agent query — “show me the NetBox tools” — detonates the context window.

The fix everyone expects

The reflexive 2026 answer is: embed the tool descriptions, put them in a vector database, do semantic retrieval. We run that pattern elsewhere and it earns its keep there.

For this problem we deliberately said no, for three reasons.

The corpus is tiny and static. ~4,800 short, well-named, well-described documents that only change on a config reload. That is an in-memory index rebuilt in milliseconds — not a persistence problem. Adding PostgreSQL/pgvector to a single-binary, self-hosted Go gateway to search five thousand strings is infrastructure out of all proportion. Even the lean path — an embedded ONNX model — drags in a native runtime library, which is real packaging pain for software other people deploy themselves.

The vocabulary is already aligned. Tool names and descriptions are written for LLM consumption. Lexical ranking has excellent material to work with.

Most importantly: the agent is the semantic layer. An LLM that sees a compact, ranked result list with an honest summary line reformulates its own query in one turn. It does not need a perfect search. It needs a cheap iteration loop and feedback about what it is looking at.

What we shipped instead

Three changes, all in ToolMesh v0.3.1+, zero new dependencies.

1. Output that degrades before it detonates

discover_tools now scales its detail level to the number of matches: up to 25 matches return full TypeScript signatures, up to 250 return one-line summaries, up to 2,000 return names only, and anything beyond that returns per-backend counts. A detail parameter overrides the automatic choice, and a hard 50 KB cap backstops every tier.

The former 2 MB worst case — no filter at all — now answers in about 1.5 KB:

// ToolMesh tools — per-backend overview
rest:netbox — 608 tools
rest:mikrotik-sw-lii-labor-perlman — 297 tools
rest:mikrotik-sw-mikrotik-10g — 297 tools
rest:opnsense_backup — 292 tools
...

// ── 4767 of 4767 tools matched — detail: overview (auto).
// Refine: narrower pattern, query:"<free text>" for ranked results,
//         detail:"full"|"summary"|"names"|"overview", limit:N.

That footer is the most important line in the feature. Every response states how much of the catalog matched, how much is shown, and how to refine. The agent never mistakes a truncated view for the whole world — and it self-corrects in the next call instead of guessing.

2. Ranked free-text search — BM25 in ~200 lines of Go

Regex patterns are great for exact lookups (^netbox_list), bad for exploration. The new query parameter does ranked free-text search:

discover_tools({ query: "create dns record for a zone" })

returns the top 25 by relevance — Cloudflare, INWX, and Linode DNS tools, in that mixed order, with no NetBox noise. Under the hood is a plain BM25 index over tool names (boosted), descriptions, and parameter names — about 200 lines of dependency-free Go, rebuilt per call in microseconds. Parameter names being indexed means a query like rack_id finds netbox_list_devices even though “rack” appears nowhere in the tool name.

BM25 is fifty-year-old information retrieval. That is not a weakness; at this corpus size it is the entire point.

3. Discovery inside the sandbox

The biggest structural win: agents no longer need a separate discovery round-trip at all. Inside execute_code, two local helpers are available:

// find → inspect → call, in ONE round trip
const hits = toolmesh.discover("move task to kanban bucket", 5);
const schema = toolmesh.describe(hits[0].name);
return await toolmesh[hits[0].name]({
  project_id: 2, view_id: 8, task_id: 200, bucket_id: 5
});

toolmesh.discover() and toolmesh.describe() run against the in-memory index — no backend call, no context cost beyond what the code explicitly returns, exempt from the per-execution call budget, and filtered by the caller’s authorization like every other surface. Discovery becomes something the code does, not something the context pays for.

What live testing caught within twenty minutes

We deployed the branch to production and drove it from a real agent session. Two bugs surfaced almost immediately — both invisible to unit tests:

A stale client schema turned limit into a string. The MCP client had cached the old discover_tools schema, so it serialized the unknown parameter limit: 5 as the string "5" — which the server silently ignored. Clients you do not control will hold stale schemas; agent-facing parameters now accept numeric strings.

Summaries truncated at “e.g.” The one-line summarizer cut at the first period-plus-space, producing Set device key properties (e.g. — a period now only ends a sentence when followed by an uppercase letter.

Neither is glamorous. Both are the difference between a feature that demos well and one that survives contact with real clients.

Prior art, and what changes at scale

Progressive disclosure for tools is not our invention. Anthropic’s code execution with MCP post describes loading tool definitions on demand; Claude Code defers tool schemas until needed; Cloudflare’s Code Mode made the write-code-against-tools pattern mainstream. The pattern is settling into consensus.

What production scale adds is the parts that rarely show up in demos: ranking (because 764 candidates match “dns” somewhere), an always-on feedback line (because agents refine well but only when told what they saw), hard output caps (because some client will always ask for everything), and in-sandbox discovery (because the cheapest context is the one never spent).

What’s next

The same index has two more consumers coming: a capability index for nested Code Mode backends — MCP servers that themselves only expose search/execute, whose capabilities ToolMesh will probe and index at registration — and synthetic tool descriptions generated from it at the MCP layer. And if real-world vocabulary misses ever justify it, an optional embedding channel can slot in behind the same query API — measured first, added second.

The implementation is open source (PR #80, Apache 2.0). The tool definitions it searches come from DADL — one YAML file per API, 25+ ready-made in the registry.

If you run an MCP setup that has outgrown its tool list: we would genuinely like to hear what discovery looks like at your scale — GitHub Discussions or presse@dunkel.cloud.

From Switch Config to NetBox in One Prompt

Mon, 01 Jun 2026 00:00:00 GMT

The situation

You run NetBox as your source of truth. It is good, until it isn’t.

Last Tuesday someone swapped a switch in rack B. They added two VLANs, renamed a couple of interfaces, and moved an uplink. NetBox knows none of it. Now your IPAM is quietly wrong, your cable map lies, and the next person who trusts NetBox to plan a change is going to have a bad afternoon.

The usual fix is a sync script. You write a few hundred lines that pull the live config, diff it against NetBox, and push the deltas. It works. Then the vendor ships a firmware update, an interface naming scheme changes, you add a second switch model, and now you maintain the script as carefully as the network it describes.

There is a different shape to this.

The instruction

Here is what the task looks like when the tooling carries the connectivity and you carry the intent:

Read the live configuration from the perlman switch. Compare its interfaces, IP addresses and VLANs against what NetBox has for that device. Tell me every difference, then update NetBox to match the switch — but stop and show me anything that looks like a removal before you delete it.

That is the whole thing. No script. Tomorrow the instruction is “…and also reconcile rack B’s MikroTik while you’re at it” and nothing in your codebase has to change, because there is no codebase. The instruction is the automation, and it is disposable by design.

What actually happens underneath

This is not magic, and the point of this series is that you can see exactly what runs. The agent has two tool surfaces in front of it, both served through a single ToolMesh endpoint:

the MikroTik switch, described by a DADL file — about thirty lines of YAML turn its REST API into callable tools like export_config, list_interfaces and list_ip_addresses
NetBox, the same way — netbox_get_device, netbox_create_interface, netbox_create_ip_address, netbox_update_*

In Code Mode the model does not fire one tool call per round-trip. It writes a short piece of JavaScript that runs server-side and only returns the result:

// pull live state
const live = await toolmesh.mikrotik_perlman_list_interfaces({});
const liveIps = await toolmesh.mikrotik_perlman_list_ip_addresses({});

// pull NetBox's view of the same device
const device = await toolmesh.netbox_get_device({ name: "perlman" });
const nbIfaces = await toolmesh.netbox_list_interfaces({ device_id: device.id });

// diff happens here, in code, not in the model's head
return diff(live, liveIps, device, nbIfaces);

One execution, one result back to the model. A catalogue of eighty NetBox tools plus the switch’s tools would cost roughly 142,000 tokens to advertise on every reasoning step if you listed them all as JSON schemas. Code Mode keeps that closer to a thousand, flat, no matter how many backends you add. That is the difference between “this is neat in a demo” and “I can leave this running against my real network.”

The parts you’d worry about, handled

Nothing deletes silently. The instruction said stop and show me removals, and that is enforced at the gate, not just left to the agent’s good intentions. Two core mechanisms do it. Authorization comes first: through OpenFGA, an agent can hold netbox_create_* and netbox_update_* but never netbox_delete_* — the delete tools are simply never unlocked for it. And the ExecuteTool() pipeline runs a Pre-Gate before any call reaches the backend, where a short hard rule — plain JavaScript — refuses anything matching netbox_delete_*. The pipeline is fail-closed: if a rule can’t decide, the call is denied, not waved through. Creates and updates flow; deletions are refused at the gate, so the agent shows you the removals it found and changes none of them. You write that once, and it holds for every prompt you ever run.

No credentials in the prompt. The switch’s API token and the NetBox token never reach the model. They live in ToolMesh’s credential store and get injected at call time. The model orchestrates; it never sees a secret.

You can prove what happened. Every call lands in a structured audit log — which tool, which device, what changed, how long it took, success or denied. When someone asks in three weeks why interface sfp-sfpplus3 got renamed, the answer is a query, not an archaeology project.

What this is, and what it isn’t

If your reaction is “I’ve done config-to-NetBox with Nornir for ten years” — you have, and well. The claim here is not that this is more powerful than a purpose-built script. It’s that there is no script to maintain. The reconciliation logic isn’t pinned to one vendor, one naming scheme, or one NetBox version. The instruction adapts to the situation in plain language; the tools underneath are declared in YAML you can diff in Git. When the situation changes, you change a sentence, not a pipeline.

That is the whole bet: network state changes constantly, so the layer that reconciles it should be the cheap, disposable part — not the part you babysit.

Want to try it on your own network?

The honest friction here is setup: standing up ToolMesh, writing the DADL for your switch, wiring NetBox. If that friction is the thing stopping you, skip it. ToolMesh is an offering of Dunkel Cloud GmbH, and we will set up a personal instance for you on its own VM — you keep full control and your own credentials, we just do the initial wiring so you can point it at your gear and see whether the reconciliation actually holds up against your reality.

That offer is genuine, and it is the fastest way to find out if this fits how you work.

This is post 1 of a series on driving NetBox from real infrastructure: MikroTik, OPNsense, Xen Orchestra, Hetzner, vSphere, and UniFi. Each one is a real workflow from our own stack, not a contrived demo.

ToolMesh is open source (Apache 2.0). DADL is an open spec (CC BY-SA 4.0) with a public registry at dadl.ai.

Xen Orchestra 6.5's Full REST API — 245 Tools from One DADL

Fri, 29 May 2026 00:00:00 GMT

Xen Orchestra has spent the last two releases turning its REST API into something you can build on. XO 6.4 (April 2026) marked /rest/v0/ as stable and added fine-grained RBAC v2; 6.5 added PATCH /vms/{id} for partial VM updates and a separate /vm-controllers collection. In February, Vates also shipped a first-party MCP server bundled with XO 6.2 — seven tools, deliberately read-only, so teams can enable it on production from day one.

We took a different cut of the same API. The DADL for Xen Orchestra covers the entire 245-endpoint REST surface — read and write — as one YAML file. This post is the build log, and an honest answer to the obvious question: why two MCP surfaces for the same product?

What the REST API now covers

The XO REST API is no longer a thin read layer. As of 6.5 it exposes the full object graph — VMs (including PATCH partial updates and snapshot revert), VM controllers, VM templates, VM/VDI snapshots, hosts, pools, storage (SR/VDI/VBD), networking (VIF/PIF/PBD), hardware passthrough (PCI/PGPU/SM) — plus every lifecycle action: power, snapshot, clone, migrate, export/import, hotplug. On top of the objects sit the operational surfaces: tasks, backups (jobs, logs, repositories, restore, schedules), real-time change events over Server-Sent Events, RBAC v2 (users, groups, acl-roles, acl-privileges), and host/pool maintenance (rolling reboot, rolling update, emergency shutdown).

That is a large API, and almost all of it mutates infrastructure. None of the write side is reachable through the first-party MCP server — by design, not by omission.

The numbers

	DADL (`xen-orchestra.dadl`)	`@xen-orchestra/mcp` (first-party)
Tools	245	7
Scope	full read and write	read-only by design
Coverage	every REST object + lifecycle action, backups, RBAC v2, SSE events, SDN traffic rules, dashboards, auth tokens	infrastructure summary, list/inspect pools / hosts / VMs, pool dashboard, documentation search
Create / start / migrate / delete?	yes	no — intentionally
Distribution	one 245-tool YAML file	Node server bundled with XO 6.2+
Tracking a new API release	~30 lines of YAML per endpoint	ships with the XO release
Governance layer	credentials, authorization, audit (via ToolMesh)	none — local, in-process

The local validation, run from the registry checkout:

> cd dadl-registry && npm run validate
✅ xen-orchestra.dadl — 245 tools

Source on GitHub: dadl-registry/xen-orchestra.dadl. Live in the registry at dadl.ai/d/xen-orchestra. The DADL spec itself: dadl.ai/spec.

A worked example: a VM change, made undoable

The point of the write side is that it actually changes infrastructure — safely, with a trail. Here is a three-call round trip: find a running VM, snapshot it so the change is reversible, then patch it.

// 1. Find the VM by name (XO filter syntax, compact fields)
const [vm] = await toolmesh.xen_orchestra_list_vms({
  filter: "name_label:web-fra-01",
  fields: "uuid,name_label,tags"
});

// 2. Snapshot first, so the change is undoable
await toolmesh.xen_orchestra_snapshot_vm({
  id: vm.uuid,
  name_label: `pre-change ${new Date().toISOString().slice(0, 10)}`
});

// 3. PATCH the live VM — tags is a hot field, applied while running (XO 6.5)
await toolmesh.xen_orchestra_update_vm({
  id: vm.uuid,
  tags: [...vm.tags, "managed:toolmesh"]
});

Three calls. No glue code. Steps 2 and 3 are exactly what a read-only MCP server cannot do — and the DADL transparently handles:

the unusual cookie-based auth (the token is injected server-side as Cookie: authenticationToken=… — the model never sees it);
the async-by-default action model — most writes return a task reference; you add sync only for short operations and poll get_task for long ones (migrate, export) to avoid HTTP client timeouts;
the cold-vs-hot field distinction on update_vm — memoryStaticMax, cpusStaticMax, secureBoot need a halted VM, while tags, nameLabel, and cpus apply live (the example uses tags, so it runs without downtime);
retries on transient failures and terminal classification for 404 (“no such VM”) and RBAC 403.

Same calls from Claude or any other agent. No Xen-Orchestra-specific code on the client side.

Read-only is a feature, not a gap

The natural framing — “245 beats 7” — is the wrong one. The two surfaces answer different questions.

The first-party MCP server is read-only on purpose. It runs in-process, ships with XO, needs no external infrastructure, and cannot break anything. If the question is “let an assistant look at my infrastructure and answer questions about it,” that is the right shape, and you should use it. We are not trying to replace it — the DADL even includes a get_mcp_status tool that reports whether XO’s own built-in MCP server is enabled.

The DADL answers a different question: “let an agent operate my infrastructure — create, patch, snapshot, migrate, back up, provision RBAC — without handing it raw admin credentials.” That only makes sense with a control layer underneath. Through ToolMesh, every one of the 245 tools runs behind centralized credentials (the XO token never reaches the model), authorization (an agent can be granted list_vms and snapshot_vm but not delete_sr), and an audit log (every call recorded with what, when, and why). The write side is the whole point, and the governance layer is what makes the write side safe to expose.

Both definitions live in the same registry. They are complements: read-only discovery in-process, full lifecycle management through a governed gateway.

Tracking the API is a YAML diff

XO 6.4 added RBAC v2; 6.5 added PATCH /vms/{id}, /vm-controllers, and a REST snapshot-revert endpoint. Reflecting each of those in the DADL is the same small unit of work: open xen-orchestra.dadl, add the tool block (~30 lines of YAML per endpoint), run npm run validate, open a PR, review the diff, merge. ToolMesh picks the new tools up on next reload. No SDK changes, no release to cut, no npm publish, no “please upgrade” to send users.

Two concrete examples from the current release:

6.5 shipped POST /vms/{id}/actions/revert_snapshot for automatable snapshot revert. The DADL already carries it as revert_vm_to_snapshot, annotated “requires XO 6.5+ (route returns 404 on older builds)” — so against an older host the agent gets a clean terminal error instead of a silent failure.
6.5 also lays groundwork for a dedicated VM administrator role. You do not have to wait for it: the DADL exposes the full RBAC v2 surface (create_acl_role, create_acl_privilege, attach_acl_role_to_user), so you can compose a least-privilege operator role today and grant an agent exactly the privileges it should hold — read on vm, host, pool, and nothing more.

We made the general version of this argument in an earlier post; XO is the concrete case study for a write-heavy API.

The context-window argument

There is a second reason the tool count matters less than it looks: Code Mode. Instead of injecting all 245 XO tool descriptions into the model’s context window, ToolMesh exposes two meta-tools (list_tools and execute_code). The model discovers what is available on demand and calls flat tool names from inside a sandboxed JavaScript runtime — toolmesh.xen_orchestra_list_vms, toolmesh.xen_orchestra_snapshot_vm, not a nested namespace.

The token cost is roughly constant: ~1 k tokens of meta-tool description, whether the registry holds one backend with 7 tools or 27 backends with 3,338. A 245-tool backend adds zero tokens to every Claude conversation that does not actively touch Xen Orchestra. That is also why the JavaScript in the worked example above is not an illustration — it is literally what the model writes to call the tools.

Honest caveats

The DADL is not a universal win. Real limits:

The SSE event stream is half-declarative. open_events_stream returns a subscription ID and the DADL describes the subscribe handshake, but the Server-Sent Events stream itself is a streaming protocol — DADL describes REST, not long-lived streams. For polling task state, get_task?wait=true long-polls cleanly; for a true real-time feed you are at the edge of what a declarative REST definition models.
VDIs cannot be renamed via REST. There is no PATCH /vdis/{id} in the API — so there is no update_vdi tool. Rename via tags or drop to the JSON-RPC API. We expose what exists; we cannot expose what does not.
SDN traffic rules need a Premium plugin. The four traffic-rule tools (add/delete_network_traffic_rule, add/delete_vif_traffic_rule) drive XO’s SDN Controller — a plugin bundled with XOA Premium, not part of the documented core REST API. Without it loaded the routes return 404, so the agent gets a clean terminal error rather than a silent no-op. The other 241 tools work against a stock REST API.
The write side needs privileges. Full coverage assumes an admin user or an RBAC v2 user with the right acl-privileges. If you only need to look, the read-only first-party server is less setup and a smaller blast radius — use it.
Every call hops through ToolMesh. For interactive operation this is invisible; for high-throughput batch jobs against XO, calling the REST API directly is faster.

DADL is good at one specific thing — making a REST API surface available to agents quickly, with a real control layer underneath. For Xen Orchestra, that surface happens to be 245 endpoints of mostly-mutating operations, which is exactly the case where a governance layer earns its keep.

What is actually different

The substantive question is not “DADL vs the first-party MCP server” — ToolMesh runs both, and they coexist in the same registry. The question is: what does it cost to give an agent the write side of an API, safely?

For a read-only server, the answer is “you don’t” — that is the deliberate trade. For a hand-coded read-write server, it costs an engineering cycle per endpoint: SDK shapes, handlers, tests, a release, an npm publish, user upgrades, plus the authorization and audit you have to build yourself. For a DADL behind ToolMesh, it costs one PR with a YAML diff, and the credentials, authorization, and audit come from the runtime.

That is the asymmetry. Not “everyone should ditch the first-party server” — keep it for read-only discovery. Just: when you need an agent to actually operate Xen Orchestra, the unit of work is a YAML diff, and the safety is in the layer underneath rather than in withholding the write tools.

Anatomy of an Enterprise Tool Library

Tue, 26 May 2026 00:00:00 GMT

Most teams reach the same wall on the same Friday afternoon. A handful of MCP servers worked fine in development. Now there are fifteen, half of them touch production, and nobody can answer the basic questions — who called what, with which credential, against which policy, and where is the log. The problem is not any single server. It is that there is no shared layer underneath them.

This post is about that layer. It describes how an Enterprise Tool Library is built: the six concerns it has to merge into one runtime, the fail-closed pipeline a tool call walks through, and the two ideas — DADL and Code Mode — that make the whole thing scale to dozens of backends without bloating the agent’s context. For the business framing in German, see the companion piece on dunkel.cloud (DE).

What an Enterprise Tool Library actually is

The term “MCP gateway” gets used for two very different things. One is a passthrough proxy that forwards tool calls to a single upstream server. The other is a governed execution layer that fronts every backend the organization owns. Only the second one is an Enterprise Tool Library.

The distinguishing property is not the number of backends. It is structural. A library has:

One authentication and authorization boundary. Every tool call — no matter which upstream system it ends up hitting — passes the same identity check and the same per-tool access decision. A single source of truth for “who is allowed to call what.”
One coherent audit line. Every call lands in the same store, with the same fields, queryable with one SQL query. Not “logs over here, MCP server logs over there, a CSV someone exported last quarter.”
One shared declarative description language. REST APIs, MCP servers, internal services — all surfaced through the same definition format, so policy, retry, pagination, and credential injection are runtime concerns instead of bespoke wrapper code.
A constant context footprint. Adding the twentieth backend does not double the tokens the agent has to carry. The cost of “more tools” is paid by the library, not by every prompt.

A single MCP server has none of these. A passthrough gateway has the first two at best, and only for one backend at a time. An Enterprise Tool Library is what you get when those four properties hold across the whole tool surface.

ToolMesh is our open-source implementation of that shape. The rest of this post walks through how the parts fit together.

The six pillars as mechanics

ToolMesh organizes the work into six pillars. Each one solves a concrete problem, lives in a specific package, and has a single config touchpoint.

1. Any Backend — two ingress paths, one runtime

The library has to front anything the organization already runs. ToolMesh supports two ingress paths into the same execution pipeline:

MCP backends wrap existing MCP servers via HTTP or STDIO transport. If you already have a working server, you keep it; ToolMesh wraps it with the governance layer.
DADL backends describe REST APIs declaratively in YAML. No custom server code, no separate runtime — the description is the integration.

Both paths register through the same internal backend.Register() interface and produce tools that look identical to the model. The backend type becomes an implementation detail; the security guarantees do not depend on it. Configuration lives in a single file:

config/backends.yaml

backends:
  - name: github
    type: rest
    file: github.dadl
  - name: cloudflare
    type: rest
    file: cloudflare.dadl
  - name: legacy-internal
    type: mcp
    transport: http
    url: http://internal-mcp:8080

Adding a backend is editing one file, not building a service.

2. Code Mode — flat tool surface, constant context

A naive MCP setup exposes every tool definition directly to the model. With one backend that is fine. With twenty it is ruinous: dozens of tool schemas, each with its own parameters and descriptions, all loaded into context before the agent has even read the user’s question. Around 50,000 tokens of pure tool metadata is a normal observation in the wild.

ToolMesh sidesteps this entirely. The model sees two meta-tools — discover_tools and execute_code — and a compact TypeScript interface describing the available functions. That interface is roughly 1,000 tokens regardless of whether one or twenty backends are attached. The agent calls discover_tools once to see the type signatures, then writes JavaScript against them:

const issues = await toolmesh.github_list_issues({
  owner: "DunkelCloud",
  repo: "ToolMesh",
  state: "open",
});
const recent = issues.filter(i => Date.now() - new Date(i.created_at) < 7*864e5);
return recent.map(i => ({ number: i.number, title: i.title }));

The execute_code runner parses that JavaScript with a Go AST walker, extracts each toolmesh.* call, and dispatches it through the normal pipeline. The model never executes arbitrary code against your infrastructure — it produces a script whose tool calls are statically extracted and authorized one by one. Code Mode is described in detail in /en/code-mode/.

3. Credential Store — runtime injection, never in prompts

The concern most setups quietly ignore. A typical MCP configuration puts API keys in client configs, env vars on developer laptops, or — worst case — directly in the model’s context. None of those rotate well, none of those audit well, and any of them can leak into a transcript.

ToolMesh references credentials by name in the DADL file and resolves them server-side at execution time. The model sees the tool interface and the filtered response. It never sees the token. The credential layer is pluggable through credentials.Register():

Tier	Backend	Use case
Embedded	Env vars (`CREDENTIAL_*`)	Local development, single-tenant
Planned	Infisical	Centralized secret management
Planned	HashiCorp Vault / OpenBao	Enterprise secret governance

The embedded backend is the default and ships in the binary. The hosted backends are planned through the enterprise build tag — the registration pattern (inspired by Go’s database/sql drivers) is already in place, so adding a backend does not require touching the executor.

4. OpenFGA — ReBAC, honest about the default

Authorization in ToolMesh is relationship-based, powered by OpenFGA. The model is user → plan → tool: users belong to plans, plans have tool entitlements, and the executor asks OpenFGA whether the caller is allowed to invoke this specific tool before anything runs.

Two modes ship today:

`OPENFGA_MODE`	Behavior
`bypass` (default)	No authorization checks. Dev-only.
`restrict`	OpenFGA enforced on every tool call. Production.

The default is bypass so that docker compose up produces a working instance without forcing every contributor through OpenFGA setup. That is a deliberate developer-experience choice, not a security claim. Production deployments switch to restrict and run ./config/openfga/setup.sh to seed the model. Defaulting to bypass is honest about where the dev surface starts; the Authorization page documents the production checklist.

5. Output Gate — deterministic JS, with room to grow

Not every response should reach the model unchanged. Customer records contain PII. Internal systems return metadata the agent does not need. Error messages occasionally leak infrastructure details.

Today, ToolMesh ships Layer 1 of the gate: deterministic JavaScript policies executed in the embedded goja engine. A policy receives the response and the caller context and returns a filtered payload or a rejection:

policies/redact-pii.js

export function onResponse(response, ctx) {
  if (ctx.user.callerClass === "trusted") return response;
  return redactEmails(redactPhones(response));
}

Policies are reviewable code committed to the repo, not black-box configuration. The gate sits on top of a pluggable evaluator registry (gate.RegisterEvaluator()) — additional layers are planned, including LLM-based content classification for compliance use cases. Today we ship one layer. We do not pretend to ship more. See /en/output-gate/.

6. Audit — slog and SQLite, SQL-queryable

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 two audit backends — Go’s structured slog for log-style setups, and an append-only SQLite store for queryable compliance audits.

When someone asks “what did that agent do last Tuesday between 14:00 and 15:00?”, the answer is a SELECT query, not a forensic exercise across five log aggregators.

The fail-closed request pipeline

The pillars matter, but their value comes from the order they run in. A single tool call walks this path:

┌─────────────────────────────────────────────────────────────────┐
│  Client (Claude Desktop / ChatGPT / CLI / hosted agent)         │
└──────────────────────────────┬──────────────────────────────────┘
                               │
                               ▼
                  ┌───────────────────────┐
                  │ 1. Authentication     │   OAuth 2.1 PKCE / API key
                  │    → UserContext      │   → identity established
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 2. Authorization      │   OpenFGA: user × plan × tool
                  │    (fail closed)      │   → allowed or DENY
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 3. Credential         │   Resolved server-side,
                  │    Injection          │   never exposed to the model
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 4. Output Gate (in)   │   Optional pre-execution check
                  │    (fail closed)      │   → allowed or REJECT
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 5. Execute            │   MCP server or REST via DADL
                  │                       │   → raw response
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 6. Output Gate (out)  │   PII redaction, shaping
                  │                       │   → filtered response
                  └──────────┬────────────┘
                             ▼
                  ┌───────────────────────┐
                  │ 7. Audit              │   Append-only, queryable
                  │                       │   → SQLite / slog
                  └──────────┬────────────┘
                             ▼
                       Back to client

The pipeline is fail-closed: if AuthZ denies, nothing executes. If the gate rejects, nothing executes. If credential resolution fails, nothing executes. The default for every uncertainty is “do not run.” This is the inverse of how most ad-hoc setups behave, where a missing check silently means “proceed.”

CallerClass — the second axis nobody else has

Most gateways treat authorization as a single axis: who is the user? That is necessary but not sufficient. The same user, asking the same question, runs at a very different trust level when they are typing into a local Claude Desktop session versus when a hosted agent is making the call on their behalf as part of a scheduled workflow.

ToolMesh treats this as a first-class concept: CallerClass, attached to every request, with three values:

CallerClass	Typical origin	Typical filtering
`trusted`	Local CLI, developer laptop	Minimal — credentials redacted only
`standard`	Authenticated user via known client	PII redaction, schema shaping
`untrusted`	Hosted agents, CI bots, third-party clients	Strict — no admin tools, aggressive redaction

CallerClass modulates two things at once: which tools are reachable at all (an untrusted caller can be blocked from admin-level tools even if the user’s plan would normally allow them) and what the Output Gate redacts before the response reaches the model. Same backend, same user, different trust envelope — enforced automatically.

This is the part that does not exist in passthrough gateways. They model the user. They do not model “who is asking on the user’s behalf.” For agent infrastructure, that second axis is where most of the real risk lives.

Worked example: adding a backend

Adding GitHub’s list_issues endpoint as a governed tool, in its entirety, is this:

# github.dadl
backend:
  name: github
  type: rest
  base_url: https://api.github.com

  auth:
    type: bearer
    credential: github_token       # resolved at runtime, never in prompt

  defaults:
    errors:
      retry_on: [429, 502, 503]
      retry_strategy:
        max_retries: 3
        backoff: exponential

  tools:
    list_issues:
      method: GET
      path: /repos/{owner}/{repo}/issues
      access: read                  # → mapped to plan entitlements via OpenFGA
      description: "List issues in a repository"
      params:
        owner:    { type: string, in: path,  required: true }
        repo:     { type: string, in: path,  required: true }
        state:    { type: string, in: query, default: open }
        per_page: { type: integer, in: query, default: 30 }
      pagination:
        strategy: link_header

Twenty-three lines. Drop the file into the registry, reference it from backends.yaml, restart. What you get for free:

Authentication — OAuth or API key on the inbound side, bearer token injection on the outbound side, both handled by the runtime.
Authorization — access: read slots the tool into the OpenFGA model; the request is denied before execution if the caller’s plan does not include it.
Credential isolation — github_token is resolved from the credential store at execution time; the model never sees the value.
Retry and pagination — declared in the description, executed by the runtime.
Audit — every call lands in the audit store with caller, parameters, status, latency.
Output filtering — the gate runs on the response before the model sees it, applying whatever policy applies to the caller’s class.

None of this is wrapper code anyone wrote for GitHub specifically. It is what the runtime does for every DADL-described tool. Building the same governance around a hand-rolled MCP server is several hundred lines of boilerplate per backend — work most teams ship without and regret later.

The companion post Stop Rebuilding REST API Wrappers for MCP goes deeper on the DADL format and what disappears when you adopt it.

Why the context footprint stays constant

Most gateways scale linearly with the number of backends — every new server adds tool definitions that ride along in every prompt. Twenty backends, twenty schema bundles, fifty thousand tokens before the user has typed a word.

Code Mode breaks that scaling. The model sees discover_tools and execute_code, plus a compact TypeScript interface that lists what is available. Adding a backend grows the interface description, but not the per-request overhead — the agent looks up tools on demand instead of carrying them all the time.

In practice, a ToolMesh instance fronting the current public DADL registry — 27 APIs, 3,338 individual tools across GitHub, Cloudflare, GitLab, Stripe, Hetzner Cloud, Linode, NetBox, DeepL and others — surfaces to the model as roughly the same context cost as a single hand-built MCP server with a dozen tools would. That ratio is the entire point. Without it, the library shape does not work at all.

Scope and honesty: built vs planned

ToolMesh is early-stage. Some of the architecture is shipped, some is in motion. Being explicit about that is more useful than being aspirational.

Shipped today:

All six pillars wired through the fail-closed pipeline
Authentication (OAuth 2.1 PKCE, API keys, multi-user via users.yaml)
Authorization (OpenFGA, bypass / restrict modes)
Credential store with embedded env-var backend
Output Gate Layer 1 (deterministic goja JS policies)
Audit via slog and SQLite
MCP and DADL backends, registry-based
Code Mode with AST-extracted tool calls

Deliberate developer defaults — switch off for production:

OPENFGA_MODE=bypass (no authorization)
Debug logging on
HTTP+TLS reverse proxy assumed in front for TLS termination

These defaults make docker compose up work cleanly in development. They are documented as not-production. The Configuration page lists every variable and its production recommendation.

Planned, registered but not yet shipped:

Infisical and HashiCorp Vault credential backends (extension point exists)
Additional gate layers (LLM-based classification, compliance filters)
Expanded DADL registry coverage (community contributions welcome)

Calling these “planned” is the right level of confidence. The registration mechanics are in place, the work to wire them in is ahead of us.

Backends in practice

This article is the architectural reference. The detailed connector walkthroughs — how to populate NetBox from cloud APIs, how to put OPNsense behind a tool layer, how to integrate the HashiCorp stack — live in their own posts. The current installments:

Populating NetBox from Real Infrastructure with ToolMesh
More to follow on OPNsense, the HashiCorp suite, and additional registry-driven integrations

If you operate infrastructure that would make a good worked example, the DADL registry is the place to start — most APIs that have OpenAPI specs can become DADL files in an afternoon.

The why, in German: dunkel.cloud — Enterprise Tool Library — business framing, not architecture
The scaling trick: /en/code-mode/ — how the context footprint stays constant
The protocol question: Why MCP Gateways Alone Don’t Solve the Real Problem — gateway vs description layer
The description layer: Stop Rebuilding REST API Wrappers for MCP — what DADL replaces
Common questions: /en/faq/ — short answers across MCP, DADL, ToolMesh
Source: GitHub — DunkelCloud/ToolMesh
Connector format: dadl.ai — registry and spec

Try it

The fastest path from this article to a running instance:

Hosted demo. Try the Demo — a managed ToolMesh with a curated set of backends, no setup.
Self-host quickstart. Clone the repo, docker compose up, point your MCP client at http://localhost:8080. The full walkthrough is in Getting Started.

An Enterprise Tool Library is not a library of tools. It is the layer underneath them that makes “any backend” a property of the runtime instead of a property of every wrapper. The six pillars, the fail-closed pipeline, and the CallerClass axis are what turn a pile of MCP servers into something an enterprise can actually operate.

DeepL v3 Customization Hub — Covered in One DADL

Fri, 22 May 2026 00:00:00 GMT

In late May, DeepL turned on the Customization Hub — 13 new REST endpoints across style rules, multilingual glossaries, translation memory, the redesigned /v3/languages resource, and an opt-in tag_handling v2 algorithm. On the morning we merged our DADL for it, the official deepl-mcp-server still exposed nine tools — all of them v2 — and the community alternative mcp-deepl was in the same shape, last released 2026-05-09. Not because anyone is slow. The unit of work for adding API coverage is fundamentally different on either side of that line, and the new release surfaces the gap clearly. This post is the build log.

What the new release added

The Customization Hub is the marketing name for an honest API expansion. DeepL now lets API consumers manage per-language style profiles (think “Brand voice — DE”), multilingual glossaries (one glossary, many source → target dictionaries), and translation memories (segment-level reuse with a configurable match threshold). /v2/translate accepts three new parameters — style_id, custom_instructions, translation_memory_id — any of which silently bumps the model to quality_optimized. The new /v3/languages endpoint replaces the old /v2/languages and exposes per-resource feature flags (formality support, glossary support, style-rules support, voice). Finally, tag_handling_version: v2 ships a much improved HTML/XML structure preservation algorithm — position-independent translation, better-preserved nesting.

That is a meaningful expansion. None of it is in the official MCP server today.

The numbers

	DADL (`deepl.dadl`)	`deepl-mcp-server` (official)
Tools	27	9
Coverage	text translation, document translation, multilingual v3 glossaries, style rules CRUD, custom instructions CRUD, TM listing, Write/rephrase, `/v3/languages`, usage	translate-text, rephrase-text, translate-document, list-glossaries, get-glossary-info, get-glossary-dictionary-entries, get-source-languages, get-target-languages, get-writing-styles
Distribution	38 KB YAML	Node.js server (TypeScript SDK, build step, runtime to host)
Adding a new endpoint	~30 lines of YAML	Tool definition + request handler + tests + release
v3 Customization Hub coverage	full	none today

The local validation, run from the registry checkout:

> cd dadl-registry && npm run validate
✅ deepl.dadl — 27 tools

Source on GitHub: dadl-registry/deepl.dadl. Merged in PR #34. The DADL spec itself: dadl.ai/spec.

A worked example: style rules end-to-end

The interesting thing about style rules is that they actually take effect — custom_instructions carry through into the model output. Here is the round trip:

const style = await toolmesh.deepl_create_style_rule({
  name: "Brand voice — DE",
  language: "de",
  custom_instructions: [
    { label: "Greeting",     prompt: "Begin every translation with 'Sehr geehrte Damen und Herren'." },
    { label: "Product term", prompt: "Render 'ToolMesh' verbatim, never translate." }
  ]
});

const r = await toolmesh.deepl_translate({
  text: ["The deployment of ToolMesh was successful."],
  source_lang: "EN", target_lang: "DE",
  style_id: style.style_id
});
// → "Sehr geehrte Damen und Herren, die Bereitstellung von ToolMesh war erfolgreich."

Two calls. No glue code. The first hits POST /v3/style_rules; the second references the result by style_id in POST /v2/translate. The DADL transparently handles:

the unusual DeepL-Auth-Key Authorization scheme (custom prefix, server-side credential injection — the model never sees the key);
the language-code casing trap (UPPERCASE for translate, lowercase for style rules — both correctly typed);
the silent model switch — passing style_id, custom_instructions, or translation_memory_id flips model_type to quality_optimized;
retries on 429 / 529 with Retry-After, and terminal classification for 400/401/403/456 (the Free-plan quota-exceeded code is 456, not 429 — a footgun in hand-coded clients).

Same call from Claude or any other agent. No DeepL-specific code on the client side.

Maintenance asymmetry

This is the part that does not show up in the tool count but shapes how quickly an integration tracks an upstream API.

Adding the v3 endpoints to the DADL:

Open deepl.dadl.
Add the new tool blocks (~30 lines of YAML per endpoint).
npm run validate — output is ✅ deepl.dadl — 27 tools.
Open a PR. Review the YAML diff. Merge.
ToolMesh picks the new tools up on next reload. Users see them.

Adding the same endpoints to a hand-coded MCP server:

Update the TypeScript SDK to model the new request and response shapes.
Add tool definitions and request handlers (one per endpoint).
Write or extend tests.
Cut a release. Tag. Publish to npm.
Tell users to upgrade. Wait for them.
Repeat for the Python SDK if you maintain one. Repeat for any downstream forks.

DADL collapses steps 1, 2, 4, 5, and 6 into “edit one YAML file.” The PR diff is a reviewable change set, not a software release. We made the general version of this argument in an earlier post; the DeepL release is the concrete case study.

The flip side worth naming: if you need behavior the runtime does not support, the YAML file does not save you. DADL is declarative — there is no escape hatch for custom orchestration. For DeepL specifically, the document-translation flow (upload_document → check_document_status → download_document) is purely sequential REST and fits cleanly. A protocol-level deviation — say, the WebSocket Voice API — would not.

The context-window argument

The other reason the tool count matters less than it looks: Code Mode. Instead of injecting every backend’s full tool list into the model’s context window, ToolMesh exposes two meta-tools (list_tools and execute_code). The model discovers what is available on demand and calls flat tool names from inside a sandboxed JavaScript runtime — toolmesh.deepl_translate, toolmesh.deepl_create_style_rule, not toolmesh.deepl.translate.

The token cost is roughly constant: ~1 k tokens of meta-tool description, regardless of whether the registry has one backend with 9 tools or 27 backends with 3,338. Tool-count-driven bloat goes away. Adding the v3 Customization Hub took the DADL from 14 to 27 tools and added zero tokens to every Claude conversation that does not actively touch DeepL.

In Code Mode, the JavaScript in the worked example above is not an illustration — it is literally what the model writes to call the tools. That is why it reads like JavaScript rather than like JSON tool-call payloads.

Honest caveats

The DADL is not a full coverage replacement. Real limits:

Voice translation is WebSocket-based. DeepL’s real-time voice translation is a bidirectional streaming protocol. DADL describes REST APIs declaratively; it does not describe streaming protocols. That endpoint is not in our 27-tool count and will not be — it is custom-server territory.
The Admin API is out of scope on purpose. DeepL exposes admin endpoints (org analytics, developer-key management). We deliberately scoped this DADL to user-facing translation surfaces. Admin endpoints have a different threat model and belong in a separate, more privileged backend — not bundled with the everyday translate tool that any team member might use.
Translation memory mutation is web-UI only. /v3/translation_memories is read-only via the API as of May 2026 — TMs are created and edited in the DeepL web UI. We expose list_translation_memories; we cannot expose endpoints that do not exist.
Stateful MCP clients are a legitimate use case. If you drive Claude Desktop, Cursor, or Continue directly and want a local MCP server with no governance layer in between, the official deepl-mcp-server is the right shape for that. The DADL-via-ToolMesh approach assumes a runtime that centralizes credentials, authorization, and audit — and that someone is willing to host it. For an individual developer with no governance requirements, that is overhead, not value.
Latency-sensitive pipelines. Every call hops through ToolMesh. For interactive translation at human latencies, this is invisible; for high-throughput batched pipelines, calling the DeepL client library directly is probably faster.

DADL is good at one specific thing — making REST API surface available to agents quickly, with a real control layer underneath. It is not a silver bullet, and it does not try to replace every kind of MCP server.

What is actually different

The substantive question is not “DADL vs MCP server” — that framing is wrong; ToolMesh runs both, and they coexist in the same registry. The substantive question is: what does it cost to track an upstream API release?

For a hand-coded server, it costs an engineering cycle: SDK changes, tool definitions, handlers, tests, a release, an npm publish, user upgrades. That is why community MCP servers tend to lag fast-moving APIs — not for lack of effort, but because the work is linear in software releases, not in lines of YAML.

For a DADL, it costs one PR with a YAML diff. DeepL shipped 13 new endpoints in mid-May. We shipped the updated DADL on May 21 — 14 old tools plus the 13 new ones, validated, merged, live. The work for the new endpoints was a couple of hours, most of it spent reading DeepL’s API reference and verifying behavior against a Free key. The runtime did the rest.

That is the asymmetry. Not “everyone should ditch MCP servers.” Not “DADL is universally better.” Just: when the unit of work to add API coverage is a YAML diff rather than a software release, the integration tracks the upstream faster. That matters when the upstream is shipping a Customization Hub.

→ Für die deutsche Geschäfts-Perspektive: dunkel.cloud/de/blog/deepl-customization-hub-via-dadl

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 27 APIs covering 3,338 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 early 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 27 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 27 backend definitions with 3,338 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.

ToolMesh | Blog

Reconciling a UniFi site against NetBox in one prompt

What happens underneath

What this run actually did

The definitions need the same scrutiny

”I have done this with Nornir for years”

Try it against your own controller

Tool Discovery for 4,800 MCP Tools — Without a Vector Database

How a discovery call gets to 320 KB

The fix everyone expects

What we shipped instead

1. Output that degrades before it detonates

2. Ranked free-text search — BM25 in ~200 lines of Go

3. Discovery inside the sandbox

What live testing caught within twenty minutes

Prior art, and what changes at scale

What’s next

From Switch Config to NetBox in One Prompt

The situation

The instruction

What actually happens underneath

The parts you’d worry about, handled

What this is, and what it isn’t

Want to try it on your own network?

Xen Orchestra 6.5's Full REST API — 245 Tools from One DADL

What the REST API now covers

The numbers

A worked example: a VM change, made undoable

Read-only is a feature, not a gap

Tracking the API is a YAML diff

The context-window argument

Honest caveats

What is actually different

Anatomy of an Enterprise Tool Library

What an Enterprise Tool Library actually is

The six pillars as mechanics

1. Any Backend — two ingress paths, one runtime

2. Code Mode — flat tool surface, constant context

3. Credential Store — runtime injection, never in prompts

4. OpenFGA — ReBAC, honest about the default

5. Output Gate — deterministic JS, with room to grow

6. Audit — slog and SQLite, SQL-queryable

The fail-closed request pipeline

CallerClass — the second axis nobody else has

Worked example: adding a backend

Why the context footprint stays constant

Scope and honesty: built vs planned

Backends in practice

Related

Try it

DeepL v3 Customization Hub — Covered in One DADL

What the new release added

The numbers

A worked example: style rules end-to-end

Maintenance asymmetry

The context-window argument

Honest caveats

What is actually different

Populating NetBox from Real Infrastructure with ToolMesh

Architecture Overview

Mapping: Source Objects to NetBox Objects

The Trust Escalation Model

What’s Next

Introducing ToolMesh — The Missing Control Layer for AI Agents

What ToolMesh is

The six pillars

1. Authentication

2. Authorization

3. Credential Store

4. Output Gate

5. Execution

6. Audit Trail

DADL: declare instead of code

Code Mode: scaling that otherwise doesn’t work

Self-hosted, open source

Get started

Stop Rebuilding REST API Wrappers for MCP

The wrapper you keep rebuilding

The same integration in DADL

The control layer you are not building