Skip to main content
Glama

game

Interact with a running Godot instance: inspect and modify nodes, simulate input, wait for conditions, run deterministic playtests, monitor properties, and automate UI.

Instructions

游戏桥接操作。安装/卸载: game_bridge_install, game_bridge_uninstall。P2-1 overrides 注入: install_override/uninstall_override (启动游戏前注入任意调试脚本到项目 autoload,如日志钩子/状态快照)。查询: game_query (ping, get_tree, find_nodes, get_node_properties, get_performance, get_viewport_info, take_screenshot)。写入: game_write (set_node_property, call_method)。输入: game_input (send_key, send_mouse_click, send_mouse_move, send_text, send_touch, send_drag)。等待: game_wait (wait_for_node, wait_for_property)。P2-4 确定性 playtest: game_playtest (playtest.seed 锁随机, playtest.fixed_delta 锁步长, playtest.step 单步推进, playtest.snapshot/restore 状态快照)。监控: monitor_start/stop/poll (属性时间线采样)。信号: watch_start/stop/poll (信号事件记录)。UI: find_ui_elements/click_button (UI元素发现+按钮点击)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoclick_button: 按钮节点路径(和 text 二选一)
portNogame_bridge_install: 桥接监听端口(当前忽略,始终 9081)
pushNoP3-6 watch_start/monitor_start: 启用 push 模式(事件/采样产生时主动推送 MCP notification,无需 poll)。client 需订阅 resources/subscribe 才能收到
textNoclick_button: 按钮文字(和 path 二选一)
typeNofind_ui_elements: 按类型过滤(如 "Button"、"Label")
limitNofind_ui_elements: 最大返回数(默认 200,上限 500)
actionYes操作类型
methodNogame_query/game_write/game_input/game_wait/game_playtest 的具体方法。game_query: ping, get_tree, find_nodes, get_node_properties, get_node_layout, get_performance, get_viewport_info, take_screenshot。game_write: set_node_property, call_method。game_input: send_key, send_mouse_click, send_mouse_move, send_text, send_touch, send_drag。game_wait: wait_for_node, wait_for_property。game_playtest: playtest.seed (锁全局 RNG,仅覆盖 randi/randf), playtest.fixed_delta (锁 physics 步长,delta=1/hz), playtest.step (单步推进 N 帧,走 coroutine 延迟响应), playtest.snapshot (快照场景树属性,不保信号/物理/已free节点), playtest.restore (从快照恢复属性)
paramsNo方法参数。game_query: 因方法而异。game_write: set_node_property {path, property, value}, call_method {path, method, args}。game_input: send_key {key, pressed}, send_mouse_click {x, y, button, pressed}, send_mouse_move {x, y}, send_text {text}, send_touch {x, y, pressed, index}, send_drag {x, y, index, relative, speed}。game_wait: wait_for_node {path}, wait_for_property {path, property, value}。game_playtest: playtest.seed {seed:int}, playtest.fixed_delta {hz:int}, playtest.step {frames:int(1-60)}, playtest.snapshot/restore 无参数
patternNofind_ui_elements: 名称/文字匹配模式(Godot match 语法)
timeoutNogame_query/game_write/game_input/game_wait: 超时时间(毫秒,默认 10000)。game_wait 的 timeout 用作整个轮询窗口的总预算(在窗口内反复探测直到条件成立)
node_pathNomonitor_start: 要监控的节点路径(如 root/Player)
godot_pathNo覆盖 Godot 二进制路径(可选,优先于项目配置和环境变量)
max_eventsNowatch_start: 最大记录事件数(默认 1000,最大 5000)
propertiesNomonitor_start: 要监控的属性名列表(如 ["position", "health"])
interval_msNogame_wait 专用:轮询探测间隔(毫秒,默认 200,范围 50-2000)。仅 wait_for_node/wait_for_property 生效
signal_nameNowatch_start: 要监听的信号名(如 "pressed"、"health_changed")
project_pathNoGodot 项目目录路径(可选,默认使用 GODOT_PROJECT_PATH 环境变量或当前目录)
visible_onlyNofind_ui_elements: 仅返回可见元素(默认 true)
interval_framesNomonitor_start: 采样间隔帧数(默认 10,最小 1,最大 300)
source_script_pathNoinstall_override/uninstall_override: 源调试脚本绝对路径(必须在 ALLOWED_PROJECT_PATHS 白名单内,拷贝到项目根注册为 autoload/MCPOVERRIDE_<basename>)
Behavior3/5

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

With all annotations set to false (readOnlyHint, idempotentHint, destructiveHint), the description carries the burden of behavioral disclosure. It adds useful details such as install_override copying scripts to the project and registering as autoload, and playtest.snapshot not preserving signals/physics/freed nodes. However, it lacks explicit warnings about side effects, reversibility, or permission requirements for mutation actions.

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 dense single paragraph that conveys a large amount of information. It is organized by action category with colons, but the run-on structure makes it hard to scan. Given the complexity of the tool, the length is justified, but it could be better formatted with bullets or clear separators.

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?

There is no output schema, so the description should explain return values and error conditions for each action. It provides a broad overview but does not mention what each action returns (e.g., screenshot binary, tree data), or potential errors like missing nodes or timeouts. This is a significant gap for such a complex multi-action tool.

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 the baseline is 3. The description groups actions and repeats some parameter semantics (e.g., game_wait timeout budget) that are already in the schema. It adds a high-level understanding but does not significantly enhance parameter meaning beyond what the schema already provides.

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

Purpose4/5

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

The description clearly states that this tool performs '游戏桥接操作' (game bridge operations) and lists all major action categories with specific sub-operations. It distinguishes itself from sibling tools by focusing on the game bridge, but it is a multi-action dispatcher rather than a single verb+resource, so it doesn't quite reach 5.

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?

The description gives some context for each action category (e.g., P2-4 playtest, overrides), but it does not explicitly explain when to use this tool versus overlapping sibling tools like screenshot, ui, signal, etc. There is no comparison or exclusion guidance, making it hard for an agent to choose between this and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wgt19861219/godot-mcp-enhanced'

If you have feedback or need assistance with the MCP directory API, please join our Discord server