RoBridge

Overview Schema Source Related Servers Discussions Admin

manage_physics

Manage Roblox physics: anchor or unanchor objects, set collisions, weld parts, adjust mass and physical properties, create constraints, and manage collision groups.

Instructions

Physics helpers. Actions: anchor / unanchor, set_collide, weld, get_mass, set_physical_properties, create_constraint, register_group, set_collidable, get_groups (PhysicsService collision groups).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "manage_physics"
  }
}

Input Schema

Name	Required	Description
`path`	No
`group`	No	Collision group name
`action`	Yes
`groupA`	No
`groupB`	No
`density`	No
`friction`	No
`otherPath`	No
`canCollide`	No
`collidable`	No
`elasticity`	No
`properties`	No
`constraintType`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.8Aug 17, 2026

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It lists action verbs but doesn't explain side effects (e.g., whether 'weld' permanently connects parts, whether 'anchor' affects physics simulation), reversibility, required permissions, or what gets destroyed or changed. The parenthetical about collision groups provides a tiny bit of context, but overall it's minimal.

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

Conciseness3/5

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

The description is a single sentence listing actions, which is concise but under-structured. It front-loads 'Physics helpers' but then becomes a dense list. It's not overly verbose, but the lack of grouping or explanation makes it less effective than a brief structured overview.

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

Completeness2/5

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

Given the tool's complexity (10 actions, 13 parameters, no output schema, no annotations), this description is severely incomplete. It provides no per-action behavior, expected return values, prerequisite conditions, or examples. The description is essentially a menu of action names without the context needed to select among them confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 8% (only 'group' has a description), so the description must compensate. It doesn't map actions to their relevant parameters. For example, 'create_constraint' likely requires 'constraintType' and 'otherPath', but this isn't stated. The list of actions adds no semantic detail beyond their names, leaving the agent to guess which of the 13 parameters apply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'Physics helpers' and lists actions like 'anchor / unanchor, set_collide, weld', which conveys it's a physics manipulation tool. However, it lacks a clear statement of the tool's overall purpose or how it differs from sibling tools like manage_properties or execute_luau. The list of actions gives some clarity but is more of an enumeration than a coherent purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention scenarios that favor manage_physics over manage_properties, execute_luau, or other siblings. The parenthetical about PhysicsService collision groups is the only contextual hint, and it applies only to a subset of actions.

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