LÖVE2D MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_objectsA | Get objects from the current game scene. Omit 'id' to list every object (id, type, x, y for each). Pass 'id' to get full detail on just that one object instead. Replaces what used to be two separate tools (list_objects / get_object) since they were the same underlying query with or without a filter. |
| run_luaC | Execute arbitrary Lua code in the game context |
| get_screenshotA | Capture a screenshot of the currently running game window as a base64 PNG image |
| send_inputC | Simulate keyboard or mouse input in the game, letting the AI actually play (move, attack, click, etc). type must be one of: key_down, key_up, mouse_move, mouse_down, mouse_up. |
| watch_game_stateA | Subscribe to real-time game state updates. The game will push a notification every time something changes (position, health, animation state, etc), instead of you having to repeatedly call get_objects. Call unwatch_game_state to stop. |
| unwatch_game_stateB | Stop receiving real-time game state update notifications. |
| list_lua_filesA | List every .lua file in the game project. Real games are usually split across several files (main.lua plus modules), so check this before deciding what to edit and pass to reload_code — don't assume everything lives in main.lua. |
| reload_codeA | Hot-reload a Lua file from disk into the running game (default 'main.lua'). LÖVE does NOT pick up file edits on its own — without this tool, changes you write to disk have zero effect until the game is restarted. This clears the require() cache for every game module first (so edits to files required by main.lua are picked up too, not just main.lua itself), then re-runs the file and calls love.load() again — it behaves like restarting the level with the new code rather than a state-preserving patch. Module tables themselves are reloaded via in-place mutation (same table identity, new contents), so any other system that already did |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinctly different capability: input simulation, Lua execution, screenshots, live state subscription, file listing, code reload, and object inspection. The watch/unwatch pair is a natural complementary set rather than an overlap. No two tools could plausibly be confused for one another.
All eight tools follow a consistent verb_noun snake_case pattern (send_input, run_lua, get_screenshot, watch_game_state, unwatch_game_state, list_lua_files, reload_code, get_objects). The watch/unwatch pairing is symmetric and predictable.
Eight tools is well-scoped for a game-automation server, covering input, observation, code editing, and hot-reload without bloat. The note that list_objects/get_object were merged into a single get_objects shows active curation against redundancy.
The surface covers the full loop an agent needs: inspect the project, execute or reload code, simulate input, and observe results via screenshots, object queries, or live subscriptions. Minor gap: no tool to write/edit .lua files from the server, so file changes must be made externally before reload_code.