Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Write (overwrite) a file in the executor workspace (UNC writefile)

write-file
Destructive

Writes content to a file in the executor workspace folder, creating it if needed and overwriting existing contents.

Instructions

Write content to a file in the executor's workspace folder, creating it if needed and OVERWRITING any existing contents. NOTE: this is executor-side file I/O — the connector runs INSIDE the executor, so the path is relative to the executor's workspace directory on the host machine, NOT the Roblox game. Requires the UNC function writefile(path, content). The call is type-guarded and pcall-wrapped: if writefile is missing you get { error = 'writefile is not available in this executor.' }, and any write failure (bad path, denied extension, permission) returns { error = }. Returns { path, ok = true } or { error }. Signature: { path: string, content: string, threadContext: number?, timeoutMs: number? }. Phase: act; cost=medium; idempotency=contextual-write. Requires: active-client, resolved-target, explicit-mutation-approval. Capabilities: executor filesystem. Produces: operation-receipt. Verify with: file-exists. Safety: MUTATING; writes executor workspace filesystem. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the file within the executor workspace folder, e.g. 'config.json'. Existing contents are replaced.
contentYesThe full text content to write to the file.
timeoutMsNoOptional per-call deadline in milliseconds; omit it to use the tool or server default.
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.4/5.0
Behavior5/5

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

Annotations already declare destructive/not-idempotent/openWorld, so the bar is lower, yet the description adds real substance: the UNC writefile dependency, the exact error shape for missing writefile and for write failures, and the success shape { path, ok = true }. That is material behavioral detail beyond what the structured fields convey.

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 with the action and the overwrite warning, then reference detail. Most sentences earn their place, though the internal taxonomy line (Phase: act; cost=medium; idempotency=...) plus the generic 'inspect tool-schema' closer add some boilerplate weight.

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 mutating file-write tool with no output schema, it covers prerequisites, side effects, verification, and both error and success return shapes, so an agent has everything needed to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents path, content, timeoutMs and threadContext. The inline signature restates the same parameters without adding format, default, or constraint semantics beyond what the schema provides, so the baseline 3 applies.

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 precise verb+resource (write content to a file) with explicit scope: 'executor's workspace folder', overwriting existing contents. The clarification that this is executor-side I/O 'NOT the Roblox game' cleanly separates it from read-file, append-file, and the many in-game mutation siblings.

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

Usage Guidelines4/5

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

Gives strong context: requires active-client, resolved-target and explicit-mutation-approval, and names file-exists as the verification step. It implies rather than states when to prefer append-file or create-instance; no explicit when-not/alternative routing sentence beyond the executor-vs-game distinction.

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