pith. sign in

arxiv: 2605.28148 · v1 · pith:NTMXP3GMnew · submitted 2026-05-27 · 💻 cs.SE · cs.AI

DeltaMCP: Incremental Regeneration via Spec-Aware Transformation for MCP servers

Aditya Pujara , Xiaogang Zhu , Hsiang-Ting Chen This is my paper

Pith reviewed 2026-06-29 11:02 UTC · model grok-4.3

classification 💻 cs.SE cs.AI
keywords MCP serversOpenAPI specificationincremental regenerationAPI maintenanceLLM agentsenterprise APIstool generationspecification-aware transformation
0
0 comments X

The pith

DeltaMCP updates only the affected MCP server tools when an OpenAPI specification changes.

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

DeltaMCP is a tool that takes a changed OpenAPI specification and produces updates limited to the affected tooling inside an MCP server instead of rebuilding the whole server. The approach targets the recurring task of keeping MCP implementations aligned with evolving enterprise APIs that power LLM agents. Evaluation on Azure REST API specifications compares the method to full regeneration baselines and reports lower developer effort along with better maintainability and version consistency.

Core claim

DeltaMCP is introduced as a specification-aware incremental regeneration tool for enterprise-grade MCP servers. It maps changes from a new release of a service's OpenAPI specification to a minimal set of updates in the corresponding MCP tool implementations. When benchmarked against full generation methods on Azure REST API specifications, the approach reduces developer overhead while improving maintainability and version consistency.

What carries the argument

DeltaMCP's spec-aware transformation that identifies and regenerates only the affected MCP tool implementations from OpenAPI changes.

If this is right

  • Developers update only the tooling that actually changes instead of regenerating entire MCP servers on each API release.
  • Version consistency between the OpenAPI specification and the MCP implementation is preserved through targeted updates.
  • Maintenance overhead decreases for enterprise systems that must keep MCP servers aligned with frequently updated services.
  • The method supports scaling MCP server infrastructure for LLM-based agents without proportional increases in regeneration cost.

Where Pith is reading between the lines

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

  • The same change-mapping logic could be adapted to keep other API-to-tool bridges in sync beyond the MCP setting.
  • Integration into automated pipelines might allow continuous updates whenever a service publishes a new OpenAPI version.
  • The approach leaves open the question of how to handle specification changes that affect tool dependencies or shared code.

Load-bearing premise

Changes in an OpenAPI specification can be reliably mapped to a minimal set of affected MCP tool implementations without requiring full regeneration or introducing inconsistencies.

What would settle it

A concrete OpenAPI change where DeltaMCP produces an MCP server missing required functionality or containing inconsistencies that a full regeneration would have avoided.

Figures

Figures reproduced from arXiv: 2605.28148 by Aditya Pujara, Hsiang-Ting Chen, Xiaogang Zhu.

Figure 1
Figure 1. Figure 1: Architecture of DeltaMCP clients [1] [7]. Finally, MCP contracts can also share predefined prompts to it’s users to allow them to get started and learn how to interact with the server [1] [7]. However, given this enablement of communication between agents and backend servers, security is paramount as information shared is generally sensitive and potentially consistent of PII (Personally Identifiable Inform… view at source ↗
Figure 2
Figure 2. Figure 2: Data Processing Pipeline for DeltaMCP in a curated dataset consisting of more than 2000 high granularity samples, en￾abling fine-grained behavioral learning that retains transformation locality. For LLMs to learn transformation patterns directly from empirical changes, 3 LLM models were fine-tuned using the Low-Rank Adaptation (LoRA) method [16]. LoRA injects lightweight rank-constrained adaptation layers … view at source ↗
Figure 3
Figure 3. Figure 3: Mean CPU and memory consumption during incremental regeneration [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Tools touched per update across version increments. Lower is better. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Comparative code generation quality across version transitions based on [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
read the original abstract

The rapid development of LLMs coupled with the introduction of Model Context Protocol (MCP) has revolutionized how intelligent agents interact with APIs through deterministic and structured methods \cite{ModelContextProtocolIntro2025}. While some existing systems like AutoMCP attempt to automate a previously completely manual process of generating MCP servers, they fail to address the recurring challenge of maintaining synchronization between evolving enterprise-level APIs and their corresponding MCP toolset implementation \cite{mastouri2025makingrestapisagentready}. This paper introduces DeltaMCP, a specification-aware, incremental regeneration tool for enterprise-grade MCP servers. DeltaMCP enables developers to only update the affected tooling of MCP servers, given a new release of it's corresponding service's OpenAPI specification. Using Azure REST API specifications as the evaluation dataset, DeltaMCP is benchmarked against baseline full generation methods on generation quality and system performance. The results demonstrate the reduction in developer overhead through DeltaMCP whilst improving maintainability and version consistency. This research offers a scalable approach for enterprises seeking to maintain high-fidelity, up-to-date MCP server infrastructures for LLM-based systems.

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.

Referee Report

2 major / 1 minor

Summary. The paper introduces DeltaMCP, a specification-aware, incremental regeneration tool for enterprise-grade MCP servers. It claims to enable developers to update only the affected tooling of MCP servers when a new release of the corresponding service's OpenAPI specification is available. The work benchmarks DeltaMCP against baseline full generation methods using Azure REST API specifications as the evaluation dataset, asserting reductions in developer overhead while improving maintainability and version consistency.

Significance. If the incremental regeneration approach proves reliable, it would address a significant practical challenge in maintaining synchronization between evolving APIs and MCP tool implementations for LLM-based systems. This could reduce maintenance costs for enterprises using MCP servers. However, the current manuscript provides insufficient detail to assess whether the results hold.

major comments (2)
  1. Abstract: The abstract states that benchmarking was performed on Azure REST API specifications but supplies no methods, metrics, or results; the central claim of reduced overhead cannot be evaluated from available text.
  2. Abstract: The core mechanism of spec-aware transformation for incremental updates is not described, including no change-detection rules or consistency guarantees, making it impossible to verify the assumption that OpenAPI changes can be mapped to a minimal set of affected MCP tools without inconsistencies or need for full regeneration.
minor comments (1)
  1. Abstract: Typo: 'it's corresponding' should be 'its corresponding'.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed feedback. We agree that the abstract requires expansion to better convey the evaluation methods, metrics, results, and core mechanism. We will revise the abstract in the next version while ensuring the full manuscript already provides the supporting details in the methods and evaluation sections.

read point-by-point responses

  1. Referee: Abstract: The abstract states that benchmarking was performed on Azure REST API specifications but supplies no methods, metrics, or results; the central claim of reduced overhead cannot be evaluated from available text.

    Authors: We agree that the abstract is overly concise and omits key details on methods, metrics, and results. The full manuscript (Section 4) describes the benchmarking setup using Azure REST API specifications, comparing DeltaMCP against full regeneration baselines on metrics including regeneration time, number of tools updated, and overhead reduction percentages. We will revise the abstract to summarize these elements, e.g., noting the observed reductions in developer overhead and the specific performance metrics, so the central claims can be evaluated from the abstract alone. revision: yes

  2. Referee: Abstract: The core mechanism of spec-aware transformation for incremental updates is not described, including no change-detection rules or consistency guarantees, making it impossible to verify the assumption that OpenAPI changes can be mapped to a minimal set of affected MCP tools without inconsistencies or need for full regeneration.

    Authors: We acknowledge the abstract does not describe the mechanism. Section 3 of the manuscript details the spec-aware transformation, including change detection via structural diffing of OpenAPI specs, mapping rules that identify affected MCP tools based on operation/schema modifications, and consistency guarantees through dependency graph analysis to prevent inconsistencies. We will add a concise description of this process to the abstract to address the concern directly. revision: yes

Circularity Check

0 steps flagged

No circularity: tool description without derivation chain

full rationale

The paper presents DeltaMCP as an engineering tool for incremental MCP server updates from OpenAPI diffs. No equations, fitted parameters, predictions, or uniqueness theorems appear in the provided text. Citations reference external prior work on MCP and REST-to-agent mapping without self-citation load-bearing the core claim. The contribution is a practical regeneration approach evaluated on Azure specs; the mapping logic is described at the system level rather than reduced to a self-referential definition or fit. This is a standard non-circular tool paper.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review; no equations, parameters, or formal assumptions are stated in the provided text.

pith-pipeline@v0.9.1-grok · 5728 in / 894 out tokens · 30761 ms · 2026-06-29T11:02:28.837439+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

21 extracted references · 9 canonical work pages · 5 internal anchors

  1. [1]

    What is the model context protocol (mcp)?

    M. C. Protocol, “What is the model context protocol (mcp)?” https:// modelcontextprotocol.io/docs/getting-started/intro, 2025, accessed: 2025-10-29

    2025

  2. [2]

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

    M. Mastouri, E. Ksontini, and W. Kessentini, “Making rest apis agent-ready: From openapi to mcp servers for tool-augmented llms,” 2025. [Online]. Available: https://arxiv.org/abs/2507.16044

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  3. [3]

    A. M. (2025, July) Llm statistics 2025: Comprehensive insights into market trends and integration. Accessed: 2025-10-29. [Online]. Available: https: //www.hostinger.com/tutorials/llm-statistics

    2025

  4. [4]

    Deep learning for code generation: a survey,

    H. Zhang, K. Zhang, Z. Li, J. Li, Y. Li, Y. Zhao, Y. Zhu, F. Liu, G. Li, and Z. Jin, “Deep learning for code generation: a survey,”Science China Information Sciences, vol. 67, no. 9, p. 191101, 2024

    2024

  5. [5]

    A survey of large language models for code: Evolution, benchmarking, and future trends,

    Z. Zheng, K. Ning, Y. Wang, J. Zhang, D. Zheng, M. Ye, and J. Chen, “A survey of large language models for code: Evolution, benchmarking, and future trends,”

  6. [6]

    Available: https://arxiv.org/abs/2311.10372

    [Online]. Available: https://arxiv.org/abs/2311.10372

    work page arXiv

  7. [7]

    What is openapi?

    OpenAPI Initiative, “What is openapi?” https://www.openapis.org/ what-is-openapi, n.d., accessed: 2025-10-30

    2025

  8. [8]

    A survey of agent interoperability protocols: Model context protocol (mcp), agent communication protocol (acp), agent-to-agent protocol (a2a), and agent network protocol (anp),

    A. Ehtesham, A. Singh, G. K. Gupta, and S. Kumar, “A survey of agent interoperability protocols: Model context protocol (mcp), agent communication protocol (acp), agent-to-agent protocol (a2a), and agent network protocol (anp),”

  9. [9]

    Available: https://arxiv.org/abs/2505.02279

    [Online]. Available: https://arxiv.org/abs/2505.02279

    work page arXiv

  10. [11]

    Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions

    ——, “Model context protocol (mcp): Landscape, security threats, and future research directions,” 2025. [Online]. Available: https://arxiv.org/abs/2503.23278

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  11. [12]

    Brandon Radosevich and John Halloran

    B. Radosevich and J. Halloran, “Mcp safety audit,”arXiv preprint arXiv:2504.03767, 2025

    work page arXiv 2025

  12. [13]

    Simplified and secure mcp gateways for enterprise integration,

    I. Brett, “Simplified and secure mcp gateways for enterprise integration,”arXiv preprint arXiv:2504.19997, 2025

    work page arXiv 2025

  13. [14]

    The Co-Evolution of Test Maintenance and Code Maintenance through the lens of Fine-Grained Semantic Changes

    S. Levin and A. Yehudai, “The co-evolution of test and code maintenance,”arXiv preprint arXiv:1709.09029, 2017

    work page internal anchor Pith review Pith/arXiv arXiv 2017

  14. [15]

    Fastmcp,

    “Fastmcp,” 2025. [Online]. Available: https://gofastmcp.com/integrations/ openapi

    2025

  15. [16]

    azure-rest-api-specs: The source for rest api specifications for mi- crosoft azure,

    M. Azure, “azure-rest-api-specs: The source for rest api specifications for mi- crosoft azure,” GitHub repository, Microsoft Azure, 2025, https://github.com/ Azure/azure-rest-api-specs

    2025

  16. [17]

    oasdiff: Openapi diff and breaking changes,

    oasdiff Authors, “oasdiff: Openapi diff and breaking changes,” 2025, gitHub repository, Apache-2.0 license. [Online]. Available: https://github.com/oasdiff/ oasdiff 12 Pujara et al

    2025

  17. [18]

    LoRA: Low-Rank Adaptation of Large Language Models

    E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang, L. Wang, and W. Chen, “Lora: Low-rank adaptation of large language models,” 2021. [Online]. Available: https://arxiv.org/abs/2106.09685

    work page internal anchor Pith review Pith/arXiv arXiv 2021

  18. [19]

    Phi-3 mini-4k instruct,

    Microsoft, “Phi-3 mini-4k instruct,” https://huggingface.co/microsoft/ Phi-3-mini-4k-instruct, 2024, accessed: 2025-10-31

    2024

  19. [20]

    Starcoder2- 7b,

    A. Lozhkov, R. Li, L. Ben Allal, F. Cassano, J. Lamy-Poirier, N. Tazi, A. Tang, D. Pykhtar, J. Liu, Y. Wei, T. Liu, D. Kocetkov, A. Zucker, Y. Belkada, Z. Wang, Q. Liu, D. Abulkhanov, I. Paul, Z. Li, W.-D. Li, M. Risdal, J. Li, J. Zhu, T. Y. Zhuo, E. Zheltonozhskii, N. Osae Osae Dade, W. Yu, L. Krauß, N. Jain, Y. Su, X. He, M. Dey, E. Abati, Y. Chai, N. M...

    2024

  20. [21]

    Codellama:7b,

    Ollama Inc., “Codellama:7b,” https://ollama.com/library/codellama:7b, 2023, ac- cessed: 2025-10-31

    2023

  21. [22]

    FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness

    T. Dao, D. Y. Fu, S. Ermon, A. Rudra, and C. R´ e, “Flashattention: Fast and memory-efficient exact attention with io-awareness,” 2022. [Online]. Available: https://arxiv.org/abs/2205.14135

    work page internal anchor Pith review Pith/arXiv arXiv 2022