This MCP server provides tools to introspect, extract, and modify GameMaker data files (.win, .ios, .droid, .unx) via UndertaleModCli, returning clean JSON output designed for LLM interaction.
Get an overview of a data file: project name, GameMaker version, YYC flag, and resource counts.
List entities by type (sprites, sounds, scripts, code, rooms, objects, fonts, etc.) with filtering, pagination, and ordering.
Retrieve detailed properties of any entity by name or index.
Decompile GML code from individual code entries or specific object events (create, step, collision, etc.) – VM games only, not YYC.
Export assets individually (sprites as PNG, sounds as OGG/WAV, code as GML, embedded textures as PNG) or in batch (all sprites, sounds, or textures).
Search entities by name using case-insensitive substring matching, optionally scoped to specific types.
Search the string table by content (since strings have no names) to find matching entries.
Get all assets used in a room – sprites, objects, code entries, and layer summary in one call.
Find references to sprites, objects, variables, functions, or strings across the project.
Identify unresolved functions not mapped to any known script, built-in, or extension.
Extract embedded data from YYC executables or memory dumps without external tools.
Analyze dead resources (unused strings, variables, functions) for cleanup.
Find and replace across all code entries (supports text/regex) and save to a new file – VM only.
Export the entire string table to JSON for localization and analysis.
Allows reading and exporting GameMaker data files, providing tools for browsing project info, listing and retrieving entities (sprites, sounds, scripts, rooms, etc.), decompiling GML code, exporting assets, searching, and analyzing room contents.
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., "@utmt-mcp list all gameobjects in data.win"
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.
通过 UndertaleModCli 读取和导出 GameMaker 数据文件（.win、.ios、.droid、.unx）的 MCP 服务器。
专为 LLM 工具调用而设计 —— 所有输出均为干净的 JSON，实体按名称查找。
跨平台 —— 支持 Windows、macOS、Linux。UndertaleModCli 为这三个平台都提供了官方构建。
npx utmt-mcp或全局安装：
npm install -g utmt-mcp
utmt-mcpRelated MCP server: GMS2 MCP Server
Node.js 18+
.NET 运行时（UndertaleModCli 需要）
UndertaleModCli —— 加入 PATH，或通过环境变量 / 工具参数指定
从 GitHub Releases 下载对应平台的构建包，解压后任选一种方式：
把可执行文件加入系统 PATH，或
将 UTMT_CLI_PATH 环境变量设置为可执行文件的完整路径
在 Windows 上 CLI 二进制文件带 Windows 可执行文件后缀；macOS 和 Linux 上没有后缀。其余用法完全一致。
变量 | 说明 |
| UndertaleModCli 可执行文件的完整路径 |
在 MCP 客户端中（如 Claude Desktop、Cursor、Claude Code 等）：
{
"mcpServers": {
"utmt": {
"command": "npx",
"args": ["-y", "utmt-mcp"],
"env": {
"UTMT_CLI_PATH": "/path/to/UndertaleModCli"
}
}
}
}或者在每次工具调用时显式传入 CLI 路径（无需环境变量）：
{
"mcpServers": {
"utmt": {
"command": "npx",
"args": ["-y", "utmt-mcp"]
}
}
}所有示例均为对真实数据文件的实际调用结果（长输出按需截断）。
utmt-info获取 GameMaker 数据文件的概览信息。返回 JSON，包含项目名称、GM 版本、isYYC 标志和各类资源数量。
参数：
dataFilePath（必填）— 数据文件路径
cliPath（可选）— UndertaleModCli 路径
输入：
{"dataFilePath": "data.win"}返回：
{"name":"VIVIDSTASIS","displayName":"vivid/stasis","gmVersion":"2024.14.1.0","isGMS2":true,"isYYC":false,"bytecodeVersion":17,"windowWidth":320,"windowHeight":180,"fps":60,"counts":{"sprites":2141,"sounds":664,"scripts":19375,"code":22033,"rooms":232,"gameObjects":814,"fonts":30,"backgrounds":5,"paths":0,"shaders":44,"strings":51932,"variables":16316,"functions":17835,"timelines":1,"embeddedTextures":100,"embeddedAudio":627,"texturePageItems":6782,"extensions":7,"sequences":0,"particleSystems":0}}utmt-list-entities列出指定类型的实体。返回 JSON 数组，包含索引、名称和简要属性。
参数：
dataFilePath（必填）
entityType（必填）— 可选值：sprites、sounds、scripts、code、rooms、gameobjects、fonts、backgrounds、paths、shaders、strings、timelines、embeddedtextures、embeddedaudio、extensions、sequences、particlesystems
filter（可选）— 不区分大小写的名称过滤
offset（可选）— 分页偏移（默认：0）
limit（可选）— 最大返回数，1-500（默认：50）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "entityType": "sprites", "limit": 3}返回：
[{"index":4,"name":"_filter_underwater_noise_sprite","width":256,"height":256,"frames":1,"origin":[0,0]},{"index":7,"name":"_filter_heathaze_noise_sprite","width":64,"height":64,"frames":1,"origin":[0,0]},{"index":987,"name":"sp_default_actor_sprite","width":16,"height":16,"frames":1,"origin":[0,0]}]utmt-get-entity获取单个实体的详细信息。返回 JSON，包含所有属性。
参数：
dataFilePath（必填）
entityType（必填）— 可选值：sprite、sound、script、code、room、gameobject、font、string、generalinfo
name（必填）— 实体名称（string 类型用数字索引；generalinfo 忽略此参数）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "entityType": "sprite", "name": "_filter_large_blur_noise"}返回：
{"name":"_filter_large_blur_noise","width":32,"height":32,"originX":0,"originY":0,"frames":1,"transparent":false,"smooth":false,"preload":false,"bboxMode":0,"sepMasks":0,"marginLeft":0,"marginRight":31,"marginTop":0,"marginBottom":31,"collisionMasks":0,"spriteType":0,"playbackSpeed":30}utmt-decompile-code将代码条目反编译回 GML 源码。YYC 编译的游戏不可用。
参数：
dataFilePath（必填）
codeName（必填）— 代码条目名称（如 gml_Script_myFunction）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "codeName": "gml_Script_io_gamemaker_gm_effect_glow_1_0_0__effect_glow_script"}返回（GML 源码，节选）：
function gml_Script_io_gamemaker_gm_effect_glow_1_0_0__effect_glow() constructor
{
static shader = _effect_glow_shader;
static u_GlowRadius = shader_get_uniform(shader, "g_GlowRadius");
...
}utmt-export-entity将单个实体导出到磁盘。
参数：
dataFilePath（必填）
entityType（必填）— 可选值：sprite、sound、code、embeddedtexture
name（必填）— 实体名称（embeddedtexture 用数字索引）
outputPath（必填）— 输出文件或目录路径
cliPath（可选）
导出格式：
sprite → 输出目录中的 PNG 帧
sound → .ogg 或 .wav 文件
code → 反编译后的 .gml 文件
embeddedtexture → PNG 文件
输入：
{"dataFilePath": "data.win", "entityType": "sprite", "name": "sp_default_actor_sprite", "outputPath": "C:/out"}返回：
{"success":true,"exportedFrames":1,"outputDir":"C:/out"}utmt-search跨所有类型按名称模式搜索实体。不区分大小写的子串匹配。
参数：
dataFilePath（必填）
query（必填）— 搜索关键字
entityTypes（可选）— 限定搜索类型（空 = 全部）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "query": "player", "entityTypes": ["gameobjects", "sprites"]}返回（节选）：
[{"type":"gameobject","index":6,"name":"o_00_movieplayer"},{"type":"gameobject","index":734,"name":"obj_player_actor"},{"type":"sprite","index":661,"name":"sp_2023res_playerwindow"},"..."]utmt-get-room-assets获取一个房间内使用的所有资源：精灵（含尺寸及使用它们的对象）、对象（含位置和精灵）、代码条目（来自事件）以及图层汇总。
参数：
dataFilePath（必填）
roomName（必填）— 房间名称（如 scene_gameplay）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "roomName": "betweenspace"}返回：
{"room":"betweenspace","width":320,"height":180,"sprites":[],"objects":[{"name":"o_chromatest","sprite":"","depth":0,"visible":true,"x":0,"y":0,"instanceId":100000}],"codeEntries":[{"obj":"o_chromatest","evt":"create","subtype":0,"code":"gml_Object_o_chromatest_Create_0"},{"obj":"o_chromatest","evt":"draw","subtype":0,"code":"gml_Object_o_chromatest_Draw_0"}],"layers":[{"name":"Instances","type":2,"depth":0,"visible":true,"objectCount":1},{"name":"Background","type":1,"depth":100,"visible":true,"objectCount":0}]}utmt-search-strings按内容搜索字符串表。字符串没有名字，常规 utmt-search（按名字）搜不到它们。返回匹配的字符串索引和内容（每条截断到 500 字符）。
参数：
dataFilePath（必填）
query（必填）— 不区分大小写的内容搜索关键字
limit（可选）— 最大返回数（默认：50）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "query": "CoroutineThen", "limit": 3}返回：
[{"index":287,"content":"THEN"},{"index":288,"content":"gml_Script___CoroutineThen"},{"index":289,"content":"__CoroutineThen"}]utmt-export-all批量导出某类型的全部资源到目录。支持：sprites、sounds、embeddedtextures。精灵导出为每个精灵一个 PNG 帧子目录，声音为 ogg/wav 文件，内嵌纹理为编号 PNG。返回导出/失败数量。
参数：
dataFilePath（必填）
entityType（必填）— 可选值：sprites、sounds、embeddedtextures
outputDir（必填）— 导出目标目录
cliPath（可选）
输入：
{"dataFilePath": "data.win", "entityType": "sounds", "outputDir": "C:/audio"}返回：
{"type":"sounds","exported":664,"failed":[]}utmt-get-object-code反编译对象上某个事件的 GML 代码。返回 JSON，包含对象名、事件类型、子类型和反编译代码。子类型是零基索引：alarm 是闹钟编号；step 0=begin/1=normal/2=end；collision 是另一对象索引；其余映射到事件专属按键。单条目事件用 0（如 create）。YYC 编译的游戏不可用。
参数：
dataFilePath（必填）
objectName（必填）— 对象名（如 o_player）
eventType（必填）— 可选值：create、destroy、alarm、step、collision、keyboard、mouse、other、draw、keypress、keyrelease、trigger、cleanup、gesture、precreate
subtype（可选）— 零基事件子类型索引（默认：0）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "objectName": "cc", "eventType": "create", "subtype": 0}返回（code 字段为反编译的 GML，节选）：
{"objectName":"cc","eventType":"create","subtype":0,"codeName":"gml_Object_cc_Create_0","code":"if (global.op_hide_cursor)\n{\n window_set_cursor(cr_none);\n}\nglobal.gamefps = @@array_get@@([30, 60, 75, 90, 120, 144, 165, 240, 500, 1000], global.op_fpscap);\n...\ninstance_create_depth(0, 0, -1000, obj_judgement_display);\n"}utmt-find-references查找某个资产的引用。sprite：哪些对象使用它作为精灵、哪些房间包含这些对象的实例；object：哪些房间实例化它、哪些对象继承它；variable/function：哪些代码条目引用了它（扫描字节码指令）；string：传入字符串索引，查找推入该字符串的代码条目。返回 JSON。
参数：
dataFilePath（必填）
type（必填）— sprite、object、variable、function、string
name（必填）— 资产名（string 类型传索引）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "type": "variable", "name": "x"}返回（节选）：
{"codeReferences":[{"code":"gml_GlobalScript_create_chapter2_event_nodes","references":52},{"code":"gml_GlobalScript_create_chapter2end_event_nodes","references":16},{"code":"gml_GlobalScript_create_chapter3_event_nodes","references":57},...]}utmt-find-unknown-functions列出未被任何脚本、代码条目、内置函数或扩展函数解析的函数条目（缺失脚本、外部 DLL 函数、YYC 隐藏函数）。反混淆和完整性审计用。
参数：
dataFilePath（必填）
cliPath（可选）
输入：
{"dataFilePath": "data.win"}返回：
[]utmt-extract-embedded-data从 YYC 编译的可执行文件或内存 dump 中提取内嵌的 GameMaker 数据文件。扫描输入二进制中的 FORM+GEN8 头，把恢复的数据文件（data.win）写入输出路径。纯字节扫描，无需 UndertaleModCli。
参数：
dataFilePath（必填）— YYC 可执行文件或 dump
outputPath（必填）— 输出数据文件路径
输入：
{"dataFilePath": "game.exe", "outputPath": "extracted.win"}返回：
{"success":true,"file":"extracted.win","offset":125952,"size":25165824,"candidates":1}utmt-dead-resource-analysis分析哪些字符串、变量、函数未被使用（没有被任何资产名或代码指令引用）。返回 JSON，含各分类总数和样本。内置变量/函数已排除。字符串检查还能发现未本地化的残留文本。
参数：
dataFilePath（必填）
limit（可选）— 每类样本上限（默认：50）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "limit": 3}返回（节选）：
{"unusedStrings":{"total":1552,"sample":[{"index":41466,"content":"@@SleepMargin"},{"index":41467,"content":"@@DrawColour"},{"index":41468,"content":"4294967295"}]},"unusedVariables":{"total":4844,"sample":[{"index":0,"name":"prototype"},{"index":1,"name":"@@array@@"},{"index":2,"name":"arguments"}]},"unusedFunctions":{"total":0,"sample":[]}}utmt-find-replace在全部代码条目中查找并替换文本（或正则），然后重新编译。写操作：结果保存到新的输出文件，原始文件绝不被修改。仅适用于 VM 编译的游戏（非 YYC）。
参数：
dataFilePath（必填）— 输入数据文件
outputFilePath（必填）— 输出文件（必须与输入不同）
find（必填）— 查找文本（或正则）
replace（必填）— 替换文本
caseSensitive（可选）— 区分大小写（默认：false）
isRegex（可选）— 按正则处理（默认：false）
cliPath（可选）
输入：
{"dataFilePath": "data.win", "outputFilePath": "data-mod.win", "find": "mod_scrollspeed", "replace": "mod_speed"}返回：
{"success":true,"searched":4842,"message":"Find/replace applied; changes are saved to the -o output file"}utmt-export-strings-json将字符串表全部导出为 JSON 文件。用于本地化、词频分析、文本资产审计。
参数：
dataFilePath（必填）
outputPath（必填）— 输出 JSON 路径
cliPath（可选）
输入：
{"dataFilePath": "data.win", "outputPath": "strings.json"}返回：
{"success":true,"file":"strings.json","count":51933}data.win — Windows
game.ios — iOS
game.droid — Android
game.unx — Linux/macOS
git clone <repo>
cd utmt-mcp
pnpm install
pnpm run buildnpm test单元测试零依赖（Node 内置 node --test），校验所有脚本生成器的 null 安全、转义和结构。集成测试会真实调用 UndertaleModCli：对一个生成的空白数据文件跑全部工具脚本（覆盖 GM 1.x 空集合路径）；如需对真实数据文件再跑一遍，设置 UTMT_TEST_DATA_WIN 环境变量指向 data.win（未设置则跳过真实文件用例）。集成测试需要 UTMT_CLI_PATH（或 PATH 中能找到 UndertaleModCli）；CLI 缺失时对应用例自动跳过。
MIT
Decompile a code entry from a GameMaker data file back to GML source. Returns the decompiled GML text. Not available for YYC-compiled games.
| Name | Required | Description | Default |
|---|---|---|---|
| cliPath | No | Path to UndertaleModCli executable | |
| codeName | Yes | Name of the code entry (e.g. gml_Script_myFunction) | |
| dataFilePath | Yes | Absolute path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns decompiled GML text and is unavailable for YYC-compiled games, which is useful. However, it omits behavioral details such as prerequisites (cliPath), potential failure modes, and whether the data file is modified (though 'decompile' implies read-only). This adds some value but not rich 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 two sentences: the first states the core action and output, the second adds a key limitation. Every word earns its place, and the most critical information is front-loaded.
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?
The description covers the return value and a major limitation, which is helpful given the absence of an output schema and annotations. However, it lacks guidance on when to select this tool over sibling tools and does not mention the optional cliPath context, making it only partially complete for an agent deciding how to invoke it.
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%, as all three parameters (cliPath, codeName, dataFilePath) have descriptions. The tool description itself does not add parameter-specific meaning beyond what the schema already provides, so the baseline score 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 uses a specific verb ('Decompile') and identifies the exact resource ('a code entry from a GameMaker data file') and output ('GML source'). This clearly distinguishes it from sibling tools like utmt-list-entities or utmt-get-entity, which serve different purposes.
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 provides no guidance on when to use this tool over alternatives. It does not mention 'use when you need GML code' or exclude other cases, and the YYC limitation is the only contextual hint. This leaves the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a single entity from a GameMaker data file to disk. Supported types: sprite, sound, code, embeddedtexture. Sprites export as PNG frames, sounds as ogg/wav, code as decompiled .gml, textures as PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Entity name (or index for embeddedtexture) | |
| cliPath | No | Path to UndertaleModCli executable | |
| entityType | Yes | Type of entity to export | |
| outputPath | Yes | Output file or directory path | |
| dataFilePath | Yes | Absolute path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses important behavioral output details (PNG frames for sprites, ogg/wav for sounds, decompiled .gml for code, PNG for textures). However, it does not mention side effects such as file overwriting, directory creation, or the need for cliPath, leaving some behaviors undisclosed.
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 three sentences, each contributing necessary information: first states the core action, second lists supported types, third specifies output formats. It is compact, front-loaded, and free of redundant wording.
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 the tool's moderate complexity, the description covers essential operational context: supported entity types and their export formats. Minor gaps exist, such as not explaining the role of cliPath or what happens at the output path, but these are documented in the schema, and the description is sufficient for an agent to understand the tool's function.
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 all five parameters are already documented in the input schema. The description adds no additional parameter-specific semantics beyond what the schema provides, such as the nuance that 'name' can be an index for embeddedtexture (which is already in the schema). Baseline 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 tool's verb ('Export') and resource ('a single entity from a GameMaker data file to disk'). It lists supported entity types and their output formats, distinguishing it from sibling tools like 'utmt-list-entities' or 'utmt-get-entity' by its explicit export-to-disk action.
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 the tool (whenever you need to export a single entity to disk) but does not explicitly compare it with alternatives or state when not to use it. Sibling tools like 'utmt-get-entity' or 'utmt-decompile-code' are not referenced, leaving the agent to infer differentiation from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for a single entity from a GameMaker data file. Returns JSON with all properties. Supported types: sprite, sound, script, code, room, gameobject, font, string, generalinfo. For 'string' type, use the index as the name parameter. For 'generalinfo', name parameter is ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Entity name (or index for string type) | |
| cliPath | No | Path to UndertaleModCli executable | |
| entityType | Yes | Type of entity | |
| dataFilePath | Yes | Absolute path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It appropriately states the return format (JSON), and highlights special behaviors for string and generalinfo types. It does not detail error handling or explicitly confirm read-only status, but the 'get' verb and JSON return imply a non-destructive operation, which is reasonably transparent.
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 compact and to the point: three sentences cover purpose, return format, and special cases without any fluff or redundant repetition of schema details.
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 retrieval tool with no output schema, the description sufficiently explains the return type and handles type-specific quirks. It could be improved by mentioning behavior when an entity is not found or if the CLI path is missing, but overall it provides the essential context needed to use the tool correctly.
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 already covers all parameters with descriptions (100% coverage), including the note about using index for string type. The description adds minimal extra nuance beyond the schema, such as that 'generalinfo' ignores the name parameter, but this is a small addition on top of the structured fields.
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 action (Get detailed info), the target (single entity), and the source (GameMaker data file), effectively distinguishing it from sibling tools like list-entities and export-entity. The supported types further clarify scope.
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?
Provides useful context for when to use this tool (single entity retrieval) and includes type-specific usage instructions for 'string' and 'generalinfo'. However, it does not explicitly mention alternatives or when not to use it, though the 'single entity' phrasing implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all assets used in a room: sprites (with dimensions and which objects use them), objects (with position and sprite), code entries (from events), and layer summary. One call replaces multiple round-trips.
| Name | Required | Description | Default |
|---|---|---|---|
| cliPath | No | Path to UndertaleModCli executable | |
| roomName | Yes | Room name (e.g. scene_gameplay) | |
| dataFilePath | Yes | Absolute path to the data file |
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 clearly describes the output content (sprites, objects, code, layers) but does not mention that this is a read-only operation, return format, potential error conditions, or performance implications. It adds some value beyond the schema but lacks rich behavioral context.
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 concise, with two sentences that front-load the purpose ('Get all assets used in a room') and enumerate key output categories. The second sentence adds practical value about efficiency ('One call replaces multiple round-trips') without redundancy. Every phrase earns its place.
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 compound tool returning multiple asset types, the description does a solid job of enumerating the contents and even includes details like dimensions and object associations. It does not describe the exact output structure (e.g., JSON fields), but the absence of an output schema makes this a minor gap. The tool's complexity is high, yet the description is reasonably complete for an agent to know what to expect.
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 describes all 3 parameters (cliPath, roomName, dataFilePath) with 100% coverage, so the baseline is 3. The description does not add any additional meaning about the parameters beyond what is already in the schema; it neither clarifies their usage nor provides examples, so no extra credit is warranted.
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 tool's purpose with a specific verb ('Get') and resource ('all assets used in a room'). It enumerates the returned asset categories (sprites, objects, code entries, layer summary), distinguishing it from sibling tools like utmt-get-entity or utmt-list-entities by focusing on a room-wide aggregation.
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 by stating 'One call replaces multiple round-trips,' which suggests using it when needing a comprehensive asset view without multiple requests. However, it does not explicitly mention when not to use it or name alternative tools for narrower queries, so it misses the 'explicit exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overview info for a GameMaker data file. Returns JSON with project name, GM version, isYYC flag, and resource counts for all entity types.
| Name | Required | Description | Default |
|---|---|---|---|
| cliPath | No | Path to UndertaleModCli executable | |
| dataFilePath | Yes | Absolute path to the data file |
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 clearly indicates this is a read-only info operation by stating it 'gets' and 'returns' JSON, and explicitly lists the returned fields. However, it does not mention potential error conditions or reliance on the UndertaleModCli executable, though these are inferable from the schema.
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 two sentences, front-loaded with the action verb, and contains no redundant words. It efficiently conveys the purpose and output format without any 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?
For a simple info retrieval tool with no output schema, the description provides sufficient detail about the return payload and the tool's scope. It does not enumerate every entity type or explain potential edge cases, but given the tool's simplicity and the presence of sibling tools for deeper operations, this level of completeness is adequate.
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 provides full descriptions for both parameters (cliPath and dataFilePath) with 100% coverage. The description adds no additional parameter semantics, so it meets the baseline for schema-heavy tools without adding extra value.
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 tool's function with a specific verb ('Get'), a defined resource ('GameMaker data file'), and a precise output ('JSON with project name, GM version, isYYC flag, and resource counts'). It distinguishes itself from sibling tools like utmt-list-entities and utmt-get-entity by focusing on an overview summary rather than listing or retrieving specific entities.
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 for getting a high-level overview of a data file but does not explicitly state when to prefer this tool over its siblings or mention prerequisites (e.g., valid CLI path). No exclusions or alternative guidance is provided, leaving the usage context mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entities of a given type from a GameMaker data file. Returns JSON array with index, name, and brief properties. Supported types: sprites, sounds, scripts, code, rooms, gameobjects, fonts, backgrounds, paths, shaders, strings, timelines, embeddedtextures, embeddedaudio, extensions, sequences, particlesystems.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entities to return (1-500) | |
| filter | No | Optional case-insensitive name filter | |
| offset | No | Number of entities to skip (for pagination) | |
| cliPath | No | Path to UndertaleModCli executable (default: auto-detect) | |
| entityType | Yes | Type of entity to list | |
| dataFilePath | Yes | Absolute path to the data file (data.win, game.ios, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return format ('JSON array with index, name, and brief properties') and supported types, but it omits behavioral details such as CLI dependency, read-only nature, error handling, or pagination limits (which are only in the schema).
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 compact and front-loaded with the core action and resource. The list of supported types is useful but not excessive; every sentence contributes value without redundant filler.
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 listing tool with fully documented parameters and no output schema, the description provides sufficient top-level behavior: what it lists, from what, and the general return shape. It does not explain filter/pagination behavior, but the schema already fully covers those parameters, so the description is adequately complete.
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%, and each parameter already has a clear description and defaults. The tool description adds little beyond restating the supported entity types, so it does not rise above the baseline expected when the schema is fully self-explanatory.
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') and resource ('entities of a given type from a GameMaker data file'), making the tool's purpose immediately clear. It also enumerates supported entity types, which distinguishes it from siblings like get-entity, export-entity, and search.
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 you need to list multiple entities, but it does not explicitly state when to prefer this tool over alternatives like get-entity or search. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for entities by name pattern across a GameMaker data file. Case-insensitive substring match. Returns JSON array with type, index, and name of matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (case-insensitive substring match) | |
| cliPath | No | Path to UndertaleModCli executable | |
| entityTypes | No | Limit search to specific types (empty = all). E.g. ['sprites','code','rooms'] | |
| dataFilePath | Yes | Absolute path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: case-insensitive substring matching and the return format (JSON array with type, index, name). Since no annotations are provided, this is the sole source of behavior. However, it does not mention edge cases like empty results or potential errors, so it is not fully transparent.
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 two sentences, front-loaded with the action, and contains no redundant information. It efficiently conveys the core functionality and output format.
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?
The description covers the essential aspects of the tool: what it searches, how it matches, and what it returns. Given that there is no output schema, the return format is explicitly stated. However, it does not mention the optional entityTypes filter or behavior on empty results, which are covered in the schema but not in the description. Overall, it is adequate but not exhaustive.
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 has 100% coverage for parameter descriptions, so the baseline is 3. The tool description does not add any parameter-specific semantics beyond what the schema already provides; it mentions case-insensitive matching which duplicates the query parameter description.
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 tool's function with a specific verb ('Search'), resource ('entities in a GameMaker data file'), and scope ('by name pattern'). However, it does not explicitly distinguish this tool from sibling tools like utmt-list-entities or utmt-get-entity.
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 provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios where a user should choose this over the sibling tools, such as when needing to filter by name rather than list all entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: info provides overview, list-entities enumerates by type, get-entity retrieves a single entity, search finds by name, decompile-code produces GML source, export-entity writes to disk, and get-room-assets aggregates room data. There is no meaningful overlap; even get-entity and decompile-code are clearly separated by metadata vs. source code.
All tools share the 'utmt-' prefix, and most follow a consistent verb-noun pattern (list-entities, get-entity, export-entity). The exceptions 'utmt-info' and 'utmt-search' are still concise and natural, and the overall convention is predictable and uniform.
With 7 tools, the server is well-scoped. Each tool covers a distinct operation needed for GameMaker data file analysis—from high-level info to detailed lookup, decompilation, export, and room-level asset aggregation—without redundancy.
The core workflow of listing, searching, inspecting, decompiling, and exporting is well covered. However, some entity types that can be listed (e.g., backgrounds, paths, shaders) cannot be retrieved in detail or exported, leaving minor gaps for those assets.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides asset auto generator
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for developer documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vivid-stasis-revival/utmt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
