Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

Wire up Roblox's audio graph

audio
Destructive

Builds and inspects Roblox's sound signal graph, connecting players, emitters, effects, and wires to prevent silence and enable effects.

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" category="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. Changed1 schema field changedv0.8.6
    • changedInput schema / properties / asset / description
      Previous value: -"graph 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."New value: +"graph only: the audio id, e.g. \"rbxassetid://1234\". Find one with `assets op=\"search\" category=\"audio\"`. Leave it out to build the chain now and set the asset later."
  2. Addedv0.6.8

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructive/openWorld/non-idempotent, so the bar is lower, and the description adds real value on top: the silent-failure mode ('completely silent, with no error anywhere'), that pin-name validation happens before wiring, that 'inspect' surfaces Connected = false links the Explorer hides, and that 'graph' runs in one undoable step. It never states what mutation is destructive, which keeps it from a 5.

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 one-line summary and then the mental model, and every paragraph carries information (ops, failure mode, alternatives). It is somewhat long and ornate for a tool description, but the length is justified by 12 parameters and the subtle graph semantics.

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?

No output schema exists, and the description compensates by explaining what 'inspect' returns (every connection, including false ones). It covers the domain model, the three ops, and the parameter concepts well enough that an agent can call it correctly on a complex 12-parameter tool.

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 a 3 is the baseline. The description nonetheless adds conceptual meaning: it frames pin names, direction and sink choice as 'where it actually goes wrong', explains the world-vs-ui sink distinction, and justifies omitting 'path'/'asset'. That is more than repeating the schema.

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 specific verbs and resources for each op — 'graph builds a whole working chain', 'wire joins two existing instances', 'inspect reads a graph back' — and frames the tool as building/inspecting the modern audio API. It distinguishes itself from the sibling 'create' tool explicitly, so an agent can tell them apart 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 explicit when-to-use per op ('graph is the one to reach for', 'wire joins two instances you already have', 'inspect reads an existing graph back') and names the alternative: 'The old Sound instance still works... use create for that. Come here when the case needs effects, per-listener mixing, or one emitter fed by several sources.' When-not guidance is present.

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