Back to browse
ToolMesh – turn all your REST APIs into MCP tools via declarative YAML

ToolMesh – turn all your REST APIs into MCP tools via declarative YAML

by axeldunkel·Apr 28, 2026·2 points·2 comments

AI Analysis

●●SolidSolve My ProblemShip It

Declarative YAML turns any REST API into an MCP tool in minutes.

Strengths
  • Public registry of 20 backends with 1,833 pre-defined tools saves setup time.
  • LLM-assisted DADL generation drafts configs automatically before human tuning.
Weaknesses
  • Demo link returns 404, making it impossible to verify the actual UI or flow.
  • Another abstraction layer in the already crowded MCP tooling ecosystem.
Target Audience

DevOps engineers and AI agent developers

Similar To

LangChain Tools · CrewAI · Superinterface

Post Description

When at night the pager goes off, I ask Claude: "what is alerting, what changed in the last hour?". Claude answers by chaining calls across Graylog, Prometheus, Alertmanager, Linode, GitLab, NetBox and more. The menu of tools Claude has access to is even bigger than that: I have connected 30 backends so far (20 in the public registry, the rest internal to my setup), including most of my ops stack (OPNsense, Tailscale, Xen Orchestra, DokuWiki and more). ToolMesh is what makes that menu composable for Claude.

Each backend is a simple DADL file - a small YAML that declares the REST API of the service to ToolMesh, which then exposes those tools to Claude. Most of the publicly available DADLs (currently 20 with 1,833 tools in total) were drafted by an LLM in minutes and tuned from there. The registry is public.

Here is the HN API as DADL - the API behind this very page:

tools: get_top_stories: method: GET path: /topstories.json access: read description: "Up to 500 top story IDs, ordered by HN ranking" get_item: method: GET path: /item/{id}.json access: read description: "Get story, comment, job, poll, or pollopt by ID" params: id: { type: integer, in: path, required: true }

How can a single agent access so many backends without creating context overflow? Code Mode. Naively, every tool and schema goes into context - 50,000+ tokens before the agent does anything useful. ToolMesh compresses that to ~1,000 by giving the model a typed API surface and letting it ask for endpoint details only when it needs them. That is the difference between "doesn't scale" and "please add 10 more, it's fine!". ToolMesh can also connect to other MCP servers, rendering them code mode capable as well.

Security in mind: credentials never reach the model (they are injected at runtime). ToolMesh runs a fail-closed pipeline: auth -> authz -> credential injection -> exec -> output gate -> audit. CallerClass lets the same API have different policy per client type (local dev assistant vs hosted agent vs CI bot). Every call lands in a SQLite-queryable audit log - "what did the agent do Tuesday?" becomes a SQL query, not a shrug.

ToolMesh is not magic. APIs with stateful flows or weird auth still need care, and an LLM with a great tool surface can still pick the wrong tool. You still need sane policy.

Try before cloning: https://demo.toolmesh.io is a public instance with the HN API loaded (login dadl/toolmesh). Connect Claude Desktop, Claude Code, or ChatGPT in 30 seconds: https://toolmesh.io/demo

GitHub: https://github.com/DunkelCloud/ToolMesh Docs: https://toolmesh.io DADL Spec + Registry: https://dadl.ai

Apache 2.0, single Go binary or Docker, no SaaS dependency.

If you think of your full ops stack - what DADLs would you like to have available to your LLM?

Similar Projects

AI/ML●●Solid

AnythingMCP – source-available gateway turning REST/SOAP/SQL into MCP

Turns legacy SOAP and REST APIs into MCP servers without writing glue code.

Ship ItSolve My Problem
helpcodeai
2023d ago
AI/ML●●Solid

Orloj – agent infrastructure as code (YAML and GitOps)

Kubernetes for AI agents with YAML manifests and GitOps workflows.

Big BrainBold Bet
An0n_Jon
20122mo ago
Developer Tools●●Solid

Turn any OpenAPI spec into agent-callable skills

It extracts focused, executable operations from giant OpenAPI files (the GitHub REST YAML is shown) to shrink context and avoid sidecar adapter sprawl — a pragmatic answer to token bloat and brittle ad-hoc integrations. Useful and concrete: if it actually generates tidy, updateable skill units and runtime hooks it saves a lot of maintenance. That said, the idea competes with existing LangChain/openai-function patterns; the repo will need clear runtime, versioning, and update strategies to feel like more than a nicer converter.

Solve My ProblemNiche Gem
yz-yu
103mo ago