Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Chrrxs/robloxstudio-mcp/llms.txt

Use this file to discover all available pages before exploring further.

The multiplayer_playtest tool automates Roblox Studio’s StudioTestService-based multi-client sessions, letting an agent spin up a server and several simulated clients, then route runtime eval, log reads, and property queries to specific peers. This makes it possible to reproduce and inspect multiplayer-specific bugs—race conditions, replication issues, per-player state divergence—without switching between Studio windows by hand.
action="end" is permanently disabled. StudioTestService:EndTest() is broken in this flow — calling it produces an error from the Roblox engine. As a result, multiplayer_playtest action="end" always returns a disabled error. Multiplayer test windows must be closed manually. Before starting a multiplayer test, pass force=true to confirm you understand this limitation and will close the windows yourself when done.

​
Workflow

1

Start the multiplayer test

Launch a StudioTestService session with the desired number of client players. force=true is required and signals that you accept the manual-close limitation.
multiplayer_playtest action="start" numPlayers=2 force=true
The tool waits up to 30 seconds (configurable via timeout) for all peer connections to register, then returns a brief lifecycle status.
2

Check session status

Verify the session is running and all peers are detected:
multiplayer_playtest action="status"
3

Discover connected peers

Use get_connected_instances to list all connected Studio places and their runtime roles. In a multiplayer session you will see separate entries for the server peer, client-1, client-2, and so on.
get_connected_instances
The returned instance_id values route tool calls to a specific place when multiple places are connected simultaneously.
4

Evaluate on the server

Run Luau in the game’s server Script VM to inspect server-side state:
eval_server_runtime code="return MatchService.activeMatches"
5

Evaluate on a specific client

Target a particular client’s LocalScript VM by passing its peer name:
eval_client_runtime code="return Players.LocalPlayer.leaderstats.Score.Value"
                    target="client-2"
This runs inside client-2’s game LocalScript VM, sharing the same require cache as that client’s scripts.
6

Read per-peer logs

In a StudioTestService multiplayer session, peer attribution in get_runtime_logs is reliable — each log entry includes the peer it originated from. Use target="all" to merge and deduplicate across all capture buffers simultaneously.
get_runtime_logs target="all"
To read only the server buffer:
get_runtime_logs target="server"
Peer attribution is only reliable in StudioTestService multiplayer sessions. In ordinary solo playtests (solo_playtest), LogService reflects logs across all peers, so the script-origin peer cannot be determined and entries omit the peer field.
7

Add another player mid-session

Dynamically join an additional client to the running session without restarting:
multiplayer_playtest action="add_players" numPlayers=1
8

Remove a specific client

Disconnect one client from the session while keeping the rest running. This is useful for testing disconnection handling and reconnect logic.
multiplayer_playtest action="leave_client" target="client-1"
9

Close Studio windows manually

When you are done testing, close the multiplayer test windows in Studio by hand. There is no action="end" equivalent — see the warning above.

​
Solo vs. multiplayer: key differences

FeatureSolo (solo_playtest)Multiplayer (multiplayer_playtest)
PeersServer + 1 clientServer + N clients (1–8)
Peer log attributionNot reliable (LogService reflects all)Reliable — entries include peer
Client targeting for evaleval_client_runtime target="client-1"Same, plus client-2, client-3, etc.
Stop/endsolo_playtest action="stop"Manual window close only
Window managementAutomaticManual
force=true requiredNoYes, for action="start"

​
Per-peer data from analysis tools

Several analysis tools return per-peer data during a multiplayer session. You can read memory and scene breakdowns for the server or any specific client: 
# Memory breakdown for the server peer
get_memory_breakdown target="server"

# Memory breakdown for client-2
get_memory_breakdown target="client-2"

# Scene analysis — returns attribution per peer
get_scene_analysis target="server"
Pass the appropriate target value to route each call to the peer you are inspecting. Use get_connected_instances first if you are unsure which peer labels are active in the current session.
Use eval_client_runtime with incremental since polling on get_runtime_logs to watch for state divergence between two clients in real time. Eval the same expression on client-1 and client-2 in sequence, then compare the returned values to detect replication bugs.

Build docs developers (and LLMs) love

Get started for freeTalk to us