Skip to main content
Glama
Sign In
Roblox Studio MCP

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Wire up Roblox's audio graph

audio
Destructive

Builds and inspects Roblox sound graphs, creating players, emitters, effects, and wires in one undoable step so otherwise silent setups work.

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.

speech generates voice lines from text as real audio assets (Studio beta: Text-to-Speech asset creation). Feed the returned asset to graph to play it.

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "audio"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNo'graph' builds a whole working chain, 'wire' joins two existing instances, 'inspect' reads a graph back, 'speech' turns text into voice-line audio assets.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.
linesNospeech only: voice lines to generate. Each becomes an audio asset on your account that plays instantly, with no play-time rate limit.
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. Changed3 schema fields changedv1.0.0
    • addedInput schema / properties / lines
      Added value: +{
+  "description": "speech only: voice lines to generate. Each becomes an audio asset on your account that plays instantly, with no play-time rate limit.",
+  "items": {
+    "properties": {
+      "pitch": {
+        "description": "Semitones, -12 to 12.",
+        "maximum": 12,
+        "minimum": -12,
+        "type": "number"
+      },
+      "speed": {
+        "description": "0.5 to 2.",
+        "maximum": 2,
+        "minimum": 0.5,
+        "type": "number"
+      },
+      "text": {
+        "description": "What is said. 300 characters at most.",
+        "maxLength": 300,
+        "minLength": 1,
+        "type": "string"
+      },
+      "voiceId": {
+        "description": "AudioTextToSpeech VoiceId. Defaults to \"1\".",
+        "type": "string"
+      }
+    },
+    "required": [
+      "text"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / properties / op / description
      Previous value: -"'graph' builds a whole working chain, 'wire' joins two existing instances, 'inspect' reads a graph back."New value: +"'graph' builds a whole working chain, 'wire' joins two existing instances, 'inspect' reads a graph back, 'speech' turns text into voice-line audio assets."
    • changedInput schema / properties / op / enum
      Previous value: -[
-  "graph",
-  "wire",
-  "inspect"
-]New value: +[
+  "graph",
+  "wire",
+  "inspect",
+  "speech"
+]
  2. 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."
  3. Addedv0.6.8

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructive/non-idempotent/openWorld, and the description adds real value on top: silent-failure semantics ("NOTHING is connected until a `Wire` joins two named pins... completely silent, with no error anywhere"), that `graph` is a single undoable step, that `inspect` surfaces Connected=false connections the Explorer hides, that wrong pin names are validated before wiring, and that TTS is a Studio beta feature. It does not spell out what existing instances in `parent` are affected or any permission prerequisites, which keeps it off 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?

Purpose is front-loaded in the first sentence, then concept, then per-op guidance — a sensible order. It runs long, and the sentence about a perfectly configured AudioPlayer being silent is rhetorical padding around a point already made, so it is efficient rather than tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, no-output-schema, destructive tool it covers the domain model, all four ops, the failure modes, and sibling routing (`assets`, `create`). Return shapes are only loosely implied (`inspect` "reports every connection", `speech` returns an asset you feed to `graph`), which is the main remaining gap given no output schema exists.

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; the description goes beyond by explaining why pins and sinks are the risky parameters ("the pin names, the direction and the choice of sink are where it actually goes wrong") and by cross-referencing `assets op="search" category="audio"` for the `asset` value. It duplicates some schema text (op, kind, effects) rather than adding meaning everywhere, so not a 5.

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 + resource ("Builds and inspects the modern audio API — AudioPlayer, emitters, effects and the Wires between them") and immediately distinguishes itself from the `create`/`Sound` path and from `assets` (used to find asset ids). The four ops are enumerated with one-line purposes, so an agent knows exactly what surface this tool covers.

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?

Explicit routing: `graph` is "the one to reach for", `wire` is for instances you already have, `inspect` is for tracking down silence, and it states when NOT to use it — "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." It even gives the omit-`path` heuristic for unknown-origin silence.

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