Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

Generate 3D models

generate
Destructive

Create 3D models in Roblox Studio from a text prompt, choosing a part schema for single meshes, vehicles, or custom groups.

Instructions

Makes 3D geometry from a text prompt, using Roblox's Cube model.

THE SCHEMA IS THE IMPORTANT ARGUMENT. It decides how the result is broken up, and it cannot be changed afterwards without another generation:

  • Body1 — one MeshPart. Right for props: a crate, a tree, a lamp.

  • Car5 — a body and four wheels, under the fixed names body, front left wheel, front right wheel, rear left wheel, rear right wheel. Right for anything that has to drive, because a script can find the wheels by name.

  • groups — your own list of part names, for a structure the two predefined schemas do not cover.

Asking for a car under Body1 gives you a car-shaped rock. It looks right and nothing can be articulated. If you only realise afterwards, geometry op="segment" cuts an existing mesh into named parts without generating it again.

Expect tens of seconds per call. The service is metered and moderated: a rejected prompt and a rate limit both come back as a failure that says which, so read the hint before retrying.

imageAssetId conditions the generation on a picture — supply it with a prompt or instead of one. size suggests proportions and maxTriangles caps the poly count (low values give a faceted, low-poly look). Results are anchored on arrival, because a multi-part model dropped into the workspace unanchored falls apart.

EDIT MODE ONLY, for now. A generated mesh does not survive into a playtest: inside one, its MeshContent and TextureContent read as empty. assets op="bake" does not fix this — the engine refuses to bake the kind of content generation produces. So generate for building and greyboxing, and do not rely on a generated mesh being visible in a test or after a reopen until it has been published as a real asset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName for the model.
sizeNoSuggested size as "x, y, z". Approximate — use `scaleTo` for exact.
anchorNoAnchor every part. Turn off only if physics should act on it.
groupsNoCustom part names to split into, e.g. ["body", "lid"]. Overrides `schema`.
parentNoWhere to put it. Defaults to Workspace.
promptNoWhat to generate, e.g. "a weathered stone well".
schemaNoHow to split the result. Ignored when `groups` is given.Body1
scaleToNoScale the result so its longest side is this many studs.
positionNoWhere to place it, e.g. "0, 10, 0".
studioIdNoTarget Studio; omit for the active one.
texturesNoGenerate textures. Off gives bare geometry.
imageAssetIdNoAn image asset id to condition the generation on.
maxTrianglesNoCap the triangle count. Lower is more faceted. Default is about 10000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.5

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses latency ('tens of seconds per call'), metering/moderating failures, anchoring on arrival, edit-mode-only persistence, and the emptiness of MeshContent/TextureContent in playtests. None of this contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is long but every sentence carries operational value, and the structure uses a clear opening, bullets, and bolded warnings. It front-loads the most important argument (schema) and organizes limitations so an agent can use it without rereading.

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 13-parameter generative tool with no output schema, the description covers purpose, schema selection, failure modes, retry behavior, anchoring, edit-mode limitations, and related tools. No critical operational gap remains.

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 description coverage is 100%, but the description adds substantial meaning: it explains `Body1` vs `Car5`, fixed wheel names, `groups` as an override, `imageAssetId` conditioning, and the faceted effect of low `maxTriangles`. This goes well beyond the schema's 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?

The opening line, 'Makes 3D geometry from a text prompt,' states a specific verb and resource, and the rest of the description elaborates on the kinds of geometry and schemas. It is clearly distinct from siblings like `geometry` or `assets`, which are operation/modification tools.

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?

The description gives explicit when-to-use guidance for each schema ('Right for props', 'Right for anything that has to drive'), tells the agent to 'generate for building and greyboxing', and names alternatives such as `geometry op="segment"` for post-hoc cutting and `assets op="bake"` as a non-fix. It also conditions expectations around rate limits and retries.

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