EvoMCP: Co-evolving MCP agents and training data

Xuanang Gao; Kepeng Lin; Xinyan Shi; Yong Deng; Shuheng Shen; Changhua Meng; Xiaofeng Wu; Jie Yang

cs.AIOct 30, 2026

EvoMCP: Co-evolving MCP agents and training data

Authors: Xuanang Gao, Kepeng Lin, Xinyan Shi, Yong Deng, Shuheng Shen, Changhua Meng, Xiaofeng Wu, Jie Yang,

Organizations: Shanghai Jiao Tong University · Ant Group · Huazhong University of Science and Technology · Nanjing University of Aeronautics and Astronautics

Abstract

Supervised fine-tuning of Model Context Protocol (MCP) agents is typically conducted on a static data distribution, which fails to adapt to the student's evolving capabilities and leaves newly exposed weaknesses insufficiently addressed. To address these challenges, we propose \method, an agent--data mutual evolution framework that enables MCP agents to improve through a closed loop of task evolution, trajectory evolution, and supervised fine-tuning. Specifically, \method\ assesses the student's established capabilities and capability gaps from rollout feedback to identify learning targets. Task evolution then translates these targets into executable tasks by adapting the instructions and observable environment states of compatible verified seed tasks while keeping their verifiers aligned. To provide reliable and efficient demonstrations for these tasks, trajectory evolution uses reusable skills to recover failed teacher rollouts and refine successful ones. The resulting task--trajectory pairs are used to fine-tune the student, while accepted tasks seed subsequent evolution. To close the loop, we re-evaluate the updated student and use its feedback to guide the next round of data evolution. Experiments on Toolathlon, MCPMark, and MCP-Atlas demonstrate consistent improvements over the initial student, yielding absolute gains of 16.5%, 10.2%, and 12.6%, respectively. Project page: https://github.com/xagao/EvoMCP.

Figures & tables

Figure 1: Self-evolving training in real MCP environments. (a) TOUCAN synthesizes tasks and filters teacher trajectories executed through real MCP tools for SFT ( Xu et al., 2025 ) . (b) EvoMCP uses student rollout feedback to assess capabilities and select learning targets and verified seed tasks. Task evolution adapts task instructions, environment states, or both while keeping verifiers aligned. Trajectory evolution uses reusable skills to recover failed teacher rollouts and refine successful demonstrations. Accepted demonstrations fine-tune the student, and accepted tasks supply seeds for later rounds.

Figure 2: Overview of EvoMCP. A curriculum planner uses student feedback to select learning targets and verified seed tasks. Task evolution adapts task instructions, environment states, or both while keeping their verifiers aligned. Trajectory evolution uses reusable skills to recover failed teacher rollouts and refine successful demonstrations on each fixed task. Accepted demonstrations train the student, and the corresponding tasks become seed tasks for subsequent rounds.

Closed-source agents
Model	Params	Toolathlon	MCPMark	MCP-Atlas
GPT-5.4 (xhigh)	–	54.6	62.5	70.6
Claude Opus 4.5	–	43.5	42.6	69.8
Gemini 3 Pro	–	36.4	53.9	70.3
Open-weight models
Kimi K2.5	1T/32B	27.8	29.5	64.4

Table 1: Performance on three tool-use benchmarks (%). Scores are task success for Toolathlon and Pass@1 for MCPMark and MCP-Atlas. Bold and underlined values mark the highest and second-highest reported scores per benchmark, respectively. Blue rows denote EvoMCP checkpoints. Params gives total/activated parameters. Public reference scores use their original evaluation settings.

Variant	Stud. fb.	Task evo.	Traj. evo.	Toolathlon	MCPMark	MCP-Atlas
Initial student (R0)	–	–	–	36.9	56.7	61.0
Round 1
Static SFT	$\times$	$\times$	$\times$	40.8	57.4	65.8
w/o student feedback	$\times$	$\checkmark$	$\checkmark$	42.2	58.2	66.4
w/o task evolution	$\checkmark$	$\times$	$\checkmark$	42.4	57.4	66.2
w/o trajectory evolution	$\checkmark$	$\checkmark$	$\times$	44.3	59.5	67.8

Table 2: Component ablations at R1 and Static SFT comparisons through R3. Cumulative training steps match per round. Scores (%) use the metrics in Table 1 . Checkmarks indicate enabled components: student feedback (Stud. fb.), task evolution (Task evo.), and trajectory evolution (Traj. evo.). Bold marks each round’s best scores, and shading denotes EvoMCP.

(a) Task evolution
Metric	Seed	Evolved	$\Delta$
Target realization (%)	27.8	85.7	+57.9
Behavior-changing tasks (%)	–	100.0	–
Student failure rate (%)	24.5	45.3	+20.8
Teacher success rate (%)	89.7	78.9	$-10.8$

Table 3: Effects of task and trajectory evolution. (a) Seed–evolved task pairs, with

\Delta

denoting evolved-minus-seed differences in percentage points. (b) Matched verifier-passing teacher demonstrations before and after refinement. AWR denotes avoidable-work ratio. Down arrows indicate lower is better. Shading and boldface identify the evolved condition.

Figure 3: Evolution dynamics across rounds. (a) Benchmark performance from R0 to R3. (b) Task-validity, trajectory-acceptance, and training-pair-admission rates. (c) Turns and tool calls, each normalized by its R0 median, as proxies for interaction workload. (d) Recovered tasks as a percentage of all tasks in each round under a matched teacher-rollout budget. Best-of-K denotes unguided retries.

Appendix figures & tables19 assets

Supplementary material from the paper’s appendix.

Appendix

Setting	Qwen3.6-27B
Training method	Full-parameter SFT
Training trajectories per round	2,400
Epochs per round	3
Optimizer	Adam
Adam betas	$(0.9,0.95)$
Weight decay	$0.1$

Appendix

Table 4: Supervised fine-tuning configuration.

Type	Representative subtypes	Boundary
Planning	Turn-budget exhaustion; redundant search; incorrect ordering	Available actions are arranged into an ineffective plan.
Tool selection	Wrong tool; omitted required tool	An exposed operation is omitted or replaced by an unsuitable one.
Argument	Missing argument; wrong scope; invalid schema	The selected tool is appropriate, but its arguments are not.
Recovery	No retry; repeated failed call; ineffective fallback	Visible failure feedback is not followed by an appropriate response.
Evidence	Incomplete retrieval; source substitution; mismatched evidence	Required evidence is retrievable but collected or associated incorrectly.
Synthesis	Deliverable omission; truncation; format or consistency failure	Evidence is available, but the final response is incomplete or inconsistent.

Appendix

Table 5: Trajectory-failure taxonomy used for diagnosis and skill routing.

Panel of Figure 4 — Figure 4: Ranked-segment reconciliation skill. The procedure partitions ranked groups, reconciles their totals, and checks every requested comparison without retaining source-task values.

Panel of Figure 5 — Figure 5: Complete transient-read recovery skill. This active skill continues evidence collection after a temporary tool rejection while preventing failed calls from being presented as successful observations.

Panel of Figure 6 — Figure 6: Excerpts from the curriculum-planner system prompt. The output assigns learning directions and seeds to construction work orders.

Panel of Figure 7 — Figure 7: Excerpts from the builder system prompt for requirement changes on selected seed environments. Recorded work orders and outputs appear in the cases in Section D.1 .

Panel of Figure 8 — Figure 8: Static instruction used to realize a structured task as a user request.

Panel of Figure 9 — Figure 9: Static instruction used for teacher-failure attribution.

Panel of Figure 10 — Figure 10: Static instruction used to distill a source-grounded recovery skill.

Panel of Figure 11 — Figure 11: Static instruction used for tool-path efficiency assessment.

Panel of Figure 12 — Figure 12: Static instruction used for output-efficiency assessment.

Panel of Figure 13 — Figure 13: Requirement evolution. The planner supplies the learning direction; the builder chooses a concrete change supported by the seed data. The recorded assignment is exploratory. Both the output requirement and its verifier change, while the source environment is reused.

Panel of Figure 14 — Figure 14: Environment variation. Recorded instances from the paired environment evaluation change observable facts and layout while retaining the capability goal. Expected response values and the target form are rebound to each instance. The held-out s21 instance and its teacher trajectory are excluded from SFT.

Panel of Figure 15 — Figure 15: Combining environment and requirement changes. Environment variation first supplies the executable seed; feedback-guided requirement evolution then changes announcement routing on that seed. The final task uses 11 instructor-group destinations while preserving the remaining requirements for all 27 courses.

Panel of Figure 16 — Figure 16: Trajectory-evolution case. The two columns show an abridged trace for the same task. Red rows identify verifier-grounded failures; blue rows show the corresponding skill-guided corrections. The tool calls, intermediate values, and footer statistics come from the complete recorded executions. Claim coverage is the score reported by the task verifier.

Checkpoint	Tasks	Passed	Pass@1 (%)
Initial	310	196	63.23
EvoMCP R1	310	221	71.29
EvoMCP R2	310	228	73.55

Appendix

Table 6: Student performance on the common diagnostic tasks.

Initial outcome	Tasks	R1 passed	R2 passed
Failed	113	60 (53.10%)	65 (57.52%)
Passed	189	154 (81.48%)	155 (82.01%)
All	302	214 (70.86%)	220 (72.85%)

Appendix

Table 7: Resolving initial failures and retaining initial successes. Percentages use the number of tasks in each initial group.

Reference workflow	N	Initial	R1	R2
Calculation-related	99	56.57	73.74	70.71
Other workflows	203	65.52	69.46	73.89
One service	5	100.00	100.00	80.00
Two services	209	64.11	75.12	76.08
At least three services	88	56.82	59.09	64.77

Appendix

Table 8: Diagnostic Pass@1 by reference workflow.

Observed behavior	Initial	R1	R2
YearBuilt predicate	$\geq 2010$	$>2010$	$>2010$
Selected apartments	12	11	11
Reported mean rent	3,293.583	3,387.182	3,387.182
Recorded claim coverage	0.167	1.000	1.000

Appendix

Table 9: Correcting a strict filter boundary. All entries come from recorded tool calls and answers for the same task.

LLM Agent Training

Large language model agent training teaches models to plan, use tools, and learn from multi-step interaction with environments.

See all 602 papers

MCPEvol-Bench: Benchmarking LLM Agent Performance Across Dynamic Evolutions of MCP Servers
Jul 16, 2026Huanxi Liu, Kun Hu, Jiaqi Liao +6Tool-Use Evaluation AI Agent Benchmarks
College of Computer Science and Technology, National University of Defense Technology · State Key Laboratory of Complex & Critical Software Environment · National Key Laboratory of Parallel and Distributed Computing
EE-MCP: Self-Evolving MCP-GUI Agents via Automated Environment Generation and Experience Learning
Apr 10, 2026Tiantian He, Yihang Chen, Keyue Jiang +4Computer-Use Agents Self-Improving Agents
University College London · Huawei Noah’s Ark Lab · The Chinese University of Hong Kong +2
MCPDisCo: Seesaw-Mitigated Tuning for MCP-Native Agents
Oct 10, 2026Kounianhua Du, Jianxing Liu, Shuai Shao +3RL for LLM Agents Agentic RL
Shanghai Jiao Tong University, Shanghai, China · Tencent. Shanghai, China

Jul 16, 2026J/K move · Enter open · S save

MCPEvol-Bench: Benchmarking LLM Agent Performance Across Dynamic Evolutions of MCP Servers

Huanxi Liu, Kun Hu, Jiaqi Liao, Qiang Wang+5

College of Computer Science and Technology, National University of Defense Technology · State Key Laboratory of Complex & Critical Software Environment · National Key Laboratory of Parallel and Distributed Computing

Tool-Use Evaluation AI Agent Benchmarks Model Context Protocol LLM Agents

Open paper AskPDF arXiv

As Model Context Protocol (MCP) servers emerge as the core infrastructure for connecting LLMs with external tools, existing benchmarks leverage real-world MCP servers to evaluate LLM agents' tool-using capabilities. However, these benchmarks overlook the continuous evolution of tool interfaces and functionalities within MCP servers, resulting in flawed assessments that fail to capture the agent's adaptability in changing tool landscapes. To bridge this gap, we introduce MCPEvol-Bench, a novel benchmark for evaluating the task-solving capabilities of LLM agents under dynamic toolset evolution. Inspired by large-scale empirical study, we propose 11 mutation operators to simulate realistic tool evolution within 123 MCP servers. We benchmark 12 state-of-the-art LLMs on multiple versions of MCP servers, revealing that even frontier models struggle to adapt to evolving tools. For instance, GPT-5.4 and Claude-Sonnet-4-6 exhibit performance declines of 13.7% and 14.4% in evolved MCP servers, respectively, accompanied by substantial increases in planning and reasoning errors. These findings highlight the vulnerability of LLM-driven workflows, establishing MCPEvol-Bench as a standard for evaluating agent adaptability in dynamic tool environments.

Abstract

LLM Agent Training

Explore similar work

MCPEvol-Bench: Benchmarking LLM Agent Performance Across Dynamic Evolutions of MCP Servers

EE-MCP: Self-Evolving MCP-GUI Agents via Automated Environment Generation and Experience Learning

MCPDisCo: Seesaw-Mitigated Tuning for MCP-Native Agents