Roblox BedWars Creative Scripting Tool MCP

Overview Schema Source Related Servers Discussions Admin

connect_sync

Uploads a script folder to the Roblox BedWars editor and opens or replaces a Code Sync connection, optionally watching for future file changes.

Instructions

Upload a folder immediately and establish or replace the active Code Sync connection. Inputs: sync_token (required string from the BedWars editor Sync tab); directory (optional string, default empty: reuse the previous connected directory; required on first connection); glob_pattern (optional string, default empty: read bwconfig.lua syncGlob, otherwise scripts/**/*.lua); watch (optional boolean, default true: automatically upload future matching file changes); allow_empty (optional boolean, default false: permit clearing remote scripts if no files match); probe (optional boolean, default false: write scripts/zz_sync_probe.lua unless allow_empty=true); probe_message (optional string, default empty: use the generated probe message). Effects: uploads the selected file set; on success retains token, folder, and glob in process memory and starts or stops the watcher according to watch. Removes exact legacy generated helper files. Returns upload status, file details, connection/watcher flags, probe, and removed helpers.

Context: Choose to establish a reusable connection or refresh its token; then use sync_connected without resending inputs. It uploads during connection, so it is not a configuration-only action. sync_directory has the same upload/session behavior but always requires directory. Set watch=false for manual syncing. If legacy-helper cleanup leaves no matching files, an empty deletion upload is permitted even with allow_empty=false. Preview first with preview_directory_sync; use probe=true only for an explicitly requested visible test. Tokens are not persisted or returned. Validation and in-game execution are separate steps.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`probe`	No
`watch`	No
`directory`	No
`sync_token`	Yes
`allow_empty`	No
`glob_pattern`	No
`probe_message`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does: it discloses that tokens are not persisted or returned, that token/folder/glob are retained in process memory, that the watcher starts or stops per watch, that legacy helper files are removed, and that validation and in-game execution are separate steps. These are non-obvious side effects an agent needs before invoking a write action.

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 core action and then segmented into Inputs / Effects / Context, which is easy to scan. It is on the long side and some sentences (legacy-helper cleanup behavior) could be tightened, but nearly every line carries actionable information.

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 7-parameter mutation tool with no annotations, the description covers inputs, side effects, session persistence, cleanup behavior, and even notes the output schema's return fields. An agent has everything needed to call it correctly and understand the consequences.

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 0% and the description compensates by documenting all 7 parameters inline with defaults and meaning beyond the schema (e.g. glob_pattern falls back to bwconfig.lua syncGlob then scripts/**/*.lua; directory defaults to reusing the prior connection; probe/allow_empty interaction). This is strong, though the inline prose is dense rather than exhaustive on edge cases like token expiry semantics.

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?

Opens with a specific verb and resource plus scope: 'Upload a folder immediately and establish or replace the active Code Sync connection.' It explicitly distinguishes itself from sync_directory ('same upload/session behavior but always requires directory') and sync_connected, so an agent can route correctly without opening sibling schemas.

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 when-to-use routing: establish/refresh a reusable connection then use sync_connected to avoid resending inputs; set watch=false for manual syncing; preview first with preview_directory_sync; use probe=true only for an explicitly requested visible test. Alternatives and exclusion conditions are all named.

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

Deploy Server