arxiv: 2605.05247 · v1 · submitted 2026-05-04 · 💻 cs.SE

Recognition: 3 theorem links

· Lean Theorem

DADL: A Declarative Description Language for Enterprise Tool Libraries in LLM Agent Systems

Axel Dunkel

Authors on Pith no claims yet

Pith reviewed 2026-05-08 17:35 UTC · model grok-4.3

classification 💻 cs.SE

keywords DADLdeclarative descriptionREST APIsLLM agentstool librariescontext reductionenterprise integrationYAML

0 comments

The pith

Declarative YAML reduces LLM tool context by 142 times while centralizing credentials.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces DADL, a YAML format for describing REST APIs with their endpoints, authentication, pagination, response shaping, and access classification. A shared execution layer interprets these files at runtime instead of deploying separate servers for each integration. This allows all tools to share one runtime where credentials and authorization are managed centrally. The full catalog reaches the LLM through a fixed-size Code Mode interface whose token cost does not grow with the number of tools. On a catalog of 1,833 definitions, this cuts the context cost of advertising tools from 142,000 tokens to about 1,000.

Core claim

DADL is a declarative YAML language that captures a REST API's endpoints, authentication, pagination, response shaping, and access classification in a single file. The file is interpreted by an execution layer at runtime; no per-API server process is deployed and no integration code is generated. Because all tools share that runtime, credentials and authorization are managed centrally, and the catalog reaches the LLM through a fixed-size Code Mode interface independent of size. The result is an Enterprise Tool Library: a versioned, auditable collection of API integrations any team can extend, share, and consume through one authentication and authorization boundary.

What carries the argument

DADL, a YAML declarative description of REST API behaviors interpreted by a single shared runtime server that presents tools via a constant-size Code Mode interface to the LLM.

If this is right

Credentials and authorization are managed at one central boundary for the entire tool catalog.
The context cost for the LLM to learn about available tools stays fixed even as the library grows to thousands of entries.
API integrations become versioned and auditable files that teams can share without redeploying servers.
Changes to how an API is called or secured require only editing the YAML description.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Teams could more easily enforce consistent security policies across all external services used by agents.
This setup may reduce the engineering overhead of adding new tools by allowing reuse of declarative descriptions.
Registries of DADL files could emerge as a way to share integration knowledge without sharing code.

Load-bearing premise

That the full range of REST API behaviors, including complex authentication flows, dynamic pagination, error handling, and response shaping, can be captured completely and correctly in a declarative YAML format without requiring per-API custom code or generated integration logic.

What would settle it

Testing whether a complex real-world API involving multi-step OAuth, cursor pagination, and custom error responses can be fully executed using only its DADL description in the runtime, without any additional code.

Figures

Figures reproduced from arXiv: 2605.05247 by Axel Dunkel.

**Figure 1.** Figure 1: Side-by-side architectural comparison of the conventional one-MCP-server-per-API model (left) with the DADL + Code Mode model (right). The left side shows N independent server processes, each with its own runtime and deployment, exposing NxM individual tool schemas that overflow the LLM context window. The right side shows a single shared runtime that interprets per-API DADL files; the agent reaches the en… view at source ↗

read the original abstract

The Model Context Protocol (MCP) is the standard interface between large language model (LLM) agents and external tools. At organizational scale, however, it exposes two structural problems. First, every API integration is shipped as a dedicated server process with its own deployment, dependency tree, and credential handling; recent empirical work shows the overwhelming majority of these servers are thin wrappers around REST APIs. Second, the per-tool registration model causes context window consumption to grow linearly with catalog size, forcing real deployments to expose only a small fraction of the APIs an organization actually uses. We present DADL (Dunkel API Description Language), a YAML format describing a REST API's endpoints, authentication, pagination, response shaping, and access classification in a single declarative file. A DADL file is interpreted by an execution layer at runtime; no per-API server process is deployed and no integration code is generated, though the runtime is itself a server. Because all tools share that runtime, credentials and authorization are managed centrally, and the catalog reaches the LLM through a fixed-size Code Mode interface independent of size. The result is an Enterprise Tool Library: a versioned, auditable collection of API integrations any team can extend, share, and consume through one authentication and authorization boundary. The DADL v0.1 specification is released under CC BY-SA 4.0, and a public registry contains 1,833 tool definitions across 20 services. On this catalog, Code Mode reduces the context cost of tool advertisement from approximately 142,000 tokens to approximately 1,000, a 142x reduction; the per-call cost of search and execute invocations is additional and depends on the task.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

DADL gives a declarative YAML route to large enterprise tool catalogs for LLM agents with fixed context cost, but the evidence that it covers real REST complexity without extra code is missing.

read the letter

DADL introduces a YAML format that describes REST endpoints, auth, pagination, response shaping, and access rules in one file, then runs everything through a shared interpreter instead of per-tool servers. The fixed-size Code Mode interface keeps the LLM's view of the whole catalog at roughly 1,000 tokens regardless of size. On their registry of 1,833 definitions this produces the reported 142x drop in advertisement cost. The Enterprise Tool Library idea—versioned, centrally governed, and shareable—directly targets the two scaling headaches that come up in real deployments: deployment overhead and context bloat.

Referee Report

2 major / 1 minor

Summary. The paper introduces DADL (Dunkel API Description Language), a YAML format for declaratively specifying REST API endpoints, authentication, pagination, response shaping, and access classification. It argues that a shared runtime interpreting these files eliminates per-API server processes and dedicated integration code, while a fixed-size Code Mode interface replaces linear per-tool context growth; on a public registry of 1,833 definitions across 20 services, this yields a claimed 142x reduction in tool-advertisement tokens (from ~142k to ~1k).

Significance. If the declarative format proves sufficient to capture full REST behaviors without per-definition extensions, the work could meaningfully reduce deployment friction and context overhead for enterprise-scale LLM agent tool libraries, with the released v0.1 spec and public registry offering a reusable artifact for the community.

major comments (2)

[Abstract] Abstract: the 142x token-reduction claim is stated as an empirical result on the 1,833-definition catalog, yet the manuscript supplies no measurement methodology, no description of how the fixed-size Code Mode interface was implemented for comparison, and no coverage or error analysis of the declarative format.
[Abstract] Abstract / DADL description: the architectural advantage (elimination of per-API servers and fixed-size interface) rests on the assumption that DADL YAML can completely and correctly encode complex behaviors including multi-step OAuth, cursor-based pagination with state, conditional error shaping, and dynamic response handling. No worked examples, coverage metrics, or documented failure cases are provided to support this.

minor comments (1)

[Abstract] The term 'Code Mode interface' is introduced without a reference to its specification or a diagram showing its fixed-size structure relative to the per-tool MCP model.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed and constructive review. We address each major comment below and indicate the revisions that will be incorporated to strengthen the manuscript.

read point-by-point responses

Referee: [Abstract] Abstract: the 142x token-reduction claim is stated as an empirical result on the 1,833-definition catalog, yet the manuscript supplies no measurement methodology, no description of how the fixed-size Code Mode interface was implemented for comparison, and no coverage or error analysis of the declarative format.

Authors: We agree that the abstract states the 142x reduction without describing the measurement approach or implementation details. The submitted manuscript presents the result at a high level in the abstract and defers technical specifics to the DADL specification and registry artifact. To address this directly, we will revise the abstract to include a concise methodology statement (token counts obtained via cl100k_base tokenizer on serialized MCP tool lists versus the fixed-size Code Mode JSON schema) and add a short evaluation paragraph summarizing coverage (all 1,833 definitions encoded without extensions) along with basic error analysis. These additions will also be expanded in a new dedicated evaluation section. revision: yes
Referee: [Abstract] Abstract / DADL description: the architectural advantage (elimination of per-API servers and fixed-size interface) rests on the assumption that DADL YAML can completely and correctly encode complex behaviors including multi-step OAuth, cursor-based pagination with state, conditional error shaping, and dynamic response handling. No worked examples, coverage metrics, or documented failure cases are provided to support this.

Authors: The referee is correct that the abstract provides no concrete examples or metrics to demonstrate coverage of the listed behaviors. The v0.1 specification document (released with the paper) contains the grammar and illustrative snippets for OAuth flows and pagination, while the public registry of 1,833 definitions across 20 services provides implicit coverage evidence. However, the manuscript itself does not include worked examples or explicit failure-case discussion in the abstract or main text. We will therefore revise the abstract to reference one representative worked example (e.g., cursor pagination with state) and add a brief coverage statement. A new subsection on limitations, documented failure cases, and coverage metrics will be added to the evaluation section of the revised manuscript. revision: yes

Circularity Check

0 steps flagged

No circularity: token reduction is direct empirical measurement on provided catalog

full rationale

The paper's central quantitative claim is an empirical count: on the authors' registry of 1,833 definitions, the fixed-size Code Mode interface reduces advertised tokens from ~142,000 to ~1,000. This is presented as a measured comparison between the new interface and the linear per-tool baseline on the same data; no equations, fitted parameters, or self-referential definitions derive the ratio. The architectural claims rest on the assertion that DADL YAML fully captures REST behaviors (auth, pagination, etc.) without custom code, supported by the existence of the registry, but this coverage is not shown to reduce to any prior input or self-citation by construction. No load-bearing self-citations, uniqueness theorems, or ansatzes appear in the provided text. The derivation chain is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 2 invented entities

The central claim rests on the domain assumption that REST API integrations can be fully specified declaratively; the paper contributes the new language and interface rather than deriving results from prior fitted parameters.

axioms (1)

domain assumption REST APIs can be fully described for runtime execution by specifying endpoints, authentication, pagination, response shaping, and access classification in a declarative YAML format.
This assumption enables the claim that a single shared runtime suffices without per-API servers or generated code.

invented entities (2)

DADL (Dunkel API Description Language) no independent evidence
purpose: Declarative YAML format for describing REST APIs for LLM agent use
Newly introduced language specification in the paper.
Code Mode interface no independent evidence
purpose: Fixed-size presentation of the tool catalog to the LLM independent of catalog size
New interface design introduced to solve linear context growth.

pith-pipeline@v0.9.0 · 5604 in / 1600 out tokens · 75886 ms · 2026-05-08T17:35:07.462251+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

15 extracted references · 8 canonical work pages · 3 internal anchors

[1]

Function calling and other API updates

OpenAI. Function calling and other API updates. OpenAI Blog, June 2023

2023
[2]

Model Context Protocol specification

Anthropic. Model Context Protocol specification. https://modelcontextprotocol.io, 2024

2024
[3]

X. Hou, Y. Zhao, S. Wang, and H. Wang. Model Context Protocol (MCP): Landscape, security threats, and future research directions. arXiv:2503.23278, 2025

work page internal anchor Pith review arXiv 2025
[4]

From REST to MCP: An Empirical Study of API Wrapping and Automated Server Generation for LLM Agents

M. Mastouri, E. Ksontini, A. Barrak, and W. Kessentini. From REST to MCP: An empirical study of API wrapping and automated server generation for LLM agents. arXiv:2507.16044, 2025

work page internal anchor Pith review Pith/arXiv arXiv 2025
[5]

M. M. Hasan, H. Li, E. Fallahzadeh, G. K. Rajbahadur, B. Adams, and A. E. Hassan. Model Context Protocol (MCP) at first glance: Studying the security and maintainability of MCP servers. arXiv:2506.13538, 2025

work page internal anchor Pith review Pith/arXiv arXiv 2025
[6]

Mcp safety audit: Llms with the model context protocol allow major security exploits

B. Radosevich and J. Halloran. MCP Safety Audit: LLMs with the Model Context Protocol allow major security exploits. arXiv:2504.03767, 2025

work page arXiv 2025
[7]

Lumer, A

E. Lumer, A. Gulati, V. K. Subbiah, P. Basavaraju, and J. A. Burke. MemTool: Optimizing short-term memory management for dynamic tool calling in LLM agent multi-turn conversations. arXiv:2507.21428, 2025

work page arXiv 2025
[8]

X. Ni, Q. Wang, Y. Zhang, and P. Hong. ToolFactory: Automating tool generation by leveraging LLM to understand REST API documentations. arXiv:2501.16945, 2025

work page arXiv 2025
[9]

Sharif, and Yaser Mohammadi Banadaki

A. Ahmadi, S. Sharif, and Y. Mohammadi Banadaki. MCP Bridge: A lightweight, LLM-agnostic RESTful proxy for Model Context Protocol servers. arXiv:2504.08999, 2025

work page arXiv 2025
[10]

OpenAPI Specification v3.1.0

OpenAPI Initiative. OpenAPI Specification v3.1.0. https://spec.openapis.org/oas/v3.1.0, 2021

2021
[11]

Low-Code CDK: Pagination

Airbyte. Low-Code CDK: Pagination. https://docs.airbyte.com, 2025

2025
[12]

OpenFGA: Fine-grained authorization

OpenFGA project. OpenFGA: Fine-grained authorization. https://openfga.dev, 2024

2024
[13]

R. Pang, R. Cáceres, M. Burrows, Z. Chen, P. Dave, N. Germer, A. Golynski, K. Graney, N. Kang, L. Kissner, J. L. Korn, A. Parmar, C. D. Richards, and M. Wang. Zanzibar: Google's consistent, global authorization system. USENIX Annual Technical Conference, 2019

2019
[14]

Kedrick, W

K. Kedrick, W. Yang, T. Gebhart, Y. Wang, and R. J. Funk. Opening knowledge gaps drives scientific progress. arXiv:2509.21899, 2025

work page arXiv 2025
[15]

F. P. Brooks Jr. The computer scientist as toolsmith II. Communications of the ACM, 39(3):61–68, 1996

1996