Skip to main content
Glama
Godot MCP - Full Control
by cxb2523

game_physics_2d

Run Area2D overlap checks and 2D point, shape, or ray queries to detect collisions and identify nodes in Godot scenes.

Instructions

Area2D queries and 2D point/shape intersections

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": "game_physics_2d"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoEnd point {x,y} (for ray)
fromNoOrigin point {x,y}
sizeNoRectangle size {x,y} (shape_query rectangle)
actionYesAction: overlap, point_query, shape_query, ray
radiusNoCircle radius (shape_query circle)
nodePathNoArea2D/node path (for overlap)
positionNoQuery position {x,y} (point_query/shape_query)
shapeTypeNoShape: circle or rectangle (shape_query)
maxResultsNoMax results. Default: 32
collisionMaskNoCollision mask bitmask

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so description must disclose behavior. It mentions queries and intersections but does not specify side effects, permissions, or performance implications. The action 'overlap' could be read-only or have side effects, but this is unclear.

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?

Description is very short (5 words) and front-loaded. It is concise but may be too brief to be fully informative. Still, it wastes no words.

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?

Tool has 10 parameters and no output schema. Description does not explain return values, how actions differ, or complex behaviors. It is insufficient for an agent to use correctly without further inference.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond summarizing the action. It does not explain parameter relationships or constraints beyond what the schema already provides.

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?

Description clearly states the tool performs 'Area2D queries and 2D point/shape intersections'. It uses a specific verb ('queries', 'intersections') and identifies the resource ('Area2D', '2D point/shape'), distinguishing it from sibling tools like game_physics_3d or game_raycast.

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 on when to use this tool versus alternatives. The description does not provide context, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema alone.

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