Allows creating and managing GameMaker projects, including adding scripts, objects, sprites, and listing resources, by manipulating YYP/YY files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GM-Maker MCP Server add a player object with a step event"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Build GameMaker projects with AI in Cursor
An MCP (Model Context Protocol) server that brings GameMaker Studio development directly into your AI-powered workflow. Create YYP projects, add scripts, objects, and sprites using natural language in Cursor IDE.
This server exposes GameMaker project manipulation as MCP tools, letting you:
Create new GameMaker YYP projects from scratch
Add GML scripts with your code
Create objects with event definitions
Import sprite animations from image sequences
List and manage project resources
Maintain proper YYP/YY file structure automatically
All through natural language conversations with AI in Cursor.
Related MCP server: Layer.ai MCP Server
This project is built on the excellent work by Butterscotch Shenanigans, the indie game studio behind Crashlands, Levelhead, and other amazing games. They've open-sourced their entire GameMaker tooling suite called Stitch.
Specifically, this MCP server uses:
@bscotch/yy - Robust parsing and writing of GameMaker YY/YYP files
Their extensive TypeScript type definitions for GameMaker resources
Their battle-tested approach to programmatic GameMaker project manipulation
Without their incredible open-source contributions to the GameMaker ecosystem, this project wouldn't be possible. Thank you, Butterscotch Shenanigans! 🧈
This MCP server was created while building Soulbound, a game project that needed better AI-assisted GameMaker development workflows in Cursor. The goal was simple: make Cursor understand GameMaker projects so it could help write GML code, create objects, and manage resources without breaking the YYP structure.
Instead of manually creating GameMaker resources and switching between the IDE and Cursor, this tool lets you stay in the AI-powered flow and have Cursor handle the tedious project setup work.
This MCP server bridges GameMaker Studio development with modern AI-assisted workflows:
Foundation: Built on Butterscotch's @bscotch/yy library, which provides safe, validated reading and writing of GameMaker's JSON-like YY/YYP file formats.
MCP Protocol: Implements the Model Context Protocol from Anthropic, which allows AI assistants to call structured tools via a standard interface.
Cursor Integration: Configured to run as a stdio-based MCP server that Cursor can launch and communicate with, exposing GameMaker operations as callable tools.
Type Safety: Written in TypeScript with full type definitions from the @bscotch packages, ensuring robust file generation.
Architecture: Each tool (create_project, add_script, etc.) follows a consistent pattern:
Validate parameters with Zod schemas
Load existing YYP or create new project structure
Generate proper YY resource files
Update YYP resource registry
Write everything back using Butterscotch's safe write methods
The result: You can now say "create a player object with a step event" in Cursor, and the AI will generate a proper GameMaker object with all the right YY file structure, registered in the YYP, ready to open in GameMaker Studio.
Born from real game development needs, this tool makes AI-assisted GameMaker development actually practical.
create_project - Scaffold a new .yyp project
add_script - Create a GML script and register it in the YYP
add_object - Create a .yy object with optional event stubs
add_sprite_from_images - Import frames from a directory and register a sprite
list_resources - Enumerate resources by type (scripts, objects, sprites)
Node.js 18+
npm or pnpm
Cursor IDE
Clone and install dependencies:
cd /Users/webb/Repos/mcp-yyp
npm installBuild the server:
npm run buildTest with MCP Inspector (optional but recommended):
npm run inspectThis opens the MCP Inspector to validate your tools before using them in Cursor.
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"gm-maker": {
"command": "node",
"args": ["/Users/webb/Repos/mcp-yyp/dist/index.js"],
"env": {}
}
}
}Add to .cursor/mcp.json in your workspace:
{
"mcpServers": {
"gm-maker": {
"command": "node",
"args": ["${workspaceFolder}/dist/index.js"]
}
}
}For development with hot-reload:
{
"mcpServers": {
"gm-maker": {
"command": "npx",
"args": ["tsx", "/Users/webb/Repos/mcp-yyp/src/index.ts"]
}
}
}After adding the configuration, restart Cursor to load the MCP server.
Once configured, you can use natural language in Cursor to interact with GameMaker projects:
"Create a new GameMaker project called MyGame at /Users/webb/Projects/MyGame"Or explicitly:
Call gm-maker.create_project with { "projectDir": "/Users/webb/Projects/MyGame", "name": "MyGame" }"Add a script called player_movement to my GameMaker project at /Users/webb/Projects/MyGame"Or with code:
Call gm-maker.add_script with {
"projectDir": "/Users/webb/Projects/MyGame",
"scriptName": "player_movement",
"code": "function move_player(spd) {\n x += spd;\n}"
}"Create an object called obj_player with a Create event in my project"Or explicitly:
Call gm-maker.add_object with {
"projectDir": "/Users/webb/Projects/MyGame",
"objectName": "obj_player",
"events": [{"eventType": 0, "eventNum": 0}]
}Common GameMaker event types:
0 = Create
1 = Destroy
2 = Alarm
3 = Step
4 = Collision
8 = Draw
"Import PNG frames from /Users/webb/Assets/portal as a sprite called spr_portal"Or explicitly:
Call gm-maker.add_sprite_from_images with {
"projectDir": "/Users/webb/Projects/MyGame",
"spriteName": "spr_portal",
"framesDir": "/Users/webb/Assets/portal"
}"Show me all scripts in my GameMaker project"Or explicitly:
Call gm-maker.list_resources with {
"projectDir": "/Users/webb/Projects/MyGame",
"kind": "scripts"
}npm run dev - Run in development mode with tsx
npm run build - Build for production
npm run start - Run built version
npm run inspect - Open MCP Inspector for testing
gm-maker/
├── src/
│ ├── index.ts # MCP server entrypoint
│ └── gm/
│ ├── types.ts # TypeScript types
│ ├── yyp.ts # YYP project operations
│ ├── scripts.ts # Script creation
│ ├── objects.ts # Object creation
│ └── sprites.ts # Sprite creation
├── dist/ # Built output
├── package.json
├── tsconfig.json
└── README.md@modelcontextprotocol/sdk - MCP protocol implementation
@bscotch/yy - Safe GameMaker YY/YYP file parsing and writing
zod - Runtime type validation
This server uses the stdio transport protocol to communicate with Cursor. Each tool:
Validates input parameters using Zod schemas
Loads the existing YYP file (or creates a new one)
Performs file system operations for the resource
Updates the YYP resource list
Writes the updated YYP back to disk
The @bscotch/yy library ensures all YY/YYP files maintain proper structure and don't get corrupted.
Current limitations:
Sprite metadata (width, height, bbox) uses defaults - manual adjustment may be needed
No support for rooms, sounds, or other advanced resources yet
Event GML files are created with stub comments
Potential enhancements:
Add update_script to modify existing script code
Add delete_resource for removing resources
Add create_room for room creation
Add build_project using GameMaker CLI/Igor
Integration with @bscotch/gml-parser for code refactoring
Butterscotch Stitch Monorepo - The foundation this project is built on
@bscotch/yy Package - GameMaker file parsing/writing
Model Context Protocol - The protocol specification
Cursor MCP Documentation - How to use MCP in Cursor
GameMaker Manual - Official GameMaker documentation
Butterscotch Shenanigans - The studio behind the tooling
Butterscotch Blog - Great articles on GameMaker workflows
This is an experimental project exploring AI-assisted GameMaker development. Contributions, ideas, and feedback are welcome!
Areas for improvement:
Additional resource types (rooms, sounds, shaders, etc.)
Better sprite metadata handling
GML code parsing and refactoring
Project build automation
Integration with GameMaker CLI/Igor
MIT License - See LICENSE file for details
Butterscotch Shenanigans for creating and open-sourcing Stitch
Anthropic for the Model Context Protocol
Cursor for pioneering AI-first IDE experiences
The GameMaker community for being awesome
Built with ☕ while developing Soulbound. Created for the GameMaker community. Made possible by Butterscotch Shenanigans' amazing open-source tools.
Create a GameMaker object .yy file with optional event stubs and register it in the project
| Name | Required | Description | Default |
|---|---|---|---|
| events | No | Array of event definitions to create | |
| objectName | Yes | Name of the object to create | |
| projectDir | Yes | Absolute path to the GameMaker project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole source. It discloses that the tool creates a .yy file and registers it in the project, which are meaningful side effects. However, it does not address overwrite behavior, project prerequisites, or error conditions, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the primary action and packs in the file type, optional events, and registration. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context. It covers the core action but omits prerequisites (e.g., project must exist) and return/error behavior. Still, the schema descriptions fill in parameter details, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds only minor context ('optional event stubs' aligns with the events parameter) and does not explain parameter syntax or relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), names the resource ('GameMaker object .yy file'), and notes additional scope ('optional event stubs', 'register it in the project'). This clearly distinguishes it from sibling tools like add_script or add_sprite_from_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided; it does not mention alternatives or exclusions. The intended use is implied by the action (creating an object), but the description lacks explicit direction on when to choose this tool over add_script or add_sprite_from_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GML script and register it in the YYP
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | GML code for the script | // TODO |
| projectDir | Yes | Absolute path to the GameMaker project directory | |
| scriptName | Yes | Name of the script to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'create and register' without explaining side effects, error behavior (e.g., if the script already exists), or whether registration modifies project files in a way that could be destructive or require specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core action without waste. The acronym 'YYP' is not expanded, which slightly hurts clarity for agents unfamiliar with GameMaker terminology, but overall it is appropriately terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter creation tool, the description names the core action and target resource. However, it omits key context such as expected project structure, prerequisites like an existing project, failure modes, and what registering in the YYP actually does—leaving the agent with only a high-level understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the description need not repeat them. However, it adds no extra meaning beyond the schema—like the relationship between scriptName and the YYP registration or how code defaults are applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'GML script', then adds 'register it in the YYP' to indicate the integration step. This distinguishes it from sibling tools like add_sprite_from_images or add_object, which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new script is needed but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or prerequisites are mentioned, so the agent gets only inferred context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import frames from a directory into a new sprite and register it in the project
| Name | Required | Description | Default |
|---|---|---|---|
| framesDir | Yes | Directory containing PNG frames | |
| projectDir | Yes | Absolute path to the GameMaker project directory | |
| spriteName | Yes | Name of the sprite to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Import frames... and register it' without disclosing side effects like whether an existing sprite is overwritten, what happens if the directory is missing, or any permissions needed. This is insufficient for a mutation tool with clear side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action verb 'Import' and contains no redundant words. It efficiently communicates the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 100% schema coverage, no annotations, and no output schema, the description provides a clear purpose but omits behavioral context such as project requirements, overwrite behavior, and error handling. It is not completely inadequate but has clear gaps in side-effect disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description (e.g., 'Directory containing PNG frames', 'Absolute path to the GameMaker project directory'). The tool description adds minimal additional semantic value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Import'), the resource ('sprite'), and the source ('frames from a directory'), and adds 'register it in the project' to convey full scope. It distinguishes itself from sibling tools like add_script and add_object by being specific to sprite creation from images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when importing a sprite from image frames) and the sibling tool names provide natural context for alternatives. However, it does not explicitly state 'use this instead of add_script or add_object' or mention any exclusions, so it stops short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GameMaker YYP project at the specified directory if it does not exist
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name for the YYP | |
| projectDir | Yes | Absolute path to the GameMaker project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does disclose the 'does not exist' condition, which is useful, but it fails to mention what happens when the directory already exists (e.g., error, no-op) or whether it creates intermediate directories. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is well-structured and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with two parameters and no output schema, the description is largely sufficient. The main gap is the ambiguous handling of an existing directory, but overall it provides adequate context for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (100% schema coverage), so the description adds no extra meaning beyond referencing the directory and name. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with a clear resource 'GameMaker YYP project' and a condition ('if it does not exist'). It clearly distinguishes from sibling tools like add_sprite_from_images, which operate on existing projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for creating new projects and the 'if it does not exist' condition gives some context, but it does not explicitly state when to use this tool over alternatives or what happens if the directory already exists. Sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List resource names by type from the YYP file
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Type of resources to list (optional) | |
| projectDir | Yes | Absolute path to the GameMaker project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the action (list names) and source (YYP file), but does not disclose behavior such as sorting, error handling, or whether it reads from disk each time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary verb and object. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two well-documented parameters and no output schema, the description is sufficiently complete. It conveys the core function and source, though it could optionally mention that the return will be a list of names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds context by mentioning 'by type' (matching the kind parameter) and 'from the YYP file' (matching projectDir), but does not add new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the resource ('resource names'), and the source ('from the YYP file'). It clearly differentiates from sibling tools which all create/add resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading/listing resources, while all sibling tools are for creation. However, it does not explicitly state when to use this versus alternatives or mention any limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_objectadd_scriptadd_sprite_from_imagescreate_projectlist_resourcesEach tool targets a distinct action and resource type: creating a project, listing resources, and adding sprites, scripts, or objects. There is no overlap between tools, and the purpose of each is immediately clear from its name and description.
All tool names follow a consistent verb_noun pattern (create, list, add), with lowercase snake_case throughout. The only deviation, 'add_sprite_from_images', still clearly uses the 'add_' verb and noun, maintaining a predictable structure.
With exactly 5 tools, the server is well-scoped for its purpose of creating and managing a GameMaker project. Each tool covers a core operation without unnecessary redundancy or bloat.
The server covers the primary lifecycle of creating a project and adding core resources (sprites, scripts, objects), along with listing everything. It lacks support for other GameMaker resource types (e.g., sounds, rooms) and does not offer update or delete operations, but these are minor gaps for a tool set focused on initial creation and discovery.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build, version, review, and export websites, web apps, and games from a conversation.
Generate game assets with AI: sprites, 3D models, animations, sound effects, music, and voices.
Generate game assets with AI for 2D games, including sprites, tilesets, and animations.
Generate AI images, video, speech, music and presentations from Claude, ChatGPT and Cursor.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/darkw3bb/GameMaker-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
