Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

Collision groups

collision
Destructive

Manage part collision groups to control what passes through what, and run ray, block, or sphere casts plus overlap checks to find real geometry.

Instructions

Controls which parts physically collide with which.

This is the right answer to 'these should pass through each other'. The alternative — turning CanCollide off — disables collision against everything, so a ghost that should pass through walls also falls through the floor.

The order is: create a group, assign parts to it, then set what it is collidable with. A group with nothing assigned does nothing.

Assigning a Model assigns every part inside it, which is almost always what is meant.

Groups are not undoable and not scoped to a session: remove when one was created to try something and is no longer wanted, rather than leaving it registered in the place indefinitely. The built-in "Default" group cannot be removed.

Groups belong to a world, not to the place. The Workspace is the default and is what nearly every question is about; a WorldModel inside a ViewportFrame keeps its own separate registry, so pass worldModel to reach that one. A group of the same name in each is two different groups.

THE SAME TOOL ANSWERS WHAT IS ACTUALLY THERE. cast fires a ray, block or sphere and reports the first thing it meets — the part, the hit point, the surface normal, the material and the distance. overlap lists everything inside a box, a radius, or overlapping an existing part.

That is the one question the Explorer cannot answer. A path tells you an instance exists and where its pivot sits; it does not tell you the door frame is clipping into the wall, that the spawn is buried a stud inside the floor, or that nothing stands between the turret and the player. Geometry wrong in exactly those ways looks perfect in inspect.

The queries live here because they ARE collision queries: they honour the very groups the other half of this tool manages. A cast run in the wrong collisionGroup reports a clear path through a wall the player cannot walk through — a wrong answer indistinguishable from a right one. A miss comes back as hit: false, which is a real answer and usually the one being checked for.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNooverlap only: the centre, for region "box" or "radius".
toNocast only: a point to aim at. Use this for sightlines — it saves working out a direction vector, which is where sign errors live.
fromNocast only: where the cast starts, e.g. "12, 0, 5".
onlyNocast/overlap: consider ONLY these instances and their descendants.
pathNooverlap region="part" only: the part to test against.
sizeNocast shape="block" or overlap region="box": the volume size. Defaults to "1, 1, 1" for a cast and "4, 4, 4" for an overlap.
withNocollidable only: the other group.
groupNoThe group's name. Required for everything but list.
limitNooverlap only: how many parts to list. Defaults to 50.
pathsNoassign only: parts or models to put in the group.
shapeNocast only: 'ray' is a line and the usual choice. 'block' and 'sphere' sweep a volume along the same path — use them when the thing moving has width, e.g. whether a character fits through a gap rather than whether a point does.
actionNoGroups: 'list' shows them and changes nothing, then 'create', 'assign', 'collidable', 'remove' (which unregisters a group entirely — not the same as un-assigning parts). Queries: 'cast' fires a shape and reports the first hit, 'overlap' lists what is inside a volume.list
ignoreNocast/overlap: skip these and their descendants. The usual case is the character doing the looking, which otherwise blocks its own cast at zero distance.
radiusNocast shape="sphere" or overlap region="radius": the radius. Defaults to 1 for a cast and 4 for an overlap.
regionNooverlap only: 'box' and 'radius' need `at`; 'part' takes `path` and reports what overlaps that part — the fastest way to find things clipping through each other. Defaults to 'box'.
distanceNocast only: how far along `direction`. Defaults to 100.
studioIdNoTarget Studio; omit for the active one.
directionNocast only: which way to go, e.g. "0, -1, 0" for down. Used with `distance`.
collidableNocollidable only: whether the two groups collide. False makes them pass through.
worldModelNoPath to a WorldModel whose own collision groups this call is about, e.g. "StarterGui.Preview.Viewport.WorldModel". Omit for the Workspace, which is what you want unless the parts in question live inside a ViewportFrame.
ignoreWaterNocast only: pass through terrain water instead of hitting it.
collisionGroupNocast/overlap: run the query as if from a part in this group. Required for a truthful answer in any place that uses groups.
respectCanCollideNocast/overlap: skip parts with CanCollide off. Off by default, matching the engine — leave it off to ask what is there, turn it on to ask what would stop a player.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.6
    • changedInput schema / properties / radius / description
      Previous value: -"cast shape=\"sphere\" or overlap region=\"radius\": the radius."New value: +"cast shape=\"sphere\" or overlap region=\"radius\": the radius. Defaults to 1 for a cast and 4 for an overlap."
    • changedInput schema / properties / size / description
      Previous value: -"cast shape=\"block\" or overlap region=\"box\": the volume size."New value: +"cast shape=\"block\" or overlap region=\"box\": the volume size. Defaults to \"1, 1, 1\" for a cast and \"4, 4, 4\" for an overlap."
  2. Changed18 schema fields changedv0.6.8
    • changedInput schema / properties / action / description
      Previous value: -"'list' shows existing groups and changes nothing. 'remove' unregisters a group entirely — not the same as un-assigning parts from it."New value: +"Groups: 'list' shows them and changes nothing, then 'create', 'assign', 'collidable', 'remove' (which unregisters a group entirely — not the same as un-assigning parts). Queries: 'cast' fires a shape and reports the first hit, 'overlap' lists what is inside a volume."
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "list",
      -  "create",
      -  "assign",
      -  "collidable",
      -  "remove"
      -]New value: +[
      +  "list",
      +  "create",
      +  "assign",
      +  "collidable",
      +  "remove",
      +  "cast",
      +  "overlap"
      +]
    • addedInput schema / properties / at
      Added value: +{
      +  "description": "overlap only: the centre, for region \"box\" or \"radius\".",
      +  "type": "string"
      +}
    • addedInput schema / properties / collisionGroup
      Added value: +{
      +  "description": "cast/overlap: run the query as if from a part in this group. Required for a truthful answer in any place that uses groups.",
      +  "type": "string"
      +}
    • addedInput schema / properties / direction
      Added value: +{
      +  "description": "cast only: which way to go, e.g. \"0, -1, 0\" for down. Used with `distance`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / distance
      Added value: +{
      +  "description": "cast only: how far along `direction`. Defaults to 100.",
      +  "type": "number"
      +}
    • addedInput schema / properties / from
      Added value: +{
      +  "description": "cast only: where the cast starts, e.g. \"12, 0, 5\".",
      +  "type": "string"
      +}
    • addedInput schema / properties / ignore
      Added value: +{
      +  "description": "cast/overlap: skip these and their descendants. The usual case is the character doing the looking, which otherwise blocks its own cast at zero distance.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / ignoreWater
      Added value: +{
      +  "description": "cast only: pass through terrain water instead of hitting it.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "overlap only: how many parts to list. Defaults to 50.",
      +  "maximum": 500,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / only
      Added value: +{
      +  "description": "cast/overlap: consider ONLY these instances and their descendants.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / path
      Added value: +{
      +  "description": "overlap region=\"part\" only: the part to test against.",
      +  "type": "string"
      +}
    • addedInput schema / properties / radius
      Added value: +{
      +  "description": "cast shape=\"sphere\" or overlap region=\"radius\": the radius.",
      +  "type": "number"
      +}
    • addedInput schema / properties / region
      Added value: +{
      +  "description": "overlap only: 'box' and 'radius' need `at`; 'part' takes `path` and reports what overlaps that part — the fastest way to find things clipping through each other. Defaults to 'box'.",
      +  "enum": [
      +    "box",
      +    "radius",
      +    "part"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / respectCanCollide
      Added value: +{
      +  "description": "cast/overlap: skip parts with CanCollide off. Off by default, matching the engine — leave it off to ask what is there, turn it on to ask what would stop a player.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / shape
      Added value: +{
      +  "description": "cast only: 'ray' is a line and the usual choice. 'block' and 'sphere' sweep a volume along the same path — use them when the thing moving has width, e.g. whether a character fits through a gap rather than whether a point does.",
      +  "enum": [
      +    "ray",
      +    "block",
      +    "sphere"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / size
      Added value: +{
      +  "description": "cast shape=\"block\" or overlap region=\"box\": the volume size.",
      +  "type": "string"
      +}
    • addedInput schema / properties / to
      Added value: +{
      +  "description": "cast only: a point to aim at. Use this for sightlines — it saves working out a direction vector, which is where sign errors live.",
      +  "type": "string"
      +}
  3. Changed1 schema field changedv0.6.5
    • addedInput schema / properties / worldModel
      Added value: +{
      +  "description": "Path to a WorldModel whose own collision groups this call is about, e.g. \"StarterGui.Preview.Viewport.WorldModel\". Omit for the Workspace, which is what you want unless the parts in question live inside a ViewportFrame.",
      +  "type": "string"
      +}
  4. First observedv0.1.8

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false but say nothing concrete; the description supplies the specifics an agent needs — groups are not undoable, not session-scoped, the built-in Default group cannot be removed, and a same-named group in a WorldModel is a different group. It also discloses that a wrong collisionGroup yields a plausible-but-wrong answer and that a miss returns hit:false.

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 purpose and organized into clear conceptual blocks, and every section is relevant. It is on the long side for a single description and includes persuasive flourishes ('Geometry wrong in exactly those ways looks perfect in inspect') that, while justifying the tool, could be trimmed.

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 23-parameter, seven-action tool with no output schema, the description covers the group lifecycle, the world-vs-place scoping, the query semantics and their failure modes. An agent has enough to select the right action and interpret a null/false result without further inference.

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 description coverage is 100%, so the baseline is 3. The description adds genuine conceptual meaning beyond the schema — the create/assign/collidable ordering, that assigning a Model assigns every part inside it, that an empty group does nothing, and that collisionGroup is 'required for a truthful answer.' It stops short of per-parameter detail, but the added semantics exceed the schema's field-level docs.

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+resource ('controls which parts physically collide with which') and explicitly covers the tool's two halves: group management (create/assign/collidable/remove) and collision queries (cast/overlap). An agent can distinguish it from siblings like inspect, tree, or geometry because the description names exactly what unique question it answers.

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?

Explicitly routes between alternatives: use groups rather than turning CanCollide off, which 'disables collision against everything.' It gives the ordering (create → assign → collidable), the when-to-remove rule, the worldModel-vs-Workspace condition, and the cast-vs-overlap choice. This is close to exhaustive when/when-not guidance.

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