---
title: View a model
editUrl: https://github.com/Cratis/Screenplay/edit/main/Documentation/screenplay/mcp/view.md
description: Draw a Screenplay application as an event model board inside an MCP host, and see what a proposal or a what-if sketch would change before anything is written.
---


When the MCP host renders [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview)
views, the [Screenplay server](/screenplay/mcp/reference/) can draw the application as the same event
model board as Cratis Studio and the VS Code extension. Use it to look at what is
there, and to see what a change would do to the model before it is written.

Use **Cratis.Screenplay.Tool 4.47.0 or later**, or **CLI versions that bundle
Screenplay 4.47.0 or later**. CLI hosting alone does not guarantee MCP Apps support.
See [installation](/screenplay/mcp/install/) and [See your event model](/screenplay/see-your-event-model/)
for the same board in other places.

![The Screenplay MCP App shows a proposed Notifications module beside Commerce's fulfillment flows. Its SendOrderConfirmation command produces OrderConfirmationSent; the surrounding frame identifies the local capture harness.](../images/mcp-app-what-if-harness.png)

*Captured in a minimal MCP Apps test host (a local capture harness), not a
commercial chat host. The capture uses a single-file Commerce adaptation and an
unsaved what-if sketch.*

## Which clients show the board

The board is an MCP App: an HTML view the host draws inside the conversation. The
server offers it, as the `visualize-model` tool, only to hosts that advertise the MCP
Apps extension (`io.modelcontextprotocol/ui`) when they connect. Other clients see
the server's usual tools, without `visualize-model`.

| Client | Draws the board |
| --- | --- |
| Claude Desktop | Yes |
| GitHub Copilot in VS Code | Yes |
| Claude Code | No, it is a terminal client |
| Codex | Not listed by the MCP Apps documentation as a host that draws views |

The [MCP Apps documentation](https://modelcontextprotocol.io/extensions/apps/overview)
keeps the current list of hosts. In a client that does not draw the board, use the
[VS Code extension](/screenplay/vscode/) to see a model, and keep using
[Explore a model](/screenplay/mcp/explore/) in the terminal.

The board is always drawn in its dark theme, even when the host asks for a light
one. Its labels are colored for a dark surface, the same as in Studio's viewer and
the VS Code extension, and would be unreadable on a light background. In a
light-themed chat it shows as a dark panel.

## Show the model on disk

```text
Show me the application as an event model board.
```

The assistant calls `visualize-model` without arguments. The board shows every
`.play` document under the server root, compiled as one application. The model
receives a short summary, such as how many slices, events, reactions and errors the board
shows. The documents themselves go only to the board.

The board has the Cratis logo in its upper left and its toolbar in its upper
right. *View* sets the detail level, whether properties are shown and whether
connections are drawn as arrows or lines. Where the host allows it, the toolbar
also draws the board again from disk and switches to fullscreen.

The board follows the model on disk. While it is on screen it checks every couple of
seconds and draws again when a file changed, whether the assistant applied a change
or you edited a file by hand. Open it fullscreen and keep prompting: each applied
change shows up on its own. A proposal you are looking at stays until the files
change, and then the board shows the application as it is. The refresh button in the
toolbar draws it again at once, and reports why when it cannot.

Hosts that do not let a view call the server cannot follow the files. Ask for the
board again there; every call draws the model as it is at that moment.

## Dependency map

Choose **Map** beside **Board** to inspect module and feature dependencies.
The map follows **Current** or **Proposed**, including what-if sketches. Modules
are columns in suggested producer-first order, features sit inside them, and
imported bounded contexts appear on the right. Arrows run from consumer to producer.

Choose edges between **Modules** or **Features**. The initial filters show
**uses facts from**, **reacts to**, and **decides from**; enable the other kinds
when needed. Edge labels count slice pairs. Select an edge to see the references
under each slice pair, with their kind, name and source location. Tab moves into
the drawing; arrow keys move between nodes and edges, Enter selects, and Escape clears.
Choose **Board** to return to the timeline. The map does not change the model or
highlight the board, and inferred dependencies do not prove executable readiness.

If the board cannot read or draw the model, **Board** and **Map** stay in the
toolbar. The Board view says why, and the Map stays available when the dependencies
were compiled. A failure in one view leaves the other in place. If compiling gives no
map, the Map view says it is unavailable. A selection stays when the view refreshes, as long as the
item still exists, and switching between **Current** and **Proposed** clears it.

## See what a proposal would change

Ask for a change, and ask to see it before it is applied:

```text
Add a ReturnBook slice to the Lending module that produces BookReturned. Propose
it, then show me the board for that proposal so I can see what it adds.
```

After an authoring call returns a `proposalId`, the assistant calls `visualize-model`
with it:

```json
{ "proposalId": "<proposalId>" }
```

The board starts on the application as the proposal would leave it. *Current* and
*Proposed* in the toolbar switch between that and the application as it is. What
both share keeps its place, so the difference is what moves. The summary lists
the modules, features, slices, commands, events, read models, screens and reactions
the proposal adds and removes. Nothing is written: review and `apply` the proposal
as described in [Edit a model](/screenplay/mcp/edit/#review-and-apply).

## Sketch a what-if

To see how a piece of functionality could look before shaping it into a proposal,
ask for a sketch:

```text
Without changing anything, sketch what a Reservations feature could look like next
to the existing Lending module, and show it on the board. Do not propose it yet.
```

The assistant passes whole `.play` documents as a `sketch`, with paths relative
to the model root. Multi-file sketches require Screenplay 4.59.1 or later, or a
CLI that bundles it; older versions such as 4.48.0 have sketch-path failures.
For a model whose complete source is `application.play`, this example replaces
that document for the view only:

```json
{
  "sketch": [
    { "path": "application.play", "source": "module Orders\n  feature Returns\n    slice StateChange RegisterReturn\n      command RegisterReturn\n        produces ReturnRegistered\n      event ReturnRegistered\n" }
  ]
}
```

Each document replaces the one at its path, or is added when there is none. The
sketch is drawn over the documents on disk exactly as a proposal is, with the same
*Current* and *Proposed* switch and the same summary. It is never validated as a
proposal, never kept, and never written. A sketch that does not compile is drawn
as far as it can be read, with the number of errors shown on the board. Pass
either `proposalId` or `sketch`, not both.

Ask for the board again after each change to the sketch or the model: every call
draws a new board, from the model as it is at that moment.

## Compare with the VS Code extension

| | MCP board | VS Code extension |
| --- | --- | --- |
| Opens from | A prompt in the conversation | A `.play` file |
| Follows your edits | Polls disk when the host allows server calls; otherwise redraws on request | Redraws as you type |
| Shows a proposal or sketch | Yes | No |
| Needs the MCP server | Yes | No |

Use the extension while you write, and the MCP board to review what an assistant is
about to write.