world-model-mcp

Overview Schema Source Related Servers Discussions Admin

generate_game_inputs

Read-onlyIdempotent

Translate 3D navigation paths into Playwright WASD or click-to-move commands, or project and unproject 3D coordinates, for browser game automation.

Instructions

Translate 3D navigation paths into Playwright commands (WASD/click-to-move) or project/unproject 3D coordinates and screen pixels. Actions: generate_inputs, project_screen, unproject_ray. Read-only: generates Playwright inputs, does not press keys. Returns {ok, action, inputs[]|screen_coords|ray}. Use generate_game_inputs instead of simulate_movement when translating 3D trajectories into Playwright browser automation commands.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	No	Action to perform (default: generate_inputs)
`camera`	No	Camera state for projection / click-to-move
`project`	No	Optional project identifier
`screen_x`	No	Screen pixel X coordinate for screen_to_world unprojection
`screen_y`	No	Screen pixel Y coordinate for screen_to_world unprojection
`viewport`	No	Browser viewport dimensions
`direction`	No	Projection direction for projection mode
`entity_id`	No	Player or target entity ID
`waypoints`	No	Optional intermediate navigation waypoints
`output_format`	No	Output format (default: playwright_mcp)
`world_position`	No	3D world position for projection or starting point
`control_profile`	No	Game control key bindings and physical parameters
`target_position`	No	Destination 3D coordinates
`current_position`	No	Starting 3D coordinates (auto-resolved from entity_id if omitted)
`ground_elevation`	No	Ground plane elevation Y for raycast intercept (default: 0)
`target_entity_id`	No	Target destination entity ID
`current_orientation`	No	Starting orientation angles

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.1Oct 1, 2026
- addedInput schema / properties / action / enum
```
Added value: +[
+  "generate_inputs",
+  "project_screen",
+  "unproject_ray"
+]
```
Changed13 schema fields changedv0.4.1Sep 24, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / action / enum
```
Removed value: -[
-  "generate_inputs",
-  "project_screen",
-  "unproject_ray"
-]
```
- removedInput schema / properties / camera / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / camera / properties / orientation / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / camera / properties / position / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / control_profile / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / current_orientation / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / current_position / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / target_position / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / viewport / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / waypoints / items / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / world_position / additionalProperties
```
Removed value: -true
```
First observedv0.3.1Sep 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real context beyond them: it clarifies that 'read-only' here means the tool generates Playwright inputs and 'does not press keys', and it states the return shape ({ok, action, inputs[]|screen_coords|ray}). It omits rate limits, auth requirements, or failure modes, so it stops short of full disclosure.

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?

Four sentences, front-loaded with the core purpose and backed by the action list, return shape, and sibling routing. The 'Read-only: generates Playwright inputs, does not press keys' clause partially restates the readOnlyHint annotation, a minor redundancy, but overall there is little waste.

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 17-parameter, nested-object tool with no output schema, the description compensates by stating the return shape and the three action modes, which is what an agent needs to call it correctly. It is nearly complete, though the absence of guidance on which parameter groups pair with which action leaves some inference to the caller.

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 every parameter is already documented in the schema with defaults and enums. The description adds only indirect meaning (naming the action enum values and the WASD/click-to-move schemes); it does not explain how camera, viewport, or control_profile interact for a given action, so baseline 3 is appropriate.

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 gives a specific verb+resource ('Translate 3D navigation paths into Playwright commands'), enumerates the three concrete actions (generate_inputs, project_screen, unproject_ray), and explicitly routes the agent away from the sibling simulate_movement. 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?

It explicitly names the alternative (simulate_movement) and the condition that selects this tool instead ('when translating 3D trajectories into Playwright browser automation commands'), which is strong routing guidance. However, it offers no when-to-use discrimination among its own three actions (e.g. project_screen vs unproject_ray, or when click-to-move beats WASD), so guidance is clear but partial.

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

Deploy Server

generate_game_inputs

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools