MCP-Cosmos: World-Model Augmented MCP Agents

• MCP-Cosmos is a framework that integrates MCP tool calls, world models, and agents to simulate and plan actions before real execution.
• It adopts a BYOWM strategy that enables any compatible world model to predict tool call outcomes, enhancing tool selection and parameter accuracy.
• Empirical results demonstrate that world-model augmentation reduces unnecessary tool calls and improves overall execution quality in complex MCP environments.

MCP-Cosmos is a framework and evaluation suite for world-model-augmented MCP agents. It treats MCP tool calls as environment actions, uses world models to simulate their consequences in a latent or pseudo environment, and then executes a vetted plan on real MCP servers. In this formulation, MCP becomes the standardized execution substrate, the world model becomes a predictive simulator of tool effects, and the agent becomes a planner-controller that can reason over simulated trajectories before committing to live actions (Ganapavarapu et al., 9 May 2026).

1. Conceptual scope and problem setting

MCP-Cosmos is motivated by a specific gap in MCP-based agent design: task-level planning often ignores execution-time dynamics, while reactive execution lacks long-horizon foresight. The framework addresses this by unifying three components: MCP, World Model, and Agent. Within this unification, an MCP tool call is an action $a_t$, a tool response is an observation $o_t$, and the world model approximates the transition structure needed to predict the consequences of candidate actions before they are executed (Ganapavarapu et al., 9 May 2026).

The framework adopts a "Bring Your Own World Model" (BYOWM) strategy. Under BYOWM, the agent does not require a single fixed simulator; rather, any world model that can simulate a tool call in context can be inserted into the planning loop. This makes MCP-Cosmos a systems architecture rather than a single model family. The paper explicitly frames this as a move from purely reactive ReAct-style execution toward predictive cognition, in which the agent simulates state transitions and refines plans before acting in the real environment (Ganapavarapu et al., 9 May 2026).

The underlying state representation is abstract rather than fully symbolic. In practice, state is the conversation-plus-plan context: the user query, the history of simulated or executed tool calls, their observations, and the planner’s scratchpad. Actions are MCP tool calls represented textually, while transitions are modeled as either real observations $o_t$ from the MCP environment or simulated observations $\tilde{o}_t$ from the world model. The intended transition approximation is:

$p(s_{t+1}\mid s_t, a_t)$

with the simulator operationalized through pseudo-observations rather than an explicit latent-state dynamics model (Ganapavarapu et al., 9 May 2026).

This suggests that MCP-Cosmos belongs to a broader shift in MCP research toward treating MCP environments as structured decision processes rather than as ad hoc collections of callable functions. Related work on hybrid MCP-GUI agents makes a similar move by formalizing action selection over structured tool and environment interfaces, although with different objectives and benchmarks (He et al., 10 Apr 2026).

2. System architecture and BYOWM interface

The architecture is organized into two explicit phases. First, a planning phase runs in a latent or pseudo environment. The planner proposes candidate tool calls, forwards them to the world model, receives simulated observations, and refines the plan. Second, the chosen plan is executed against real MCP servers, producing the actual execution trajectory and the final answer. The paper emphasizes that this layer sits on top of MCP: neither MCP servers nor tools need modification (Ganapavarapu et al., 9 May 2026).

The world-model interface is intentionally minimal:

$o_t$4

The tool_call is a textual description of an MCP invocation, typically including tool name and arguments. The user_request is the original task. The context can hold prior simulated state. The return value is a simulated observation $\tilde{o}_t$, which need not exactly match the real tool schema; it may instead summarize likely outputs, likely errors, or downstream effects. That design choice is central to BYOWM: MCP-Cosmos does not require a perfect symbolic emulator, only a simulator useful for planning (Ganapavarapu et al., 9 May 2026).

At the agent level, the framework wraps planners in a WMInfusedAgent abstraction with a world_model argument and an execute method. The same interface supports three operational modes: no world model, a world-model-augmented sequential planner, or a search-based planner using world-model rollouts. Because the execution loop is externalized, the same MCP environment can be driven by different planning substrates without changing server-side code (Ganapavarapu et al., 9 May 2026).

The real and simulated trajectories are kept distinct. A world-model trajectory is:

$$\tau_{\text{wm}} = \{(a_0, \tilde{o}_0), \dots, (a_k, \tilde{o}_k)\},$$

while the execution trajectory is:

$\tau = \{(a_0, o_0), \dots\}.$

This distinction is important because the paper’s later metrics show that a planner can improve tool selection and execution quality without necessarily improving final task completion to the same degree (Ganapavarapu et al., 9 May 2026).

3. Planning algorithms and use of world models

MCP-Cosmos evaluates three agent architectures: a baseline ReAct agent with no world model, a ReAct-Plan-Exec variant that uses the world model during planning, and a SPIRAL-Exec variant that uses MCTS-style search with world-model rollouts (Ganapavarapu et al., 9 May 2026).

Agent	Planning substrate	Execution pattern
ReAct	None	Real MCP calls interleaved with reasoning
ReAct-Plan-Exec	Sequential LLM planning with WM simulation	Plan first, then execute
SPIRAL-Exec	MCTS-style search with WM rollouts	Search first, then execute

The baseline ReAct loop is standard: read task, generate thought and action, execute the real MCP tool immediately, observe the result, and continue until enough evidence has been accumulated to answer. Its strength is live adaptation. Its weakness is what the paper terms horizon myopia: the agent learns through trial and error in the real environment, often producing retries, redundant calls, or irreversible missteps (Ganapavarapu et al., 9 May 2026).

ReAct-Plan-Exec inserts an explicit planning phase before real execution. At step $t$, the planner proposes an action

$a_t \gets \pi_{\text{plan}}(s_t),$

queries the world model,

$o_t$0

updates the simulated trajectory, and continues until a stopping condition indicates that the plan is complete. The selected plan $o_t$1 is then executed on the real MCP servers. In the benchmarked configuration, plan revision on execution failure was available in the algorithmic formulation but disabled in the experiments due to cost (Ganapavarapu et al., 9 May 2026).

SPIRAL-Exec replaces sequential planning with search. It uses Structured Planning with Iterative Reflection and Lookahead, described as an MCTS-style planner. Candidate tool sequences form branches of a search tree; the world model supplies simulated observations along each branch; and heuristic scoring backs up branch quality to select a final plan. The paper notes that this formulation naturally supports parallelization in planning and is more explicit about dependency structure than ReAct-style generation (Ganapavarapu et al., 9 May 2026).

Three world models are evaluated: gpt-oss-120b, claude-sonnet-4.6, and Arctic-AWM-4B. The first two are generic LLM-based world models. Arctic-AWM-4B is a purpose-built MCP world model trained using a synthetic environment generation pipeline. In the reported benchmark, however, the generic LLM world models outperform the specialized AWM model on the selected task set (Ganapavarapu et al., 9 May 2026).

4. Benchmarking methodology and metric design

The evaluation uses a subset of MCP-Bench rather than MCP-Universe. The paper states that MCP-Bench was chosen because it offers 28 live MCP servers, 257 tools, fuzzy realistic tasks, judged metrics with strong human agreement, and an explicit failure mode taxonomy. The MCP-Cosmos subset contains 24 tasks covering 12 task types, with emphasis on 2-server and 3-server tasks where cross-server dependencies are critical. The experiments produce more than 300 trajectories across planner and world-model combinations (Ganapavarapu et al., 9 May 2026).

The original metric hierarchy is inherited from MCP-Bench. Task Completion is defined as

$o_t$2

Tool Selection as

$o_t$3

and Planning Effectiveness as

$o_t$4

The original overall score is then

$o_t$5

All of these are reported as percentages (Ganapavarapu et al., 9 May 2026).

The paper argues that these metrics underweight the main intended benefit of world models: reducing failed or unnecessary environment interactions. It therefore introduces additional execution-facing metrics. The first is tool call success rate. The second is average number of tool calls per task. These are combined into Execution Quality by first defining a min-max normalized inverse call-count score,

$o_t$6

and then averaging it with Tool Call Success:

$o_t$7

A new overall score is then defined as

$o_t$8

The paper explicitly notes that Execution Quality is experiment-relative because the min-max normalization is computed over the evaluated cohort (Ganapavarapu et al., 9 May 2026).

5. Empirical results, ablations, and efficiency trade-offs

With gpt-oss-120b as planner, baseline ReAct achieves Overall ≈ 36.1%, with Task Completion = 41.7%, Tool Selection = 36.4%, and Planning Effectiveness = 30.1%. The best original-metric result is SPIRAL-Exec + gpt-oss-120b world model, with Overall ≈ 44.8%, Task Completion ≈ 41.9%, Tool Selection ≈ 60.3%, and Planning Effectiveness ≈ 32.3%. ReAct-Plan-Exec + claude-sonnet-4.6 world model reaches Overall ≈ 42.4%, with Tool Selection = 59.5% and Parameter Accuracy = 65.9%. In contrast, the Arctic-AWM-4B variants improve Tool Selection and Parallel Efficiency over baseline but lag generic LLM world models overall (Ganapavarapu et al., 9 May 2026).

These numbers support a specific interpretation. The world-model layer consistently improves tool selection and parameter accuracy. It does not, however, guarantee a proportional gain in Task Completion. The baseline ReAct agent remains competitive on Task Fulfillment and Task Completion because direct trial-and-error in the real environment can compensate for weaker planning. World-model planning instead improves decisiveness and reduces waste in environment interaction (Ganapavarapu et al., 9 May 2026).

That pattern becomes much sharper under Execution Quality. Baseline ReAct has Tool Call Success = 77.7%, Average tool calls = 7.04, and therefore Execution Quality ≈ 38.9%, with Overall$o_t$9 ≈ 36.8%. All world-model agents reach Tool Call Success = 100%, with Average tool calls between 1.12 and 7.91 and Execution Quality between 87.7% and 100%. The best new-overall result is SPIRAL-Exec + gpt-oss-120b world model, with Execution Quality ≈ 91.4% and Overall$o_t$0 ≈ 56.5% (Ganapavarapu et al., 9 May 2026).

The ablation with a stronger planner is especially revealing. ReAct with gpt-oss-120b uses 7.04 tool calls per task and 63.7 seconds of execution time. ReAct with claude-sonnet-4.6, without a world model, increases to 29.78 tool calls per task and 214.9 seconds. The stronger planner improves accuracy but explores much more aggressively. When paired with world models, however, claude-sonnet-4.6 is constrained back toward efficient execution: ReAct-Plan-Exec + WM reduces tool calls to 6.91–7.91, and SPIRAL-Exec + WM reduces them further to 1.83–1.92 calls per task. Under the new overall metric, ReAct + claude-sonnet-4.6 baseline reaches Overall$o_t$1 ≈ 52.9%, while ReAct-Plan-Exec + gpt-oss-120b world model reaches ≈ 61.5% and ReAct-Plan-Exec + claude-sonnet-4.6 world model reaches ≈ 60.2% (Ganapavarapu et al., 9 May 2026).

The principal cost of this strategy is prompt and simulation overhead. Baseline ReAct with gpt-oss-120b uses about 50K tokens per task. World-model agents use 82K–302K tokens per task, or 1.6–6× more. SPIRAL + Arctic-AWM-4B is the most expensive among the gpt-oss-120b-planner variants at about 302K tokens per task, while under claude-sonnet-4.6 planning the SPIRAL + Arctic-AWM-4B configuration reaches 686K tokens per task. The appendices report that prompt tokens dominate at roughly 9× output tokens. The trade-off is therefore explicit: fewer failed and redundant real tool calls are obtained by spending more planning-time context and simulation budget (Ganapavarapu et al., 9 May 2026).

6. Relation to the wider MCP ecosystem, limitations, and significance

MCP-Cosmos addresses one part of a larger MCP systems problem: predictive planning over tool-mediated environments. Complementary evaluation work asks a different question, namely how well agents perform across broad tool ecologies. For example, MCP-AgentBench builds a 33-server, 188-tool testbed with 600 queries and an outcome-oriented pass-rate metric, emphasizing heterogeneity and protocol-mediated task completion rather than world-model-guided plan quality (Guo et al., 10 Sep 2025). This suggests a useful division of labor: MCP-Cosmos studies planning under complex multi-server dependencies, while broader benchmarks measure general MCP agent capability across server and interaction classes.

Operational work on MCP also highlights why the efficiency side of MCP-Cosmos matters. Measurement studies of MCP-enabled agents show that MCP interactions are often prompt-heavy, with total token use frequently reaching $o_t$2–$o_t$3 tokens per task, very low completion-to-prompt ratios, and strong incentives for parallel tool calls and robust abort mechanisms (Ding et al., 20 Oct 2025). Against that backdrop, MCP-Cosmos can be read as an attempt to exchange some planning-time token cost for fewer real environment errors, fewer tool retries, and higher tool parameter accuracy (Ganapavarapu et al., 9 May 2026).

At the same time, the paper does not claim to solve the broader deployment problem. Its stated limitations include a static environment snapshot, the computation cost of world-model simulation, gaps in existing MCP-Bench metrics, simulation fidelity and compounding-error risks, and the fact that destructive or write-heavy operations are not the main focus of the current evaluation (Ganapavarapu et al., 9 May 2026). This is significant because several MCP security papers show that malicious tool metadata, compromised servers, weak authorization boundaries, and prompt-injection-style tool misuse are already pervasive concerns in real MCP deployments (Kumar et al., 17 Apr 2025, Zhao et al., 29 Sep 2025, Kumar et al., 10 Mar 2026, Zhou et al., 21 May 2026, Guo et al., 18 Aug 2025, Halloran, 29 May 2025). A plausible implication is that world-model planning will be especially valuable when tool calls are not merely expensive, but also irreversible or security-sensitive, although that extension remains outside the demonstrated benchmark.

Within the MCP literature, the main contribution of MCP-Cosmos is therefore architectural and methodological. Architecturally, it defines a clean BYOWM interface and a plan-then-execute pattern for MCP agents. Methodologically, it argues that world models should be evaluated not only by final task success but also by execution-facing criteria such as tool success rate, parameter accuracy, and call efficiency. Empirically, it shows that world-model augmentation can improve Tool Selection and Parameter Accuracy substantially, and that under an execution-aware metric the best world-model planner materially outperforms a strong reactive baseline (Ganapavarapu et al., 9 May 2026).