ToolMesh | Blog

OWASP MCP Top 10: What a Gateway Fixes — and What It Doesn't

Tue, 18 Aug 2026 00:00:00 GMT

A gateway eliminates some OWASP MCP Top 10 attack paths by construction, puts others behind a switch you still have to throw, and does not reach one category at all. That is the honest short answer, and this post is the long one: each of the ten categories, what a control plane in front of your MCP estate actually does about it, and where the mechanism stops. The reference implementation throughout is ToolMesh, our Apache-2.0 self-hosted MCP gateway, so every claim below is checkable against code you can read.

Three things you will find here that a summary of the list does not give you: the measured exposure figures the list responds to, a category-by-category table with a verdict per row, and a section naming the categories a gateway leaves open — anchored in someone else’s analysis, not our own marketing.

The numbers that made this list urgent

The Top 10 did not arrive in a vacuum — and it is older than this summer’s headlines: the list was there before the measurement that made it urgent. In July 2026, Nicolás Padilla published Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale (arXiv:2608.00150, v1 submitted 31 July 2026), the first dynamic behavioural assessment of MCP servers reachable from the public internet. Its findings, taken from the paper’s own abstract:

over 21,000 MCP server instances detectable on the public internet
640 production servers confirmed, of which 414 were dynamically audited
91.8 % of the dynamically audited servers lack OAuth authentication
687 tool instances across the confirmed servers expose shell execution capabilities without access controls
41.6 % of confirmed servers disappear within three days between measurement runs

That last number is the one operators should sit with. It describes an estate deployed faster than it can be reviewed. Forkast summarised the wider picture on 11 August 2026, counting more than ten critical or high-severity CVEs in the MCP ecosystem over the same period. One detail worth carrying if you compare write-ups: the 91.8 % applies to the 414 dynamically audited servers, and the 687 shell-capable instances are tools, not servers — several secondary reports round both onto the 640-server figure.

Public-sector guidance landed earlier. On 20 May 2026 the NSA’s Artificial Intelligence Security Center released the Cybersecurity Information Sheet Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. Its framing matters more than any single recommendation: alongside serialization risks and trust boundaries, the CSI names dynamic tool invocation, implicit trust relationships, and context sharing as risks that established cyber defence strategies do not adequately address, and argues these cannot be patched at the interface or endpoint level.

That is a structural claim, and it is why a per-server fix does not scale. Twenty-one thousand individually hardened servers is not a plan.

What the OWASP MCP Top 10 actually is

Precision about the artefact’s status is part of using it honestly. The OWASP Top 10 for Model Context Protocol is an Incubator project, currently at version v0.1, and its own roadmap places it in Phase 3 — Beta Release and Pilot Testing, with the next release scheduled for October 2026 (project page, checked 18 August 2026). The document is licensed CC BY-NC-SA 4.0.

So: not a certification target, not a compliance baseline, and the IDs still carry the :2025 suffix. What it is is a shared vocabulary for MCP risk, which is exactly what the category was missing. Treat it as a checklist for design review rather than an audit standard — and expect the categories to move in October.

The ten categories, as given in the summary list on the project page:

ID	Category
MCP01:2025	Token Mismanagement & Secret Exposure
MCP02:2025	Privilege Escalation via Scope Creep
MCP03:2025	Tool Poisoning
MCP04:2025	Software Supply Chain Attacks & Dependency Tampering
MCP05:2025	Command Injection & Execution
MCP06:2025	Intent Flow Subversion
MCP07:2025	Insufficient Authentication & Authorization
MCP08:2025	Lack of Audit and Telemetry
MCP09:2025	Shadow MCP Servers
MCP10:2025	Context Injection & Over-Sharing

One caveat about that table, and it is the sharpest available evidence for the beta status above: the project page does not agree with itself. The summary list gives MCP06 as Intent Flow Subversion. A second, fuller listing further down the same page titles the same entry Prompt Injection via Contextual Payloads — and in that listing the IDs lose their zero padding (MCP1:2025, MCP4:2025, MCP5:2025, MCP6:2025, MCP8:2025) while MCP03 and MCP07 keep theirs. Both readings were live on the page on 18 August 2026. We use the summary list throughout this post. If you cite OWASP MCP06 anywhere else, say which of the two titles you mean, because they describe noticeably different things: one is about hijacked intent, the other about prompt injection as an injection class.

The mapping at a glance

ToolMesh runs every tool call through one pipeline. The source comment states the order plainly: AuthZ → Credentials → Gate pre → Backend → Gate post → Audit (internal/executor/executor.go). The mapping below is that pipeline held against the ten categories, with a verdict per row.

OWASP category	Mechanism	Verdict
MCP01 Token Mismanagement & Secret Exposure	Credentials injected server-side per request; never in client config or model context	Client/model exposure closed; credential lifecycle open
MCP02 Privilege Escalation via Scope Creep	OpenFGA relationship check per call; discovery filtered by the same check	Enforced when configured
MCP03 Tool Poisoning	REST tool definitions come from operator-held YAML, not from the upstream server	Closed for DADL backends, open for aggregated MCP servers
MCP04 Supply Chain Attacks & Dependency Tampering	A backend is ~30 lines of YAML, not a package; strict parser rejects unknown fields	Reduced, not eliminated
MCP05 Command Injection & Execution	Tools are declared HTTP calls with typed parameters; no shell unless you add one	Shell injection closed at the tool layer; backend injection remains
MCP06 Intent Flow Subversion	Blast-radius limits only: authorization ceiling, output policies, audit trail	Not closed
MCP07 Insufficient Authentication & Authorization	OAuth 2.1 issuer, PKCE mandatory, S256 only; bcrypt API keys	Authentication closed; authorization only when enforcement is on
MCP08 Lack of Audit and Telemetry	Structured audit entry on every exit path, denials included	Recorded everywhere; not immutable, and the write itself is fail-open
MCP09 Shadow MCP Servers	One endpoint, one file-declared catalog — an inventory by construction	Consolidated, not prevented
MCP10 Context Injection & Over-Sharing	goja policy engine pre and post execution; Code Mode projects results	Enforced when configured

The ten categories, one by one

MCP01:2025 — Token Mismanagement & Secret Exposure

The failure mode is a backend API key sitting in a client config file, or worse, passing through the model’s context on its way to a tool. In ToolMesh, backend credentials never reach the client. They resolve inside ExecuteTool() at step 2 of the pipeline and are attached to the outbound request by the adapter — the agent asks for netbox_list_devices, not for a token. Revoking a key touches the gateway, not thirty client configurations.

Honest scope, and it is wider than it first looks. The shipped credential store is the embedded one, reading CREDENTIAL_* environment variables; Vault, OpenBao and Infisical adapters are documented as the tiering path, but the open-source binary today ships the embedded store, and per-user credential resolution is an accepted-design ADR rather than running code. More importantly, OWASP’s own scope for MCP01 goes past exposure: its description names long-lived tokens explicitly and calls short-lived, scoped credentials essential. The OWASP MCP Security Cheat Sheet is blunter still — do not store secrets in server code, configs, or environment variables, and prefer ephemeral tokens to long-lived ones. Read against that, ToolMesh closes the path from credential to model and leaves credential lifecycle where it found it.

MCP02:2025 — Privilege Escalation via Scope Creep

Authorization runs first in the pipeline, per call and per user, against an OpenFGA relationship model in a User → Plan → Tool structure. The detail worth knowing: the same check filters tool discovery, so a user who may not call a tool does not see it in the listing either. Scope-to-filter injection goes one step further and narrows backend query parameters from the caller’s scope, so authorization shapes the request rather than only permitting it.

Honest scope: ToolMesh ships with OPENFGA_MODE=bypass as the default — no authorization checks at all. Enforcement is one setting (restrict) plus a relationship model you have to write, and a gateway configured for convenience enforces nothing. The model is documented under Authorization.

MCP03:2025 — Tool Poisoning

The rug-pull variant of this attack works because an MCP client re-reads tool definitions from the server, so a description approved in review can change afterwards. For backends declared in DADL, that channel does not exist: RESTAdapter.ListTools reads the parsed YAML file the operator holds — it takes no context and makes no upstream call. The catalog changes when someone edits a file in your repository, which is a reviewable event with an author attached.

Honest scope: this holds for DADL-declared REST backends. Where ToolMesh aggregates a genuine upstream MCP server, MCPAdapter.ListTools does query that server, and those definitions are exactly as trustworthy as their source. In neither case does the gateway semantically inspect a description for hidden instructions — pinning is not detection.

MCP04:2025 — Software Supply Chain Attacks & Dependency Tampering

Every MCP server you add is normally a package, a runtime, and a transitive dependency tree. That cost model is the starting point of our own preprint, DADL: A Declarative Description Language for Enterprise Tool Libraries in LLM Agent Systems (arXiv:2605.05247, 4 May 2026): at organizational scale every API integration ships as a dedicated server process with its own deployment, dependency tree and credential handling — while the overwhelming majority of those servers turn out to be thin wrappers around REST APIs. With DADL, adding an API means adding a YAML file: no third-party code enters the runtime. The parser is explicit about what it does not understand, which is a weaker and more useful property than strictness: an unknown key is re-decoded strictly, reported as a warning and then ignored — the DADL spec’s warn-and-ignore rule, so a file using newer additive features still loads, visibly degraded rather than silently. Two things do fail closed: a requires block naming a capability this build lacks refuses the load outright, and a behaviour-determining value this version does not implement — a pagination behaviour, a stream handling — is rejected rather than guessed.

Honest scope: this shifts the supply chain rather than removing it. The gateway binary has its own Go dependency tree, and a malicious DADL file is still a config-supply-chain problem — the mitigation is that it is reviewable YAML in git rather than minified code in node_modules.

MCP05:2025 — Command Injection & Execution

Set against the paper’s 687 tool instances with unrestricted shell execution, this is the most structural difference in the list. A DADL tool is a declared HTTP call: method, path, and a typed parameter schema. There is no shell to inject into, because there is no shell — one appears only if an operator deliberately adds a backend that exposes one. Outbound URL validation fails closed on DNS resolution errors and treats unresolvable addresses as private, which is the SSRF-to-cloud-metadata path the same paper reports finding in the wild.

Honest scope: OWASP’s category is broader than shells. Its description covers an agent constructing and executing system commands, shell scripts, API calls, or code snippets from untrusted input without validation — and constructing API calls is exactly what DADL does for a living. A typed string parameter stops the tool layer from becoming an interpreter; it does not stop the backend on the far end from passing that string into its own SQL or shell. If the backend API itself exposes a command-execution endpoint, DADL will expose it faithfully. Declarative binding constrains the transport, not the API you point it at, and input validation against the backend’s semantics remains yours to write — in the gate, if nowhere else. The MCP03 split carries over unchanged, too: aggregate an upstream MCP server that ships a shell tool, and the gateway passes that tool through — subject to authorization and the gates like any other tool, but “no shell” is a property of the DADL layer, not a filter imposed on foreign catalogs.

MCP06:2025 — Intent Flow Subversion

This is the category a gateway does not close, and pretending otherwise would discredit the other nine. When injected context steers an agent toward an attacker’s goal, the resulting tool call is authenticated, authorized, schema-valid, and wrong. Every check in the pipeline passes, because every check answers whether this caller may do this thing — not why they are asking.

What the pipeline does contribute is a ceiling and a record: authorization bounds what a subverted agent can reach at all, output policies can block specific exfiltration shapes, and the audit log makes the trajectory reconstructable afterwards. Semantic authorization — an LLM supervisor reasoning about intent — exists in our concept notes and not in the binary. Until it does, treat MCP06 as unmitigated and design the blast radius accordingly.

MCP07:2025 — Insufficient Authentication & Authorization

Against the 91.8 % figure, the authentication half of this category has a sharp answer. ToolMesh acts as an OAuth 2.1 issuer: PKCE is mandatory, S256 is the only accepted challenge method, and a request without code_challenge is rejected at the authorization endpoint. API keys and user passwords are bcrypt-hashed. No anonymous caller reaches a tool.

Honest scope: the category is called Authentication & Authorization, and the second word lands where MCP02 already left it — OPENFGA_MODE defaults to bypass, so out of the box every authenticated caller is also a fully authorized one. Saying the pipeline’s authorization step “passes” in that mode would be a word game: no authorization decision is taken at all. Strictly read, ToolMesh closes the authentication half of MCP07 by construction and hands you the authorization half as a configuration task. Beyond that, TLS terminates in front of the gateway (Caddy, nginx, or Cloudflare Tunnel), identity is local — users.yaml and apikeys.yaml, or the built-in issuer — and OIDC connectors to Keycloak, Entra, Okta or Zitadel are roadmap, not shipped. The current surface is documented under Authentication.

MCP08:2025 — Lack of Audit and Telemetry

An audit entry is written on every exit path of the pipeline, including the ones that never reach a backend: authorization error, authorization denial, pre-gate rejection, backend error, post-gate rejection, and success. Denials are the entries that matter during an incident, and they are the ones homegrown logging most often misses. Storage is structured slog to stdout or SQLite (AUDIT_STORE), with retention configurable and defaulting to 90 days; Prometheus metrics run alongside.

Honest scope, in two parts. First, the log is trustworthy exactly as far as the host is: tamper-evidence — hash chaining with external anchoring — is an ADR draft, not an implementation, and OWASP asks for immutable audit trails while the Cheat Sheet adds SIEM ingestion and alerting on top. Neither is in the box. Second, and less obvious: the audit write is deliberately fail-open. The source comment says so in as many words — audit recording failures do not block the tool response, because availability is prioritized over auditability. So the pipeline is fail-closed at the steps that decide whether a call happens, and fail-open at the step that records it. If your requirement is that no unlogged call may ever execute, ToolMesh does not meet it today; you would run an external audit pipeline and alert on the error entries.

MCP09:2025 — Shadow MCP Servers

Consolidation is the whole answer here, and it is a deployment property rather than a clever feature. One endpoint, one catalog, declared in files: our own production instance currently fronts 5,590 tools across 60 backends behind a single MCP endpoint (checked 18 August 2026). Asking “what can our agents reach?” is reading a directory, not running a network scan.

Honest scope: a gateway does not stop anyone from running an MCP server beside it. Preventing shadow deployments is egress policy, asset management and organisational discipline. What a gateway removes is the reason to spin one up — and it gives you something to compare a scan against.

The Output Gate is a goja JavaScript policy engine that runs twice per call: pre-execution on the request, post-execution on the response, with a five-second timeout per policy. Shipped policies cover PII redaction, role-based field filtering and caller blocking; redaction itself fails closed. Code Mode attacks the same category from the other side — the agent runs typed JavaScript against the tools and returns only what it projects, so a thousand-row response can be reduced to five fields before anything enters the context window.

Honest scope: the open-source gate is deterministic rules only. The LLM-based compliance evaluator is an enterprise extension, and human-in-the-loop review is not implemented at all. A rule catches what you wrote it to catch.

What a gateway does not solve

The most useful critique of the gateway pattern this year came from outside the vendor field. In Securing MCP in Production: Defense-in-Depth beyond the Gateway (InfoQ, 29 July 2026), Nik Kale grants that gateways deliver central authentication, authorization, auditing and policy evaluation — and then structures what still has to exist around them into four defense layers, each of which, he argues, has its earliest trustworthy enforcement point somewhere other than the gateway. His verdict on the pattern is two three-word sentences: “It is necessary. It is insufficient.” We agree, and held against the map above his four layers split evenly: two land where DADL already changes the mechanics, two sit beyond anything a pipeline reaches.

Safe tool execution. A gateway cannot ensure that a tool handler treats its arguments as data rather than instructions. For DADL-declared backends this layer collapses by construction: there is no handler code to get wrong, because the gateway itself builds the HTTP call from the typed schema. The MCP05 limits stay standing — what the backend does with the values, and every handler inside an aggregated MCP server, sit beyond it.
The management plane. The inspectors, harnesses, dashboards and consoles around MCP are not behind the gateway, and they frequently hold more privilege than the agents do. Nothing in the pipeline above protects them.
Outbound trust, egress and token scope. Server-side injection stops a credential from reaching the model. It does not stop a backend from being handed a token broader than the task needed, or from making its own unsafe outbound calls with it. Credential scoping is a decision you make when you write the DADL, and no pipeline stage rescues an over-broad token.
Semantic integrity and manifest pinning. Kale’s fourth layer is the rug-pull problem from MCP03, and he points out that the MCP specification is silent on pinning — functionality teams have to build at the gateway themselves. DADL-declared backends get it by construction; aggregated MCP servers do not. That is exactly where our MCP03 verdict splits.

One category from the table appears in none of the four layers: MCP06. A call that is authenticated, authorized and schema-valid, made for an attacker’s reasons, is not an execution problem, a management-plane problem, an egress problem or a manifest problem. Which is one more way of saying what the verdict column already does: a gateway does not close it, with or without the layers around it.

We add one gap of our own, because it applies to us specifically: a gateway concentrates risk as much as it concentrates control. Consolidating 60 backends behind one endpoint means that endpoint holds every credential and fronts every tool — an internet-facing MCP endpoint and a high-value target in one object. It needs its own hardening, its own exposure review, and a place in the estate you audit rather than only being the tool you audit with. We track that as an open item on our own instance, not as a solved problem.

Two things are worth saying against the temptation to read all of this as an argument for doing nothing. First, the pattern is not speculative: in A Gateway Architecture for Enterprise MCP Authentication (arXiv:2608.10760, v1, 11 August 2026), a team of authors with PayPal affiliations describes exactly this consolidation — per-team authentication implemented independently, no consistent way to authorize callers or offboard a departing employee — and reports an architecture in production fronting dozens of internal MCP servers. The paper itself does not name the operator; the affiliation is visible in the authors’ addresses. Independent of any vendor, the category is being validated at enterprise scale. Second, “insufficient” is not “useless” — and OWASP says as much from its own side. The MCP Security Cheat Sheet recommends using an MCP proxy or gateway to enforce isolation policies between servers, and pinning tool definitions to detect rug pulls. Those are two of the mechanisms described above, recommended by the same foundation that publishes the risk list. Every category except MCP06 gets materially better at the gateway — and gets better once, rather than separately on every server.

Where ToolMesh stands

ToolMesh is an Apache-2.0, self-hosted MCP gateway written in Go that runs every tool call through one central enforcement pipeline — authorize, inject credentials, gate, execute, gate, audit — fail-closed at each enforcement step you have switched on, and, as noted under MCP08, fail-open at the audit write. Backends are declared in DADL, YAML files you keep in git, which is why the tool catalog is a reviewable artefact rather than a runtime negotiation. The architecture behind the pipeline is laid out in Anatomy of an Enterprise Tool Library; what the pattern looks like under the new stateless spec is in MCP Goes Stateless.

Where we come out on the Top 10, read strictly: not one category is fully closed in OWASP’s own scope. What a gateway does is narrower and more useful than a row of green ticks. It eliminates specific attack paths by construction — credentials reaching the model, an interpreter at the tool layer, rug-pulled tool definitions on DADL-declared backends. It puts several more behind one switch that has to be thrown, and bypass is the default. It improves the rest by consolidation rather than by mechanism. And MCP06 sits outside its boundary entirely. That is a defensible position for August 2026 and not a finished one. The OWASP list moves to its next release in October, and we would rather re-run this mapping against the new version than quietly let it age.

If you run the same mapping against your own estate and reach a different verdict on any row, GitHub Discussions is open — a disagreement about one of these ten is more useful to us than agreement about all of them.

Sources

Source	Date	Used for
OWASP Top 10 for MCP	v0.1, checked 18 Aug 2026	Category IDs, titles and scope; project status; the MCP06 discrepancy
OWASP MCP Security Cheat Sheet	undated, checked 18 Aug 2026	Credential guidance, tool pinning, gateway isolation, SIEM
arXiv:2608.00150 — Exposed by Design	v1, 31 Jul 2026	21,000+ instances, 640/414 servers, 91.8 %, 687 tools, 41.6 %
NSA AISC Cybersecurity Information Sheet on MCP	20 May 2026	Dynamic tool invocation, implicit trust, context sharing
Forkast — MCP security inflection point	11 Aug 2026	10+ critical/high CVEs, ecosystem context (secondary source)
InfoQ — Defense-in-Depth beyond the Gateway	29 Jul 2026	The four defense layers beyond the gateway
arXiv:2608.10760 — A Gateway Architecture for Enterprise MCP Authentication	v1, 11 Aug 2026	Independent production validation of the pattern

MCP Goes Stateless — What It Means for Your Gateway

Sun, 16 Aug 2026 00:00:00 GMT

MCP is stateless now — at its protocol core. On July 28, 2026 the Model Context Protocol shipped 2026-07-28 — the revision its maintainers call the most important since remote MCP launched, and the start of a countdown. If you operate MCP servers, three capabilities your setup may quietly rely on — Sampling, Roots, and protocol Logging — are now deprecated, with removal possible after twelve months. Protocol sessions are gone entirely: every request now stands on its own.

This post answers three operator questions: what actually changed, what to check in your own MCP estate while the clock runs, and why the new spec — read closely — assumes there is a gateway between your agents and your servers. The spec-level detail, every breaking change with its SEP reference, waits in the reference table at the end of this post.

What changed, in plain terms

The release post explains the pressure behind the revision: the maintainers report close to half a billion SDK downloads per month across the Tier 1 SDKs. At that scale a protocol inherits infrastructure problems, and MCP’s biggest one was the session. A client was pinned to whichever server instance held its session — load balancers needed sticky sessions, deployments had to drain them, and serverless platforms fought the protocol at every step.

The 2026-07-28 changelog answers with four moves:

Sessions and the initialize handshake are gone. Version, identity, and capabilities travel inside each request, so any request can land on any instance behind a plain round-robin load balancer.
Two routing headers become mandatory. Every Streamable HTTP request carries Mcp-Method (what is being called); tool calls also carry Mcp-Name (which tool). The point: infrastructure between client and server can route, rate-limit, and meter MCP traffic without opening the JSON body.
Servers no longer send their own JSON-RPC requests to clients. The old server-initiated pattern behind Sampling, Elicitation, and Roots is replaced by Multi Round-Trip Requests (MRTR): the server answers “I need more input” (input_required), and the client retries the request with the answer attached. Notifications survive — request-scoped ones flow on the response stream, and one long-lived subscriptions/listen stream carries the change notifications a client opts in to. One misreading to avoid: Elicitation is not deprecated — only its server-initiated form is gone; elicitation itself lives on inside MRTR.
Deprecation becomes policy, not habit. Roots, Sampling, and Logging keep working for at least twelve months, but new implementations should not adopt them. The new feature lifecycle guarantees the window; only an actively exploited security risk can shorten it, and never below ninety days.

Sessions are gone — where did the state go?

Stateless is a statement about the protocol, not about your application. The changelog says where cross-call state goes now: servers that need it “use explicit, server-minted handles passed as ordinary tool arguments” (SEP-2567). Your database cursor, your SSH session, your half-finished workflow — none of that disappeared. It moved up a layer, out of the transport and into the application. Something up there now has to mint those handles, store what they point to, expire them, and decide who may use them.

Hold that thought. First, the practical part.

Which of your MCP servers use deprecated capabilities?

The twelve-month clock started on July 28. Whether you run three MCP servers or thirty, the transition is an audit before it is a migration:

Transports. Which servers still speak the 2024-11-05 HTTP+SSE transport? It is formally deprecated; Streamable HTTP is the target.
Sampling. Which servers call sampling/createMessage? The documented migration is direct integration with an LLM provider API — a real architecture decision (whose key, whose budget, whose logs), not a search-and-replace.
Roots. Which servers expect roots/list? Migration: pass directories and files as tool parameters, resource URIs, or server configuration.
Logging. Which servers rely on logging/setLevel and notifications/message? Note that logging/setLevel is removed outright in 2026-07-28 — log level moves into each request’s _meta. Migration: stderr on stdio, or OpenTelemetry.
Sessions. What breaks when Mcp-Session-Id disappears? Sticky-session load balancer rules, every tool that assumes implicit per-connection state — and interrupted SSE streams, which are no longer resumed via Last-Event-ID but simply re-requested. Redesign around explicit handles.
Auth. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents (CIMD); clients must validate a present iss parameter (RFC 9207).
SDKs. The Tier 1 SDKs (TypeScript, Python, Go, C#) already speak 2026-07-28; they must mark deprecated API surfaces and should warn at runtime when one is used. Treat those warnings as inventory data, not noise.

The practical problem: answering “which servers?” means observing capability usage across your whole estate. That is awkward server by server — and natural at a chokepoint. A gateway terminates every client connection, so it is the one place where deprecated-capability usage shows up as data, per backend and per client, and where a bridge between spec versions can live during the window. We made the broader visibility argument in Why MCP Gateways Alone Don’t Solve the Real Problem: the gateway is where you see; what you enforce there is a separate design decision.

Why the stateless spec assumes a gateway

To be clear up front: the spec does not require a gateway — a client can still talk to an MCP server directly. But read the Streamable HTTP transport spec with infrastructure eyes and a pattern appears: the protocol is visibly built so that a layer in the middle becomes maximally effective. The spec states outright that request fields are mirrored into HTTP headers so that “intermediaries (load balancers, gateways, observability tooling)” can act on requests without parsing the body. A stateless request looks like this:

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_device

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_device",
    "arguments": { "name": "sw-core-01" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" }
    }
  }
}

Three details show how seriously the spec takes that middle layer:

Header integrity is enforced. Servers must reject requests whose headers disagree with the body (HTTP 400, error HeaderMismatch) — because a load balancer routing on a header while the server executes a different body would be a security hole. You only harden a mechanism like that if you expect components in the middle to act on it.
Parameter routing is in the protocol. A tool schema can mark parameters for header mirroring (x-mcp-header → Mcp-Param-*), so tenant, region, or project routing can happen at the edge, without body inspection.
Shared caches are first-class. Tool listings now declare how long they may be cached (ttlMs) and by whom (cacheScope); the value "public" exists precisely to allow shared caches, and deterministic tool ordering is recommended so catalog caches stay stable. (Catalog size is its own problem; we wrote about it in Tool Discovery for 4,800 MCP Tools.)

Put the halves together. Remote MCP traffic now behaves much more like ordinary HTTP traffic — something your infrastructure can route, throttle, meter, and cache. Cross-call application state becomes explicit: a server mints handles and manages their lifecycle. And credentials, token exchange, policies, and audit remain operator responsibilities either way. In larger MCP estates those responsibilities bundle naturally in one place: an application-layer control plane between agents and servers.

This is not just our reading. AWS shipped AgentCore Gateway support for 2026-07-28 on release day, including per-request version bridging so old and new clients coexist. An enterprise deployment paper on arXiv (August 11, 2026) describes the governance problem of dozens of independently authenticated MCP servers and resolves it with exactly this component: one gateway fronting every downstream server. And InfoQ’s coverage (August 12, 2026) observes that the new headers hand gateways the same primitives they already apply to every other API.

The skeptics see the same facts and invert them. InfoQ’s headline asks whether stateless MCP is “just an API again”; the Hacker News thread adds sharper versions: the revision is wire-incompatible in both directions, dropping implicit session state is a real regression for tools that leaned on it, and date-based spec versions make the churn hard to track. Fair objections. But notice what they concede: if the protocol layer is now ordinary HTTP, then everything still specific to MCP in your deployment — which agents may call which tools, with whose credentials, under which policies, leaving which audit trail — is decided by whatever you place in the middle. The spec did not make that layer unnecessary. It made it the place where the decisions live.

What a gateway does not solve

Honesty cuts both ways, so here is the list we would want to read ourselves:

It does not rewrite your servers. If server code calls sampling/createMessage, that code has to change. A gateway shows you where; it does not do the work.
Sampling needs a real replacement, not a shim. Moving model access to a provider API relocates keys, budgets, and logging. Decide it deliberately rather than letting the deadline decide it for you.
Stateful designs need redesign, not translation. The Hacker News objection is legitimate: explicit handles cost schema surface and tokens compared to implicit session context. The spec chose operability; some tool designs pay for it.
Bridging buys time, not completion. A gateway that speaks both revisions extends coexistence. The deprecation window still ends.
Header-based policy has a trust boundary. The spec itself warns intermediaries to trust mirrored headers only when the declared protocol version enforces header–body validation, and to reject older traffic rather than act on unvalidated headers. And origin servers should keep validating regardless — a gateway must never become the only checkpoint.

Where ToolMesh stands

ToolMesh is an Apache-2.0, self-hosted MCP gateway written in Go that sits between AI agents and backend systems and runs every tool call through one fail-closed pipeline: authenticate → authorize → inject credentials → gate output → execute → audit. The state the new spec pushes out of the protocol is the kind of state a control plane holds on purpose: backend credentials are injected server-side and never travel through the model, and every call lands in a structured audit log — the raw material for exactly the deprecated-capability inventory described above. Backends are declared in DADL, YAML files in git, so the tool catalog is deterministic by construction — which is what the new caching rules (ttlMs, cacheScope, stable ordering) are designed to reward. The pillars behind that pipeline are laid out in Anatomy of an Enterprise Tool Library.

Our own production instance speaks Streamable HTTP and STDIO today, and its migration to 2026-07-28 is in progress — transport, SDK, and a session audit of our own backends. We would rather report findings than predictions, so we will share those notes once the migration lands.

If you are running MCP servers and starting the same audit, we would genuinely like to compare notes — GitHub Discussions is open.

Reference: the changes at a glance

Every breaking move with its SEP reference — the spec-level detail behind the summary above:

Change	What it means	Reference
Protocol sessions removed — `Mcp-Session-Id` is gone	Any request can hit any instance; cross-call state becomes explicit handles	SEP-2567
`initialize`/`initialized` handshake removed	Version, identity, and capabilities travel per request in `_meta`; optional `server/discover` RPC for up-front discovery	SEP-2575
`subscriptions/listen` replaces the HTTP GET endpoint and `resources/subscribe`	One long-lived, opt-in response stream carries change notifications	SEP-2575
`ping`, `logging/setLevel`, `notifications/roots/list_changed` removed	Log level is set per request via `_meta` (`io.modelcontextprotocol/logLevel`)	SEP-2575
`Mcp-Method` / `Mcp-Name` headers required on Streamable HTTP	Intermediaries route, authorize, and meter without parsing JSON bodies	SEP-2243
`ttlMs` / `cacheScope` required on list results and `resources/read`	Tool catalogs become cacheable; `"public"` explicitly allows shared caches	SEP-2549
Multi Round-Trip Requests (MRTR) replace server-initiated requests	`sampling/createMessage`, `elicitation/create`, `roots/list` become `input_required` round-trips	SEP-2322
All results carry a required `resultType`	`"complete"` or `"input_required"`; results from earlier-protocol servers without it are treated as complete	SEP-2322
Tasks move out of the core	Official extension `io.modelcontextprotocol/tasks`, poll-based	SEP-2663
Roots, Sampling, Logging deprecated	Still work for at least twelve months; new implementations should not adopt them	SEP-2577
Legacy HTTP+SSE transport reclassified as Deprecated	Migrate to Streamable HTTP	SEP-2596
Dynamic Client Registration deprecated	Client ID Metadata Documents (CIMD) become the registration path; RFC 9207 `iss` validation required	changelog

Servers must additionally reject requests whose routing headers disagree with the body: HTTP 400 with JSON-RPC error -32020, HeaderMismatch.

Editing Files Without an Editor

Sat, 01 Aug 2026 00:00:00 GMT

In part one of this series — Die Hände der KI, in German — we argued that a language model is a voice without hands: everything that looks like doing is a tool layer wrapped around it, and that layer is where control lives. This post goes one level deeper, into the mechanics of a single finger. Because even with hands, a model faces a problem that rarely gets talked about:

It has no editor.

No cursor. No selection. No Ctrl+F highlighting the third match. A human edits text by pointing at it. A model cannot point. It can only describe.

So how does an AI actually change a file?

Counting is not describing

The naive answer is to describe positions: “replace lines 45–52 with this.” It is how humans talk about code, it is how sed works, and it fails for models in two compounding ways.

First, language models are genuinely bad at counting. They do not perceive a file as numbered lines — they see a token stream. Ask a model for the 45th line of a long file and you get an approximation, delivered with confidence.

Second, and more fundamental: positional addresses expire the moment you use them. Every successful edit shifts every line number below it. In a multi-step editing session the model’s map of the file drifts further from reality with each step. And a bare line-number edit fails silently — line 45 always exists, it is just no longer the line you meant. (Classic patch survives drift precisely because its hunks carry quoted context lines: the escape hatch already points at content.)

The research record is blunt about this. A 2026 study of edit formats (To Diff or Not to Diff?) identifies fragile offsets and fragmented hunks as a core reason classic unified diffs are unnatural for models to generate — the @@ -45,7 +45,9 @@ hunk header is a small counting exercise, and models reliably get it wrong. Another paper (Copy-as-Decode) ran the controlled version of the experiment, perturbing otherwise-correct positional edit references by single steps: pooled exact match dropped from 100% to 15.48%.

One line of drift, 85 points gone. Positions are the wrong address space.

The text is the address

What models do far better is reproduce text they have just read — quoting is much closer to their native operation than counting is. So the robust design, arrived at independently by most of the tools that expose file editing directly to an LLM, is:

The text to be replaced is the address.

The model sends an exact quote of what should change (old_str) and its replacement (new_str):

{
  "old_str": "timeout: 30\nretries: 3",
  "new_str": "timeout: 60\nretries: 5"
}

No positions anywhere. The API searches for the quote and requires it to be unique.

The quiet superpower of this scheme is that it is self-validating — in the one dimension an API can actually check: the quoted text either exists uniquely, or nothing happens and the call fails loudly. That failure carries meaning: the model’s picture of the file is stale. Wrong line numbers produce the opposite — an edit that “succeeds” somewhere unintended. That is silent corruption, the worst failure an editing API can have, because in agent workflows nobody is looking at the file afterwards.

Loud failure is a feature. It is the API telling the model: re-read, then try again.

When the quote is not unique

The obvious objection: what if timeout: 30 appears four times?

The tempting fix is to teach the API about document structure — “replace in section X”, “inside function Y”. That road leads to a format-aware API for Markdown, another for YAML, another for Go. The better fix is to apply the same principle recursively: scope by quoting, too.

Two generic mechanisms cover it:

Anchors. Optional after and before parameters take quotes that bracket a window; old_str only needs to be unique inside the window. Headings, function signatures, config keys — the API does not need to know they are “structure”. They are just strings that happen to be naturally unique, and the model is well equipped to pick them. The API stays content-agnostic.

The occurrence round-trip. If the model does not scope and the quote is ambiguous, the API rejects the call — with numbered findings:

{
  "error": "ambiguous",
  "matches": [
    { "occurrence": 1, "context": "connect:\n  timeout: 30" },
    { "occurrence": 2, "context": "read:\n  timeout: 30" },
    { "occurrence": 3, "context": "write:\n  timeout: 30" }
  ],
  "retry": "resend with occurrence: N, or narrow with after/before"
}

The model retries with occurrence: 2. Note what did not happen: the model never counted. The index was assigned by the API, is fresh by construction, and is verifiable against the context shown. Counting has been moved from the party that is bad at it to the party that is trivially good at it.

Anchors are not free — the quoted context costs tokens and eats part of what scoping saves. For a small edit in a large file it is still far cheaper than any alternative.

Select and swap

Some edits replace a whole block. Reproducing forty lines as old_str is token waste and a fragility source — one transcription slip in line 23 and nothing matches. The editor gesture for this is click, then shift-click. The API equivalent is replace_range: quote the start, quote the end, replace everything between, inclusive:

{
  "from_str": "## Deployment",
  "to_str": "systemctl restart toolmesh",
  "new_str": "## Deployment\n\nShip it with the new runbook: ..."
}

The model describes the boundaries instead of reproducing the body. The boundary quotes follow the same rules as any quote — unique in scope, start before end, validated against the same revision. And because the body is unseen, a well-behaved API offers a dry_run that shows what would be replaced, and echoes the actually replaced text back after a committed write.

The file changed under you

Agents do not edit alone. Another agent, a human, a cron job — anything may have touched the file since it was read. An edit based on a stale read is the lost-update problem, and content addressing alone does not fully solve it: the quote might still match even though the surrounding document has moved on.

The fix is thirty years old: optimistic concurrency. Every read returns a revision. Every write carries it back as base_rev. If the file has changed in between, the write is rejected and the model re-reads and re-quotes. Web developers know this as ETag and If-Match.

Almost nothing in this protocol is novel, and that is the point. The only genuinely new decision is what gets addressed — content instead of positions — because the caller is a system that quotes flawlessly and counts badly.

An escalation ladder, not a single tool

In practice the protocol is a ladder, and the tool description should say so:

Small correction → bare str_replace.
Ambiguous match → add after/before, or take the occurrence the error just handed you.
Substantial block rework → replace_range, or str_replace with the whole paragraph as the quote.
Document under one or two thousand tokens → a full rewrite is legitimate and the most robust move of all. It simply does not scale.

The anti-pattern sits at the top rung: the unscoped full rewrite of a large file. It invites truncation laziness (”… rest of file unchanged …”) and drive-by edits in passages nobody meant to touch. Scoped tools exist precisely so the model never has to hold the whole file in its output.

The tools that ship converged on this

Look at the editing tools that get real production use:

Anthropic’s public text_editor tool is built on str_replace with enforced uniqueness.
Aider standardized on search/replace blocks after extensive benchmarking; its leaderboard scores models on emitting the edit format correctly, not just on solving the task.
OpenAI’s apply_patch (the V4A patch format used by Codex) drops line numbers and addresses each hunk by quoted context lines.

The benchmark record agrees. JetBrains Research’s Diff-XYZ compared edit representations head-to-head; search-replace “performs best for larger models across most tasks” — GPT-4.1 applies edits with it at 0.96 exact match.

There is a second school of thought — Cursor’s fast-apply and Morph-style merge models — that accepts lazy, human-style edits from the big model and trains a small specialized model to apply them. Different mechanics, same underlying distrust of raw positional output against a real file.

When Anthropic, OpenAI, Aider and the benchmark record all land on the same core move — address edits by quoted content — that is not fashion. That is the shape of the constraint.

A living proof: the wiki this post was planned in

We did not arrive at any of this in theory. Our team wiki — where the outline for this very article lived before it became a post — is a small internal tool called Tabula: an LLM-native Markdown wiki over a plain git working tree, built to be edited by agents as much as by people.

Its entire write path is the protocol above:

read_page returns {content, rev} — the revision is the future base_rev.
edit_page is str_replace: quote, replace, done. An empty old_str is rejected; inserts reproduce a surrounding anchor instead.
An ambiguous quote returns 422 ambiguous with numbered findings and retry options — occurrence: N or after/before.
replace_range covers block rework; batch_edit applies several edits atomically — all validate or none apply.
Every write requires a change summary and lands as one git commit. git log is the audit trail.

Agents edit this wiki daily. Ambiguous matches happen — self-similar prose like config tables and status lists triggers them far more often than code does — and they resolve in a single round-trip. What we have not seen once is a silently corrupted page. That trade, loud failure for cheap recovery, is the entire design.

Hands, with rules

Part one ended with a claim: intelligence will be rented — your hands should be your own. This post is one of those hands up close: not a window with a blinking cursor, but a narrow protocol of quotes, revisions and honest errors.

The narrowness is what makes the hand governable: every edit names exactly the text it touches, declares the revision it was based on, and lands as a commit someone can diff, revert and attribute. In ToolMesh, our self-hosted gateway, an editing backend like this is just another tool behind the usual permission and audit surface — a read-only agent never sees the write tools at all.

An AI’s editor was never going to look like ours. For an unattended caller, it is better: it cannot touch a line without naming it first.

If you have built — or fought — an editing interface for agents, we would genuinely like to compare notes in GitHub Discussions.

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's Full REST API — 252 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; 6.6 (June 2026) continued the same trickle — scoped Storage and Network Administrator roles, writable backup repositories, and PATCH for VDIs and VIFs. 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 252-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.6 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, with PATCH rename and disk-resize on VDIs since 6.6), networking (VIF/PIF/PBD, with PATCH on VIFs since 6.6), 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 — writable since 6.6 — 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	252	7
Scope	full read and write	read-only by design
Coverage	every REST object + lifecycle action (incl. `PATCH` on VMs, VDIs, VIFs), backups with writable repositories, 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 252-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 — 252 tools

The full definition is live and browsable at dadl.ai/d/xen-orchestra — the authoritative source, always current with the latest XO release. 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 — “252 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 252 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; 6.6 added scoped Storage and Network Administrator roles, writable backup repositories, and PATCH for VDIs and VIFs. 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.

That is what every XO release looks like from here. 6.6 was seven new tool blocks and a version bump from 245 to 252 — an afternoon’s diff, not an event. The releases worth a second look are not the ones that add endpoints, but the ones that close a gap you had written down as a limitation.

Two concrete examples from 6.6:

The release added PATCH /vdis/{id}. An earlier version of this post listed “VDIs cannot be renamed via REST” under honest caveats — 6.6 closed that gap, and reflecting it was a single update_vdi tool block (rename a disk or grow it), annotated “added in XO 6.6 — returns 404 on older builds” so an agent against an older host gets a clean terminal error instead of a silent failure.
Backup repositories became writable: POST / PATCH / DELETE /backup-repositories. Three new tool blocks, the same shape as every other write endpoint, behind the same credentials, authorization, and audit — nothing about the gateway changed. The new built-in Storage Administrator and Network Administrator roles need no new tools at all; they compose out of the RBAC v2 surface the DADL already exposed.

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 252 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 31 backends with 4,132. A 252-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.
Host power actions aren’t in the REST API. Hosts have no REST route for start / shutdown / reboot / restart_toolstack — only disable, enable, and management_reconfigure are exposed. For host power you use pool-level rolling_reboot / rolling_update or drop to the JSON-RPC API. We expose what exists; we cannot expose what does not. (The entry that used to sit here — “VDIs cannot be renamed via REST” — was retired when 6.6 shipped PATCH /vdis/{id}.)
SDN traffic rules need a Premium plugin. The six traffic-rule tools (add / delete / update_network_traffic_rule, add / delete / update_vif_traffic_rule — the two update variants new in 6.6) 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 246 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 252 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 — 31 APIs, 4,132 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 31 backends with 4,132. 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 31 APIs covering 4,132 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 31 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 31 backend definitions with 4,132 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

OWASP MCP Top 10: What a Gateway Fixes — and What It Doesn't

The numbers that made this list urgent

What the OWASP MCP Top 10 actually is

The mapping at a glance

The ten categories, one by one

MCP01:2025 — Token Mismanagement & Secret Exposure

MCP02:2025 — Privilege Escalation via Scope Creep

MCP03:2025 — Tool Poisoning

MCP04:2025 — Software Supply Chain Attacks & Dependency Tampering

MCP05:2025 — Command Injection & Execution

MCP06:2025 — Intent Flow Subversion

MCP07:2025 — Insufficient Authentication & Authorization

MCP08:2025 — Lack of Audit and Telemetry

MCP09:2025 — Shadow MCP Servers

MCP10:2025 — Context Injection & Over-Sharing

What a gateway does not solve

Where ToolMesh stands

Sources

MCP Goes Stateless — What It Means for Your Gateway

What changed, in plain terms

Sessions are gone — where did the state go?

Which of your MCP servers use deprecated capabilities?

Why the stateless spec assumes a gateway

What a gateway does not solve

Where ToolMesh stands

Reference: the changes at a glance

Editing Files Without an Editor

Counting is not describing

The text is the address

When the quote is not unique

Select and swap

The file changed under you

An escalation ladder, not a single tool

The tools that ship converged on this

A living proof: the wiki this post was planned in

Hands, with rules

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's Full REST API — 252 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