Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Read Studio output

console
Read-onlyIdempotent

Reads the Roblox Studio Output window to surface prints, warnings, and runtime errors from playtests or execute_luau calls; filter by severity or pattern.

Instructions

Reads the Studio Output window — 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.

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.

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 loaded is recoverable, and output from the playtest client is not reachable at all, because Studio forbids client sessions from making HTTP requests.

A quiet log is not proof nothing was said. Anything the playtest CLIENT printed is never here. 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
levelNoOnly this severity. Omit for everything.
limitNoMaximum items to return (1-500).
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. 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 declare readOnly/idempotent/non-destructive, but the description adds substantial non-obvious behavior: per-session logs keyed to plugin load time, no pre-load history, client output unreachable due to HTTP restrictions, and Studio-emitted messages landing in the session that raised them. The warning about not treating a quiet log as an all-clear is exactly the kind of caveat an agent needs.

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?

Front-loaded and well-structured, with the purpose in the first sentence. It is longer than strictly needed: the fact that client output is unreachable and the 'silence is not an all-clear' point are each stated twice, which costs some tightness.

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, the description carries the return model itself (up to 2000 lines held, newest last) and covers session scoping, filtering, and the key blind spots. An agent has everything needed to call it correctly and interpret empty results.

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 adds usage meaning beyond the schema: level to isolate errors, pattern to follow one subsystem's logging, and a rationale for using filters instead of a large limit. It doesn't add new syntax, but it does add selection guidance for the parameters.

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 the Studio Output window") and enumerates what it contains (prints, warnings, runtime errors, newest last). It routes the agent to siblings explicitly — script_read to open a named script/line and list_studios to find a target session — so it is distinguishable from the rest of the toolset.

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?

Gives explicit triggers ("after a playtest or an execute_luau call") and concrete when-not conditions (client output is never reachable; the editor log will not contain playtest prints). It names alternatives (list_studios, script_read, checking the Output window manually) and advises preferring a filter over a large limit.

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