---
title: 'MCP-Cosmos: World-Model Augmented MCP Agents'
url: https://www.emergentmind.com/topics/mcp-cosmos
type: topic
---

# MCP-Cosmos: World-Model Augmented MCP Agents

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 [2605.09131].

## 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 [2605.09131].

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 [2605.09131].

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 [2605.09131].

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 [2604.09815].

## 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 [2605.09131].

The world-model interface is intentionally minimal:

```python
class WorldModel(ABC):
    def __init__(self, model_name: str, **kwargs):
        pass

    async def simulate(
        self, tool_call: str, user_request: str, context: Optional[str] = None
    ) -> Dict[str, Any]:
        pass
```

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 [2605.09131].

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 [2605.09131].

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 [2605.09131].

## 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 [2605.09131].

| 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 [2605.09131].

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,

$$
\tilde{o}_t \gets \text{WorldModel}(a_t),
$$

updates the simulated trajectory, and continues until a stopping condition indicates that the plan is complete. The selected plan $\mathcal{P}$ 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 [2605.09131].

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 [2605.09131].

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 [2605.09131].

## 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 [2605.09131].

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

$$
\text{Task Completion} = \frac{\text{Task Fulfillment} + \text{Grounding}}{2},
$$

Tool Selection as

$$
\text{Tool Selection} = \frac{\text{Tool Appropriateness} + \text{Parameter Accuracy}}{2},
$$

and Planning Effectiveness as

$$
\text{Planning Effectiveness} = \frac{\text{Dependency Awareness} + \text{Parallelism Efficiency}}{2}.
$$

The original overall score is then

$$
\text{Overall}_{\text{orig}} =
\frac{\text{Task Completion} + \text{Tool Selection} + \text{Planning Effectiveness}}{3}.
$$

All of these are reported as percentages [2605.09131].

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,

$$
\widehat{\text{Avg Tool Calls}} =
\frac{\text{max\_avg\_calls} - \text{agent\_avg\_calls}}
{\text{max\_avg\_calls} - \text{min\_avg\_calls}} \times 100,
$$

and then averaging it with Tool Call Success:

$$
\text{Execution Quality} =
\frac{\text{Tool Call Success} + \widehat{\text{Avg Tool Calls}}}{2}.
$$

A new overall score is then defined as

$$
\text{Overall}_{\text{new}} =
\frac{\text{Task Completion} + \text{Tool Selection} + \text{Planning Effectiveness} + \text{Execution Quality}}{4}.
$$

The paper explicitly notes that Execution Quality is experiment-relative because the min-max normalization is computed over the evaluated cohort [2605.09131].

## 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 [2605.09131].

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 [2605.09131].

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$_{\text{new}}$ ≈ 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$_{\text{new}}$ ≈ 56.5% [2605.09131].

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$_{\text{new}}$ ≈ 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% [2605.09131].

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 [2605.09131].

## 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 [2509.09734]. 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 $10^5$–$10^6$ tokens per task, very low completion-to-prompt ratios, and strong incentives for parallel tool calls and robust abort mechanisms [2511.07426]. 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 [2605.09131].

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 [2605.09131]. 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 [2504.12757] [2509.24272] [2603.10194] [2605.22333] [2508.12538] [2505.23634]. 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 [2605.09131].

Source: https://www.emergentmind.com/topics/mcp-cosmos