Skip to main content
Glama

Physics

physics

Create and configure Godot bodies, collision shapes, layers, joints, raycasts, and project settings like gravity or tick rate.

Instructions

Physics bodies and collision: create a body/area with its collision shape (and optionally its sprite/mesh, auto-fitted) in one call, fit shapes to visuals, set collision layers/masks by name, add joints, raycast the edited scene, and change project physics settings (gravity, tick rate, engine).

Actions:

  • body: {type: static_2d|character_2d|rigid_2d|area_2d|animatable_2d|static_3d|character_3d|rigid_3d|area_3d|animatable_3d (or a class name), name?, parent?='.', position?, rotation? (degrees), shape?: {type: rect|circle|capsule|segment|world_boundary|convex|concave|polygon (2D) | box|sphere|capsule|cylinder|world_boundary|convex|concave|polygon (3D), size?, radius?, height?, points?, position?, rotation?, one_way?, disabled?} (default rect 32x32 / box 1m), shapes?: [several], sprite?: res://img.png (adds Sprite2D/Sprite3D) | mesh?: {type: 'BoxMesh', size: [1,1,1]} (adds MeshInstance3D) — the first shape is fitted to the visual (its opaque pixels) when it has no size/radius/points, layer?: [names|numbers], mask?: [names|numbers], script?, groups?, props?, visual_props?, children?: [node specs]} create a physics body + CollisionShape (+ visual) in one undoable step.

  • fit_shape: {path: body, its CollisionShape, or its Sprite2D/MeshInstance3D child, from?: visual node path (default: first Sprite2D/AnimatedSprite2D/MeshInstance3D/Sprite3D child), kind?: rect|circle|capsule|convex (2D, convex traces sprite alpha) | box|sphere|capsule|cylinder|convex|trimesh (3D), grow?: px/units (negative shrinks), trim?=true (2D: fit the opaque pixels of the current frame, not the padded frame rect)} size the collision shape to the visual (sprite frame incl. hframes/vframes/region/scale/flip; mesh AABB or hull). Creates the CollisionShape if missing.

  • layers: {path | paths, layer?: ['player'] | [2], mask?: ['world', 'enemies'] | [1, 3], mode?: set|add|remove} set collision_layer/mask using layer names from project settings (name them with project.set_layer_name) or layer numbers 1-32 (not bitmasks). Without layer/mask: shows current layers by name.

  • joint: {type: pin_2d|groove_2d|damped_spring_2d|pin_3d|hinge_3d|slider_3d|cone_3d|generic_6dof_3d, node_a, node_b, parent?=node_a's parent, name?, position? (parent space) | at?: mid|a|b (default mid), props?} connect two physics bodies. Groove/spring length defaults to the distance between the bodies.

  • raycast: {from: [x,y] | [x,y,z], to, mask?: names|numbers, areas?: bool, type?: 2d|3d} cast a ray in the edited scene (editor world, global coordinates): hit collider, position, normal. For the running game use game.raycast.

  • settings: {gravity?, gravity_direction?, linear_damp?, angular_damp?, engine_3d?: DEFAULT|GodotPhysics3D|Jolt Physics, gravity_2d?, gravity_direction_2d?, linear_damp_2d?, angular_damp_2d?, engine_2d?, ticks_per_second?, max_steps_per_frame?, jitter_fix?, interpolation?, settings?: {'physics/...': value}} read/change project physics settings (no args = read). 2D gravity is px/s² (default 980), 3D m/s² (9.8).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoJoint anchor: mid | a | b.
toNo
fromNo
growNofit_shape: grow (or shrink if negative) the fitted shape.
kindNofit_shape: shape kind.
maskNo
meshNo
modeNolayers: set | add | remove.
nameNoNode name.
pathNoNode path relative to the scene root ('.' = root, 'Player/Sprite2D', '%Unique'), or a res:// file path, depending on the action.
trimNofit_shape: fit opaque sprite pixels (default true) instead of the whole frame.
typeNoBody type (body) or joint type (joint).
areasNoraycast: also hit Areas.
layerNo
pathsNoSeveral node paths (layers).
propsNoProperty map. Values are coerced to the property type: numbers, [x,y], 'Vector2(1,2)', '#ff8800', 'res://file', {"type":"RectangleShape2D","size":[32,32]} for new resources, enum names as strings.
sceneNores:// scene to operate on; opened in the editor if needed. Defaults to the currently edited scene.
shapeNo
actionYesWhat to do. See the tool description for each action's parameters.
groupsNoGroups to add the body to.
node_aNoFirst body of the joint.
node_bNoSecond body of the joint.
parentNoParent node path.
scriptNores:// script to attach to the body.
shapesNoSeveral shape specs.
spriteNores:// texture: adds a Sprite2D (2D) / Sprite3D (3D) child.
gravityNo3D gravity m/s².
childrenNoExtra child node specs {type, name?, props?}.
positionNo[x, y] or [x, y, z].
rotationNo
settingsNoRaw physics settings {'physics/2d/default_gravity': 980}.
engine_2dNo2D physics engine.
engine_3dNo3D physics engine.
gravity_2dNo2D gravity px/s².
jitter_fixNoPhysics jitter fix.
linear_dampNo3D default linear damp.
angular_dampNo3D default angular damp.
visual_propsNoProperties for the created sprite/mesh node.
interpolationNoPhysics interpolation.
linear_damp_2dNo2D default linear damp.
angular_damp_2dNo2D default angular damp.
ticks_per_secondNoPhysics ticks per second (default 60).
gravity_directionNo3D gravity vector.
max_steps_per_frameNoMax physics steps per frame.
gravity_direction_2dNo2D gravity vector.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but the description adds rich behavioral context: creation is undoable, fit_shape creates a missing CollisionShape, settings without arguments performs a read, and raycast operates in the editor world with global coordinates. It also discloses defaults for shapes, gravity units, and tick rate, giving the agent operational confidence beyond 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.

Conciseness4/5

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

The description is necessarily long for a 45-parameter, six-action tool and is front-loaded with a summary followed by structured action bullets. It is dense and some action bullets are run-on, but each sentence carries specific calling information. It is appropriately sized for the complexity, though not maximally concise.

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 mutation-oriented tool with no output schema, the description covers inputs, defaults, alternatives, and editor-vs-runtime behavior thoroughly. It only briefly mentions return information for raycast and omits return details for other actions, which is a minor gap for an agent needing to chain calls. Overall, it is complete enough to invoke correctly.

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?

Although schema description coverage is already high at 84%, the description adds substantial action-specific meaning: body shape types, default rect/box sizes, fit_shape visual-fitting rules, layer name/number semantics, joint types and anchor defaults, and settings units/defaults. This goes well beyond the schema's brief per-parameter notes and directly guides correct parameter construction.

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 description opens with a clear verb-and-resource statement: physics bodies, collision shapes, joints, raycasts, and project physics settings. It enumerates each action with domain-specific terminology, making it easy to distinguish from siblings like node, scene, or project. An agent can identify the tool's scope without opening the schema.

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

Usage Guidelines4/5

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

The action list clearly implies when each sub-operation applies, and the raycast entry explicitly directs the agent to game.raycast for the running game. However, there is no broader guidance on when to use this tool versus node/scene for creating physics objects, and no explicit when-not conditions beyond the raycast distinction.

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