Skip to content

View a model

When the MCP host renders MCP Apps views, the Screenplay server 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 and 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.

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.

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.

ClientDraws the board
Claude DesktopYes
GitHub Copilot in VS CodeYes
Claude CodeNo, it is a terminal client
CodexNot listed by the MCP Apps documentation as a host that draws views

The MCP Apps documentation keeps the current list of hosts. In a client that does not draw the board, use the VS Code extension to see a model, and keep using Explore a model 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 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.

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.

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

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:

{ "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.

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

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:

{
"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.

MCP boardVS Code extension
Opens fromA prompt in the conversationA .play file
Follows your editsPolls disk when the host allows server calls; otherwise redraws on requestRedraws as you type
Shows a proposal or sketchYesNo
Needs the MCP serverYesNo

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