Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

Read Studio output

console
Read-onlyIdempotent

Read Roblox Studio output logs to see prints, warnings, and errors after playtesting, with filtering by severity and 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.

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.
Behavior5/5

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

Description adds context beyond annotations: it explains that output is only available after plugin loaded, that client sessions are not reachable due to HTTP restrictions, and that filtering is available. No contradictions with readOnlyHint or idempotentHint.

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

Conciseness5/5

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

The description is structured: first states purpose, then usage context, then filtering tips, then session details. Although longer than the minimal, every sentence contributes valuable information without redundancy.

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?

Given there is no output schema, the description gives enough context: it specifies the content (prints, warnings, errors) and ordering (newest last). It also covers all parameters and edge cases (client sessions, pre-load). It is complete for an agent to call correctly.

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

Parameters5/5

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

Each parameter is described in schema, and the description adds clarifications: pattern uses Lua escaping with %, studioId affects which session's log is read, limit default and max are mentioned. This adds meaning beyond the schema.

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?

Clearly states it reads the Studio Output window with specific content (prints, warnings, errors) and order (newest last). The verb and resource are specific, distinguishing it from sibling tools like script_read or execute_luau.

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?

Explicitly mentions when to use it: after a playtest or execute_luau call to find out what happened. Provides filtering guidance (use level and pattern) and warns about limit. Also explains session-specific behavior, telling users to target the playtest studioId.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EL4CTEO/rbx-studio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server