Frequently Asked Questions
Answers to the most common questions about ToolMesh, the Model Context Protocol (MCP), and DADL. If your question is not listed here, open an issue on GitHub or reach out via the Getting Started guide.
MCP
What is MCP (Model Context Protocol)?
MCP is an open standard by Anthropic that lets AI applications like Claude or ChatGPT connect to external tools, databases, and APIs through a unified protocol. Think of it as USB-C for AI: instead of building custom integrations for every service, MCP provides one standardized interface. AI models can discover available tools at runtime, understand how to use them, and maintain context across multiple operations — something traditional APIs were never designed for.
What is an MCP server?
An MCP server is a lightweight program that exposes specific capabilities — such as querying a database, calling an API, or reading files — to AI applications via the Model Context Protocol. The AI model connects to the server, discovers what tools are available, and uses them to complete tasks. MCP servers can run locally or as remote services accessible over the network.
How do I build an MCP server?
The traditional approach requires writing a dedicated server in Python, TypeScript, or Go using the MCP SDK — handling transport, tool registration, authentication, and error handling yourself. ToolMesh eliminates this entirely. You describe your API in DADL (Dunkel API Description Language), and ToolMesh automatically exposes it as a fully functional MCP server. No code, no SDK, no custom server infrastructure. Just describe your API once, and any MCP-compatible AI client can use it immediately.
What is the difference between MCP and APIs?
APIs are designed for developers: you read documentation, write integration code, and manage authentication yourself. MCP is designed for AI agents: it lets models discover available tools at runtime, understand their parameters, and use them autonomously. MCP doesn't replace APIs — it builds an AI-friendly layer on top of them. ToolMesh bridges both worlds by turning any REST API (described in DADL) into an MCP-accessible tool without writing glue code.
Is MCP secure?
MCP introduces new security challenges compared to traditional APIs, including prompt injection, tool poisoning, excessive permission scopes, and credential exposure. Security depends entirely on the implementation. ToolMesh addresses these risks through its six-pillar architecture: a server-side CredentialStore for secret management, OpenFGA-based authorization (ReBAC), an Output Gate with DLP policies, and full audit logging. Credentials never reach the AI model — ToolMesh injects them server-side at request time.
What is the difference between MCP and RAG?
RAG (Retrieval-Augmented Generation) enriches AI responses by retrieving relevant documents before generating an answer — it's read-only and focused on knowledge. MCP is broader: it lets AI models both read data and take actions, such as creating records, calling APIs, or triggering workflows. RAG answers questions from a knowledge base; MCP enables the AI to actually do things in external systems. They are complementary — ToolMesh can serve both retrieval and action tools via MCP.
Can I use MCP with ChatGPT?
Yes. OpenAI added MCP support to ChatGPT in 2025. Any remote MCP server accessible via HTTPS can be connected to ChatGPT. ToolMesh provides a remote MCP endpoint out of the box, so APIs described in DADL are automatically available to ChatGPT, Claude, Cursor, and any other MCP-compatible client — without building separate integrations for each platform.
DADL
What is DADL?
DADL (Dunkel API Description Language) is a compact, YAML-based format for describing REST APIs in a way that AI models can understand and use. A single DADL file defines endpoints, parameters, authentication, and response types. ToolMesh reads DADL files and turns them into live MCP tools — no server code required. DADL is open source and designed to be human-readable, version-controlled, and shareable through the DADL Registry.
How does DADL fit into harness engineering?
DADL (Dunkel API Description Language) is effectively Harness-Configuration-as-Code for the tool-registry component of an agent harness. Recent academic work on harness reporting (the HARNESSCARD paper, 2026) points out that most agent-system publications fail to document how their tools were configured — which makes results hard to reproduce. A DADL file is a compact, version-controllable description of every tool a harness exposes, including parameters, authentication, and pagination. Sharing a DADL file is enough to reconstruct the exact tool surface an agent had access to — which is what harness-reporting standards are asking for.
ToolMesh
What is ToolMesh?
ToolMesh is an open-source MCP server aggregator and gateway. It lets you connect multiple APIs and data sources to any AI application through a single MCP endpoint. Instead of building and maintaining individual MCP servers, you describe your APIs in DADL and ToolMesh handles tool registration, credential management, authorization, and request execution. ToolMesh is built in Go, runs as a single Docker container, and is licensed under Apache 2.0.
How is ToolMesh different from other MCP servers?
Most MCP servers expose a single service — one server for GitHub, another for Slack, another for your database. ToolMesh aggregates multiple APIs behind one MCP endpoint. It adds features that individual MCP servers lack: centralized credential management via a pluggable CredentialStore, fine-grained authorization via OpenFGA, an Output Gate for data loss prevention, and a Code Mode for dynamic tool execution. You manage one gateway instead of dozens of separate servers.
Do I need to write code to use ToolMesh?
No. ToolMesh's core workflow is code-free: write a DADL file describing your API, load it into ToolMesh, and your API is available as an MCP tool. DADL files are simple YAML that define endpoints, parameters, and authentication — no programming required. For advanced use cases, ToolMesh's Code Mode allows running custom scripts, but the standard path from API to MCP tool requires zero code.
What APIs work with ToolMesh?
Any REST API can be connected to ToolMesh by describing it in DADL. Pre-built DADL files are available for popular services including GitHub, GitLab, Cloudflare, Stripe, Hetzner Cloud, DeepL, Tailscale, and others through the DADL Registry. You can also write your own DADL for internal or custom APIs. If an API has HTTP endpoints, ToolMesh can expose it as MCP tools.
How does ToolMesh handle API credentials?
ToolMesh stores credentials server-side in its EmbeddedStore — encrypted at rest and never exposed to the AI model or the MCP client. When ToolMesh calls the target API, it injects the correct credentials into the request at runtime, so secrets stay out of prompts, tool descriptions, and tool results. The CredentialStore is a pluggable interface, which means additional backends for centralized secret management can be added without changing how tools are defined.
Is ToolMesh open source?
Yes. ToolMesh is released under the Apache 2.0 license. All current features — including MCP aggregation, DADL support, the CredentialStore, OpenFGA authorization, and the Output Gate — are fully open source and available on GitHub.
Security
How do I restrict the AI to read-only operations — the easy way?
ToolMesh evaluates the access classification (read, write, admin, dangerous) that DADL authors declare per tool, and exposes it to gate policies as ctx.toolAccess. To enforce a read-only posture, copy config/policies/examples/readonly_gate.js from the ToolMesh repo into your active policies directory — that's it. The five-line policy blocks every pre-execution call where the access classification is anything other than read, before the request reaches the backend. No OpenFGA, no roles, no extra services. The policy reads the DADL author's classification — that's the supported model when the operator and the DADL author trust each other (self-hosted DADLs and the curated DADL Registry). Available since ToolMesh v0.2.2.
How do I let the AI write but block destructive operations — the pragmatic middle?
Most production agents do not need full write access removed — they need a foot-gun guard. Copy config/policies/examples/no_dangerous_gate.js instead of the read-only policy. It permits tools classified as read and write but rejects anything tagged admin or dangerous — so the model can create issues, update configuration, and perform routine writes, while irreversible actions like deleting a repository, powering off a device, or dropping a database are blocked at the gate. The blocked levels are a one-line array at the top of the file; change BLOCKED = ["admin", "dangerous"] to fit your risk model. Same caveat as the read-only policy: the gate trusts the DADL author's access: tags.
How do I restrict the AI — the proper way?
For full fine-grained control over which user may invoke which tool, wire authorization through OpenFGA. ToolMesh's model assigns each user to one or more plans, and plans grant access to specific tools — so a support plan might permit only a handful of read tools in Vikunja and the wiki, a developer plan adds GitHub issue creation and code reviews, and an ops plan adds administrative operations. Activate the path with OPENFGA_MODE=restrict and define the user-to-plan-to-tool relationships in config/openfga/tuples.json. Each call is checked against the caller's plan at the AuthZ step, before the gate even runs. Pick this path when different users need different tool sets, when the operator must remain authoritative regardless of what the DADL author declared, or when audit requirements demand per-user granularity. Trade-off: today every tool must be enumerated explicitly in tuples.json — automatic bundling by access classification (e.g. generate a read-only role from every tool tagged access: read) is on the roadmap but not yet shipped. Use the gate path for global default rules, OpenFGA when control needs to vary per user.
Agent harnesses
What is an AI agent harness?
An AI agent harness is the software system that drives a language model through multiple turns of an observe-think-act loop — deciding what to do next, calling tools, reading back results, and keeping state across steps. The term was formally adopted by OpenAI in February 2026, and researchers structure a harness around six components: Execution loop (E), Tool registry (T), Context management (C), State store (S), Lifecycle hooks (L), and Verification/audit (V). Claude Code, OpenHands, DeepAgents, and SemaClaw are all examples of agent harnesses. Recent empirical work (Pi Research, Stanford/MIT, HAL) shows that the harness — not the underlying model — is often the bottleneck for agent performance.
Is ToolMesh an agent harness?
No. ToolMesh does not run the observe-think-act loop — that is the harness's job. ToolMesh is a standalone Tool-Registry + Lifecycle-Hooks layer (the T and L components in the six-component framework) that plugs in behind any harness over MCP. It handles authorization, credential injection, content gating, and full audit, so the harness itself can stay lean. In short: ToolMesh is not a harness — it is what makes a harness good. Claude Code, OpenHands, DeepAgents, SemaClaw, or your own agent framework can all use ToolMesh as their tool-execution backend without giving up their own agent loop.