Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx

Capture all print/warn/error log output over a window (MUTATES STATE via LogService)

capture-log-output
Read-onlyIdempotent

Records live Roblox LogService messages into a buffer so you can inspect print, warn, and error output during play, then stop to clear captured state.

Instructions

WRITES LIVE GAME STATE — INSTALLS A PERSISTENT LOG CONNECTION. Connects LogService.MessageOut and records every line the game emits (print, warn, error, and engine messages) into a ring buffer, so you can later read everything that was logged during a window of play. This is the best way to watch a game's own console output over time — see what a script prints when you trigger an action, catch errors/stack traces as they happen, or correlate warnings with behavior. It uses a signal CONNECTION (LogService.MessageOut), NOT a function hook, so it is low-risk compared to the hook-based instrument tools. WORKFLOW (stateful — survives across tool calls via getgenv().__mcp_logCapture): 1. action='start' — connects MessageOut to a handler that pushes { message (first 500 chars), messageType, t } into a 1000-entry ring buffer. Returns { started }. 2. action='fetch' — returns the captured messages (newest-bounded by limit) WITHOUT clearing them; poll while you play. Returns { count, returned, entries }. 3. action='stop' — Disconnects the connection and clears state. Returns { stopped, captured }. CAVEATS: the connection PERSISTS until you stop it (or the client restarts) and fires on every logged line, so a noisy game fills the 1000-entry buffer (oldest dropped). Each message is truncated to 500 chars. Always stop when done. Requires game:GetService('LogService') and getgenv. Returns { error } if a capability is missing, or { notRunning } for fetch/stop when nothing is active. Signature: { action: "start" | "fetch" | "stop", limit: any?, threadContext: number? }. Phase: observe; cost=medium; idempotency=read-only. Requires: active-client. Produces: structured-result. Safety: read-only. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNofetch only: maximum number of messages to return, newest first (default 200, capped at the 1000-entry buffer).
actionYes'start' connects LogService.MessageOut and begins capturing log lines (persistent until stopped); 'fetch' returns captured messages WITHOUT clearing them (poll while you play); 'stop' disconnects and clears all captured state.
threadContextNoOptional Roblox thread identity for this call; omit it to use the server default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-spies.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, destructiveHint=false, idempotentHint), but the description adds far more: the connection persists across calls until stopped, it survives across tool calls via getgenv().__mcp_logCapture, it fires on every logged line, the 1000-entry ring buffer drops oldest entries, messages are truncated to 500 chars, and failure shapes are { error } and { notRunning }. 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?

Front-loaded and well-sectioned (workflow, caveats, error returns), and every sentence carries operational information. It is dense and lengthy, however, with some redundancy between the workflow block and the trailing Signature/Phase/Cost summary, which keeps it short of a 5 on conciseness.

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?

For a stateful, multi-action tool with no output schema, the description supplies return shapes for all three actions ({ started }, { count, returned, entries }, { stopped, captured }), the error variants, prerequisites (game:GetService('LogService'), getgenv), and the persistence caveat. Nothing an agent needs to call this correctly 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% and the schema already documents action, limit, and threadContext, so baseline is 3. The description adds marginal value beyond the schema — it clarifies limit is newest-bounded against the 1000-entry buffer and that fetch does not clear captured messages — which nudges it above baseline but does not introduce syntax or defaults the schema lacks.

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 — connect LogService.MessageOut and record every emitted line into a ring buffer — and immediately scopes it against alternatives ('best way to watch a game's own console output over time', 'low-risk compared to the hook-based instrument tools'). An agent can distinguish it from siblings like get-console-output 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?

Gives an explicit three-step lifecycle (start/fetch/stop) with what each returns, names the concrete scenarios that call for it (see what a script prints when you trigger an action, catch stack traces as they happen), states when to stop, and contrasts it with hook-based tools. Conditions for use and non-use are both present.

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