Skip to main content
Glama
putervision

world-model-mcp

by putervision
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

simulate_movement

Read-onlyIdempotent

Predict entity trajectories, test AABB obstacle collisions, and compute navigation waypoints in a spatial world model before executing movement.

Instructions

Predict entity trajectory, test for AABB obstacle collisions, or compute navigation waypoints (modes: simulate, navigate, waypoints). Read-only simulation. Returns {ok, is_valid, destination, collisions[], waypoints[]}. Use simulate_movement instead of record_outcome when testing hypothetical motion and collisions before executing an action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoOperation mode: "simulate" (default) for physics/collision, "navigate" or "waypoints" for path planning
projectNoOptional project identifier
velocityNoVelocity vector in units per second
entity_idNoEntity ID to simulate or move
delta_positionNoRelative movement displacement
start_positionNoStarting 3D coordinates for navigation mode
start_entity_idNoStarting entity ID for navigation mode
target_positionNoTarget position destination
check_collisionsNoWhether to test for AABB obstacle collisions (default: true)
duration_secondsNoMovement duration in seconds
target_entity_idNoTarget destination entity ID for navigation mode

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.4.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / delta_position / additionalProperties
      Removed value: -true
    • removedInput schema / properties / start_position / additionalProperties
      Removed value: -true
    • removedInput schema / properties / target_position / additionalProperties
      Removed value: -true
    • removedInput schema / properties / velocity / additionalProperties
      Removed value: -true
  2. First observedv0.3.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description is consistent ('Read-only simulation'). It adds value by disclosing the return shape {ok, is_valid, destination, collisions[], waypoints[]}, which is otherwise unavailable since there is no output schema. It stops short of noting side effects or failure behaviors.

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?

Three tight sentences, front-loaded with capabilities and ending with the sibling routing rule. The inline return-shape object is dense but earns its place given no output schema exists.

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 an 11-parameter, zero-required tool with modes and no output schema, the description supplies the mode semantics and return keys an agent needs. It does not explain which parameters pair with which mode, leaving that inference to the schema's own descriptions.

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 all 11 parameters are already documented, including mode-dependent fields. The description's mode list adds light routing help, but it largely restates the enum in the schema, so baseline 3 applies.

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 three specific capabilities (predict trajectory, test AABB collisions, compute navigation waypoints) with the exact mode names that trigger each, so an agent can map intent to mode without opening the schema. It also explicitly separates itself from record_outcome.

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?

Gives an explicit when-to-use rule and names the alternative: prefer this over record_outcome for hypothetical motion/collision testing before executing an action. This is the exact routing information an agent needs.

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