Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Disable / enable / disconnect signal connections

set-connection-state
Destructive

Toggle or permanently remove connections on an RBXScriptSignal: disable/enable handlers reversibly or disconnect them entirely; scope one or all, with confirm required for destructive actions.

Instructions

MUTATES CLIENT STATE. Toggles or removes connections on an RBXScriptSignal: 'disable' temporarily stops a connection from firing (reversible with 'enable'), 'enable' re-activates a disabled connection, and 'disconnect' permanently removes it — IRREVERSIBLE for that connection (you would have to recreate it). scope='one' targets a single connection by index; scope='all' applies to every connection on the signal. Because they are destructive, scope='all' and action='disconnect' BOTH require confirm=true or the tool refuses without changing anything. Useful for silencing or surgically removing event handlers (e.g. anti-cheat or input listeners) while debugging. Requires getconnections plus the connection's Disable/Enable/Disconnect methods; degrades with a clear { error } if unavailable. Returns { Signal, Instance?, Action, Scope, Affected } or { error }. Signature: { instancePath: string, signalName: any?, action: "disable" | "enable" | "disconnect", scope: any?, connectionIndex: any?, confirm: any?, threadContext: number? }. Phase: act; cost=medium; idempotency=idempotent-write. Requires: active-client, resolved-target, explicit-mutation-approval. Capabilities: getconnections. Produces: created-handle, operation-receipt. Verify with: assert-state. Safety: MUTATING; writes live game/client state. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNo'one' (default) affects only the single connection at connectionIndex; 'all' affects every connection on the signal and REQUIRES confirm=true.one
actionYesWhat to do to the matched connection(s): 'disable' = stop firing but keep it (reversible via 'enable'); 'enable' = re-activate a disabled connection; 'disconnect' = permanently remove it (IRREVERSIBLE, requires confirm=true).
confirmNoSafety gate for destructive operations. Must be true to run when scope='all' OR action='disconnect'; otherwise the tool refuses without making changes. Not required for disable/enable on a single connection.
signalNameNoName of the RBXScriptSignal member on the instance (e.g. 'Touched', 'Changed'). Leave empty/omit if instancePath already evaluates to the signal.
instancePathYesLua expression resolving to the Instance that owns the signal (e.g. 'game.Workspace.Door'). Evaluated as `return <instancePath>`. Leave signalName empty if this expression already resolves to the signal itself.
threadContextNoOptional Roblox thread identity for this call; omit it to use the server default.
connectionIndexNoZero-based index of the target connection within getconnections(signal) when scope='one', matching the Index from list-signal-connections. Ignored when scope='all'. Defaults to 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-spies.2

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: distinguishes reversible disable/enable from irreversible disconnect, explains the confirm gate for scope='all' and action='disconnect', notes dependency on getconnections and graceful { error } degradation, and describes the return payload. This is materially more than destructiveHint/readOnlyHint 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-loads the critical 'MUTATES CLIENT STATE' warning and the irreversible-action caveat, and the prose is dense but readable. It loses a point for restating the full signature and appending metadata boilerplate (Phase/cost/capabilities/produces) that duplicates the schema.

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 destructive, 7-parameter tool with no output schema, the description covers reversibility, safety gating, prerequisites, failure mode, and the return shape. Nothing an agent needs to invoke it safely 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%, so the baseline is 3, but the description adds cross-parameter meaning: the interaction of scope='all' with confirm=true, and that connectionIndex matches the Index from list-signal-connections. That is real semantics beyond field-level text.

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 set (toggles/removes) on a specific resource (connections on an RBXScriptSignal), and defines each action's effect. It is clearly distinguishable from siblings like list-signal-connections or fire-connection.

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 concrete use context ('silencing or surgically removing event handlers while debugging') and spells out when each action/scope applies, plus the confirm=true precondition. It references list-signal-connections for indices, but does not name a true alternative tool for the same job.

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