Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Browse hierarchy

tree
Read-onlyIdempotent

List a Roblox Studio instance hierarchy under a path breadth-first to a set depth, returning flat paths to orient in unfamiliar places and inspect services.

Instructions

Lists the instance hierarchy under a path, breadth-first to a given depth. Returns a flat array of paths — flat is both cheaper and easier to act on than nested JSON, since every entry is directly usable as a path.

Use this to orient yourself in an unfamiliar place. Use find instead when you already know what you are looking for; a deep tree over a whole place wastes context on instances you will never touch.

With path omitted it lists only the containers a place is authored in — Workspace, ReplicatedStorage, ServerScriptService and friends. Roblox exposes ~120 services at the root, almost all engine internals; those are hidden and the response says how many. Pass an explicit path to look inside one of them anyway.

Input Schema

NameRequiredDescriptionDefault
pathNoDot-notation root, e.g. "Workspace.Map". Omit to list services from the root.
depthNoLevels below `path` to walk. Keep low; each level multiplies the result.
limitNoMaximum items to return (1-500).
cursorNoOpaque cursor from a previous call's `nextCursor`. Omit for the first page.
detailNoconcise: compact identity. standard: selected facts. full: all readable properties for inspect; tree/find use the same columns as standard.standard
playerNoclient only: player name; required with multiple players.
targetNoclient: read the actual player's playtest VM. Use the playtest server studioId.studio
handlesNoInclude bounded session handles usable in place of paths. Survive rename/reparent; refuse expired references.
studioIdNoTarget Studio; omit for the active one.
classNameNoOnly include instances of this class or a subclass, e.g. "BasePart".
nameContainsNoOnly include instances whose name contains this text (case-insensitive).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.9.1
    • addedInput schema / properties / handles
      Added value: +{
+  "default": false,
+  "description": "Include bounded session handles usable in place of paths. Survive rename/reparent; refuse expired references.",
+  "type": "boolean"
+}
    • addedInput schema / properties / player
      Added value: +{
+  "description": "client only: player name; required with multiple players.",
+  "type": "string"
+}
    • addedInput schema / properties / target
      Added value: +{
+  "default": "studio",
+  "description": "client: read the actual player's playtest VM. Use the playtest server studioId.",
+  "enum": [
+    "studio",
+    "client"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv0.8.6
    • changedInput schema / properties / detail / description
      Previous value: -"How much to return per item. 'concise' = name + class only, cheapest, use when scanning or counting. 'standard' = the properties that matter for most edits. 'full' = every readable property, expensive — use only after you have narrowed to a handful of instances."New value: +"concise: compact identity. standard: selected facts. full: all readable properties for inspect; tree/find use the same columns as standard."
  3. First observedv0.1.8

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description usefully adds the flat-array return shape and its rationale, plus the non-obvious scoping behavior when `path` is omitted (services hidden, count reported, explicit path to override). It does not cover pagination/cursor behavior or error cases, so it stops short of 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 core operation, then selection guidance, then the subtle default behavior. Every sentence earns its place, though the flat-vs-nested justification and the ~120-services aside add some prose weight.

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 complex 11-parameter read tool with no output schema, the description covers the primary output shape, the key default (path omitted), and tool-selection routing. Remaining parameters (detail, cursor, target, player, handles, studioId, className, nameContains) are documented in the schema, so the definition is largely complete; pagination semantics are the main omission.

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 baseline is 3, but the description adds meaning beyond the schema: it explains what omitting `path` actually yields (authoring containers, ~120 hidden engine-internal services, count in response) and warns that depth multiplies results. This is genuine added value over the field descriptions.

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 and resource ('lists the instance hierarchy under a path, breadth-first to a given depth') and explicitly names the sibling it is not ('Use `find` instead when you already know what you are looking for'). An agent can distinguish tree from find without opening either 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 ('orient yourself in an unfamiliar place'), when-not-to-use ('a deep tree over a whole place wastes context'), and names the alternative (`find`). Nothing about tool selection is left to inference.

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