> ## Documentation Index
> Fetch the complete documentation index at: https://docs.burn0.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Server

> Expose an environment's tools over the Model Context Protocol

<Note>
  Not built yet. This page describes what is planned. Today, agents reach an environment's tools through the [agent contract](/silo/agents/overview) — a function Silo calls with `callTool`.
</Note>

An MCP server would expose a Silo environment's tools over the Model Context Protocol, so any MCP-capable client could act inside a simulated world without writing an agent module.

```bash theme={null}
# planned
npx @burn0/silo mcp --env demo
```

## What it would unlock

**Drive a simulated world from an existing MCP client.** Point a client that already speaks MCP at a Silo environment and its 42 CRM tools become available as ordinary tools — no adapter, no glue.

**Try an environment by hand.** Ask for a stalled deal, reassign it, see what the tools say, before writing any agent code. Today the fastest way to explore a tool surface is a scripted agent and a trace.

**Evaluate agents you did not write.** Anything that speaks MCP could be pointed at an environment, which widens what Silo can measure beyond agents you can wrap in a function.

## The open question

Silo's value comes from a rollout being a **bounded, graded unit**: one fresh world, one task, one verdict, one set of artifacts. An MCP session is the opposite shape — a long-lived connection with no natural start or end.

So the design question is not how to expose the tools. It is what a rollout means over a session:

* When does the world get created, and when is it graded?
* Does one connection map to one task, or can a client switch tasks?
* What does a trace look like when the client, not Silo, decides when work is finished?

Those answers determine whether `state-diff.json` and `result.json` still mean anything. Getting it wrong would make MCP a way to poke at an environment without ever producing an evaluation — interesting, but not what Silo is for.

## What works today

Write an agent function. It is a small contract, and a model loop in any framework fits it in a few lines:

<Card title="Bring Your Own Agent" icon="robot" href="/silo/agents/overview">
  The full contract, tool errors as values, and where a model loop plugs in.
</Card>

For exploring a tool surface by hand, a scripted agent plus `trace.jsonl` gives you the same information today — see [Debug a Failed Run](/silo/guides/debug-a-failed-run).