Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

Wire up Roblox's audio graph

audio
Destructive

Build, connect, and inspect Roblox sound graphs—players, emitters, effects, wires—to find and fix silent setups.

Instructions

Builds and inspects the modern audio API — AudioPlayer, emitters, effects and the Wires between them.

Roblox's modern audio is a signal graph, not one instance with a Play method. An AudioPlayer holds the asset, an AudioEmitter puts the sound in the world or an AudioDeviceOutput sends it to the player's speakers, effects sit in between, and NOTHING is connected until a Wire joins two named pins. A place can hold a perfectly configured AudioPlayer with the right asset and the right volume and be completely silent, with no error anywhere, because the wire was never made. That is what this tool is for: create can make each instance, but the pin names, the direction and the choice of sink are where it actually goes wrong.

graph is the one to reach for: it builds a whole working chain in one undoable step. kind="world" gives a sound that comes from a part; kind="ui" gives one with no position, for menus and music. Add effects to splice reverb, EQ or a fader into the chain.

wire joins two instances you already have. inspect reads an existing graph back and reports every connection — including the ones that report Connected = false, which the Explorer does not show and which are the usual reason for silence.

The old Sound instance still works and is still shorter for a plain one-off noise; use create for that. Come here when the case needs effects, per-listener mixing, or one emitter fed by several sources.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opNo'graph' builds a whole working chain, 'wire' joins two existing instances, 'inspect' reads a graph back.graph
toNowire only: the instance sound goes INTO.
fromNowire only: the instance sound comes OUT of.
kindNograph only: 'world' is a sound heard from a place — it needs a part to come from. 'ui' has no position: menu clicks, music. Defaults to 'world'.
nameNograph only: name for the AudioPlayer.
pathNoinspect only: where to look. Omit to walk the whole place, which is the right call when tracking down silence of unknown origin.
assetNograph only: the audio id, e.g. "rbxassetid://1234". Find one with `assets op="search" kind="audio"`. Leave it out to build the chain now and set the asset later.
toPinNowire only: the target's input pin. Defaults to "Input". A wrong pin name is accepted by the engine and produces silence, so the name is checked against the instance before the wire is made.
parentNograph only: where the graph goes. For kind="world" this is the part or attachment the sound comes from.
effectsNograph only: effect classes to splice between the player and the output, in order, e.g. ["AudioFader", "AudioReverb"]. Also accepts AudioEqualizer, AudioCompressor, AudioEcho, AudioDistortion, AudioPitchShifter, AudioChorus, AudioFlanger and AudioLimiter.
fromPinNowire only: the source's output pin. Defaults to "Output", which is right for everything but a channel splitter.
studioIdNoTarget Studio; omit for the active one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.8

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), it discloses a key non-obvious behavior: an otherwise valid graph is silent until wires connect named pins. It also explains that inspect surfaces Connected=false connections hidden in Explorer, and that graph is undoable. This adds real diagnostic value that annotations alone do not provide.

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?

The description is longer than most but earns its length given 12 parameters and a non-obvious domain. It is front-loaded with the core mental model before enumerating operations, and every paragraph contributes. A little narrative is arguably unnecessary, so it is not quite a 5.

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 complex tool with no output schema, it covers the main operations, common failure causes, edge cases (channel splitter pin, asset left out), and alternative tools. Nothing essential for selecting and invoking this tool is missing.

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?

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains the failure mode behind toPin/fromPin, enumerates accepted effect classes, clarifies what omitting asset/path does, and distinguishes world versus ui placement. This makes parameter selection significantly safer.

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?

The description names a specific domain (Roblox's modern audio graph) and a concrete set of operations (graph, wire, inspect) along with the instances involved. It explicitly contrasts with the old Sound instance and the sibling create tool, so an agent can distinguish this tool without opening the 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?

It gives explicit routing: use graph for a complete chain, wire for joining existing instances, inspect for reading back and debugging silence-through-missing connections. It also states when NOT to use it ('old Sound ... use create for that') and when to prefer it (effects, per-listener mixing, multiple sources into one emitter).

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