Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Read Studio output

console
Read-onlyIdempotent

Reads Roblox Studio or playtest client output—prints, warnings, runtime errors—to diagnose what happened after a playtest or script execution. Filter by level or pattern.

Instructions

Reads Studio or playtest client output — prints, warnings and runtime errors, newest last.

This is how to find out what actually happened after a playtest or an execute_luau call. An error here usually names the script and line, which script_read can then open directly.

Use target="client" with the playtest server studioId to read continuously captured client output. In multiplayer, select a player by name. Pass the returned nextCursor as since to read only newer lines; cursors belong to one session and player. Evicted or limit-skipped lines are reported.

Filter with level to see only errors, or pattern to follow one subsystem's logging. Up to 2000 lines are held, so prefer a filter over a large limit.

mode="drain" reads a busy log without gaps: oldest unread matches first, and a cursor that stops at the first one not shown. Keep the same filters while draining. group collapses identical lines into one with a count. An error whose stack trace arrived late comes back once more, marked update.

Each connected session keeps its own log, recorded from the moment its plugin loaded — the editor session and a running playtest server do not share one. To read what a playtest printed, target the playtest's studioId (see list_studios); the editor's log will not have it. Nothing printed before the plugin or client relay loaded is recoverable.

A quiet log is not proof nothing was said. Messages Studio itself emits — the ones the Output window attributes to "Studio" rather than to a script — are inconsistent, and they arrive in the session that RAISED them, which is not always the one you are looking at: the warning that a Script with a non-legacy RunContext inside a starter container will run multiple times shows up in the playtest server's log, where the script actually loads, and never in the editor's, where it was created. Do not read silence as an all-clear — when a script misbehaves in a way nothing here explains, check the Output window yourself, or ask the user what it says.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'tail': the newest matches, cursor at the end of the log. 'drain': the oldest unread matches, cursor at the first one not shown, so a loop reads every line once.tail
groupNoCollapse identical lines into one row with a count and first/last times.
levelNoOnly this severity. Omit for everything.
limitNoMaximum items to return (1-500).
sinceNoOpaque nextCursor from a previous console response; return only newer matching lines.
playerNoClient only: player name, required when multiple players are present.
targetNoOutput source; client requires a running playtest server studioId.studio
patternNoLua pattern the message must match, e.g. "Combat" or "^%[Server%]". Lua patterns escape with %, not backslash.
studioIdNoTarget Studio; omit for the active one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.6
    • addedInput schema / properties / group
      Added value: +{
+  "default": false,
+  "description": "Collapse identical lines into one row with a count and first/last times.",
+  "type": "boolean"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "tail",
+  "description": "'tail': the newest matches, cursor at the end of the log. 'drain': the oldest unread matches, cursor at the first one not shown, so a loop reads every line once.",
+  "enum": [
+    "tail",
+    "drain"
+  ],
+  "type": "string"
+}
  2. Changed3 schema fields changedv0.7.8
    • addedInput schema / properties / player
      Added value: +{
+  "description": "Client only: player name, required when multiple players are present.",
+  "type": "string"
+}
    • addedInput schema / properties / since
      Added value: +{
+  "description": "Opaque nextCursor from a previous console response; return only newer matching lines.",
+  "type": "string"
+}
    • addedInput schema / properties / target
      Added value: +{
+  "default": "studio",
+  "description": "Output source; client requires a running playtest server studioId.",
+  "enum": [
+    "studio",
+    "client"
+  ],
+  "type": "string"
+}
  3. First observedv0.1.8

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only/idempotent safety profile, yet the description adds substantial behavior beyond them: cursor is session-and-player scoped, 2000-line eviction, late stack traces reappearing as 'update', drain-mode cursor semantics, and the caveat that silence is not an all-clear. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long (nine parameters, dense caveats), but front-loaded with the purpose and mostly earned sentences. Some repetition exists — session isolation is stated twice and the closing paragraph on Studio-emitted messages runs long — which keeps it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and nine parameters, the description still covers return semantics (nextCursor, update marker, evicted/skipped lines reported) and the multi-session model an agent must understand to target the right log. Nothing essential to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description goes further: it explains that cursors belong to one session/player, that filters must stay stable while draining, and that a filter beats a large limit. It doesn't restate every enum, which the schema already handles, so 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Reads Studio or playtest client output — prints, warnings and runtime errors') and immediately distinguishes itself from siblings execute_luau and script_read by positioning itself as the way to see what happened after a run. An agent can tell it apart from script_read/script_grep without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('after a playtest or an execute_luau call'), when to choose target="client" vs the editor log, when to filter vs raise limit, and a clear boundary case ('check the Output window yourself, or ask the user'). Alternatives and their selection conditions are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools