Universal Game Modder
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| UGM_CONFIG | No | Path to a config file that the server reads and merges over built-in defaults. If set, the file named by this environment variable is used first (ahead of ugm.config.local.json and ugm.config.json). |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| detect_engineB | Scan a game directory and detect what engine it uses (Unity, Unreal, Godot, Java, etc.). Returns engine type, runtime, and primary assembly path. |
| load_gameA | Set a game as the active modding target. Auto-detects engine, sets up session state, and returns what tools are available for this game type. |
| game_statusA | Get the current session state including loaded game, engine type, cached analysis data, and mod build status. |
| find_steam_gamesB | Search configured Steam library paths for installed games. Optionally filter by name. |
| mod_this_gameA | End-to-end game modding assistant. Detects engine, analyzes game structure, and returns a modding plan with available tools and next steps. Start here when modding a new game. |
| find_gameplay_valuesC | Search for gameplay-related values (health, damage, speed, money, etc.) across the game code. Works with any engine by using the appropriate search tools. |
| build_and_deployC | Compile a mod project and deploy the output to the game mods directory. |
| debug_modC | Analyze mod logs to diagnose errors and suggest fixes. |
| scaffold_modC | Generate a mod project skeleton from templates. Creates project files, plugin class, and build configuration. |
| list_available_toolsA | List all tools available for the currently loaded game engine, grouped by category. |
| analyze_pe_fullB | Full PE (Portable Executable) analysis. Shows headers, sections, data directories, and whether it is managed (.NET) or native. |
| analyze_file_formatB | Detect file format from magic bytes. Works with PE, ELF, Mach-O, ZIP, Java class, and other formats. |
| hex_readC | Read raw bytes from a file at a specific offset. |
| hex_writeC | Write raw bytes to a file at a specific offset. |
| hex_searchC | Search for a hex pattern in a binary file. |
| hex_replaceC | Replace bytes at a specific offset or replace a pattern throughout the file. |
| pattern_scanB | IDA-style pattern scan with wildcards. Searches for byte patterns in PE sections. |
| pattern_scan_allB | Scan entire file for a pattern (not limited to a section). |
| extract_strings_advancedC | Extract ASCII and UTF-16 strings from a binary file with filtering. |
| extract_dll_classesA | Extract class names from a .NET DLL using stream-based analysis. Works with very large files. |
| search_binary_patternC | Search for text patterns in a binary file using stream-based approach. |
| extract_stringsC | Simple string extraction from a binary file. |
| analyze_dll_structureB | Analyze the overall structure of a DLL: sections, imports, exports summary. |
| calculate_checksumsC | Calculate MD5, SHA1, SHA256 checksums for a file. |
| compare_binaries_detailedC | Compare two binary files and show differences. |
| rva_to_offsetB | Convert a Relative Virtual Address (RVA) to a file offset in a PE file. |
| offset_to_rvaB | Convert a file offset to a Relative Virtual Address (RVA) in a PE file. |
| analyze_godot_pckC | Analyze a Godot .pck archive and list its contents. |
| gorebox_generate_discovery_modB | Generate a GoreBox Lua mod that discovers all available API functions, globals, tables, and callbacks. Writes results to a dump file in the mod folder. Use this when you need to learn what Lua API is available in a game that uses Lua scripting. |
| gorebox_read_api_dumpA | Read and parse an API discovery dump file generated by gorebox_generate_discovery_mod. Returns structured information about all discovered globals, functions, tables, and callbacks. |
| gorebox_generate_modC | Generate a GoreBox-compatible Lua mod with proper info.json and main.lua. Creates a ready-to-use mod in the Mods directory. |
| gorebox_list_modsB | List all installed GoreBox mods with their info.json contents and file structure. |
| unpack_gameA | CATALOG-FIRST universal unpacker. Recursively walks an ENTIRE game install, classifies and sha256-hashes EVERY file, and persists the catalog into a SQLite .autopsy.db (game/binary/asset/data_store tables, provenance on every row). Read-only: never writes game files. Containers (.pak/.pck/.bundle/...) are catalogued as single rows, never expanded (per-format extraction is a later slice). Idempotent: re-running on the same game re-opens the DB and upserts, no duplicate rows. |
| decode_assetsA | Universal Asset Decoder. Reads a PR-1 autopsy catalog, cracks open Unity .assets containers, and decodes their members back into The Model (decoded=1, decoded_path set): Texture2D -> PNG (streamed pixels from sibling .resS), Mesh -> glTF .glb + .obj (plain/uncompressed; compressed noted+deferred), and AudioClip -> WAV (PCM) / OGG (bare Vorbis); FSB5-wrapped Vorbis + other codecs are noted+deferred. Read-only on game files; decoded files + DB rows are the only writes. Pass either db_path (the .autopsy.db) or game_path (whose default .autopsy/ DB is used). Optional out_dir overrides where decoded files land; asset_kinds restricts to textures, meshes, or audio. |
| disassemble_rangeA | Disassemble an arbitrary byte range of a native PE (x86-64) starting at an RVA. Resolves the RVA to its section and file offset, reads ONLY that slice (read-only on the binary), and decodes it with Capstone. Returns the instruction listing. If db_path or game_path is given AND the binary is catalogued in that autopsy DB, the decoded instructions are also summarized into The Model as a 'function' row spanning the range (provenance=verified for the bytes). Pure read-only when no DB is supplied. |
| disassemble_functionA | Disassemble a function starting at an RVA in a native PE (x86-64). Linear sweep from the entry RVA to the first terminal instruction (ret/iret) or max_bytes, whichever comes first — a PR-3.1 boundary heuristic (CFG-accurate bounds arrive with the call-graph in PR-3.2), so the function EXTENT is tagged provenance=inferred while the decoded bytes themselves are verified. Read-only on the binary. Writes a 'function' row into The Model when db_path/game_path is supplied and the binary is catalogued. |
| load_assemblyA | Load a .NET assembly (DLL) for analysis. Must be called before other Unity tools. |
| list_typesC | List all types (classes, structs, enums, interfaces) in a loaded assembly. |
| decompile_typeC | Decompile a type to full C# source code. |
| decompile_methodB | Decompile a single method to C# source code. |
| inspect_typeA | Inspect type structure (fields, properties, methods) without decompiling method bodies. |
| search_codeC | Search across assembly for types, methods, fields, or string literals. |
| find_referencesC | Find all references to a method or field. |
| get_inheritance_treeB | Get full inheritance tree for a type (ancestors and descendants). |
| list_monobehavioursC | List all MonoBehaviour components in assembly. |
| list_scriptableobjectsC | List all ScriptableObject types in assembly. |
| get_serialized_fieldsC | Get all serialized fields for a MonoBehaviour or ScriptableObject. |
| get_method_ilC | Get raw IL bytecode for a method. |
| generate_pluginC | Generate complete BepInEx 5 plugin template with Harmony patching. |
| generate_harmony_patchC | Generate correct Harmony patch class for a specific method. |
| validate_patch_targetB | Validate that a Harmony patch target method exists with expected signature. |
| list_patchable_methodsC | List all methods in a type that can be Harmony patched. |
| compile_pluginC | Compile a BepInEx plugin C# source file using Roslyn. |
| analyze_bepinex_logC | Analyze BepInEx log for errors, warnings, and patch issues. |
| validate_assemblyC | Validate compiled plugin DLL for missing references and conflicts. |
| compare_signaturesC | Compare expected Harmony patch signature with actual target method. |
| read_unity_assets_infoC | List Unity asset files in game data directory. |
| read_playerprefsC | Read Unity PlayerPrefs from Windows registry. |
| analyze_save_formatC | Analyze game save system by examining SaveManager classes. |
| detect_networkingC | Detect networking frameworks and flag unsafe-to-patch methods. |
| diff_assembliesC | Compare two assembly versions to show changes. |
| find_renamed_typesB | Find types likely renamed after a game update. |
| verify_patchesC | Verify Harmony patch targets in plugin still exist in game assembly. |
| open_gameB | Open a game directory for Unreal asset reading. Scans for .pak/.ucas/.utoc files. |
| list_assetsB | List assets in loaded game with file sizes. |
| search_assetsC | Search for assets by name (case-insensitive). |
| unreal_game_statusC | Check current state of Unreal asset reader. |
| read_assetC | Read all exports and properties from an asset. |
| read_asset_exportC | Read a specific named export from an asset. |
| read_blueprintC | Read Blueprint class definition, components, and default properties. |
| read_datatableB | Read a DataTable asset with all rows and field values. |
| list_exportsB | List all exports in a package without reading full properties. |
| get_class_hierarchyC | Get inheritance chain for a Blueprint class. |
| find_blueprints_of_typeB | Search for all Blueprint assets inheriting from a parent class. |
| jar_openC | Open and extract a JAR file for exploration and editing. |
| jar_closeA | Close a JAR session and clean up temp files. |
| jar_list_sessionsB | List all active JAR sessions. |
| jar_listC | List contents of an opened JAR file. |
| jar_searchC | Search within JAR for classes, methods, or strings. |
| jar_search_bytecodeC | Search for numeric values or strings in bytecode. |
| jar_search_opcodesC | Search for bytecode opcode patterns in .class files. |
| jar_read_classC | Read and decompile a Java .class file. |
| jar_read_fileC | Read a text file from the JAR. |
| jar_inspect_constant_poolC | Dump the constant pool of a .class file. |
| jar_hex_viewB | Read raw bytes from a .class file as hex dump. |
| jar_detect_mod_infoC | Auto-detect mod loader, version, and structure from JAR contents. |
| jar_edit_fileC | Edit a text file within the JAR. |
| jar_edit_class_constantsC | Edit numeric constants in .class file bytecode. |
| jar_edit_constant_poolC | Edit constants by their exact constant pool index. |
| jar_hex_editC | Write raw bytes at a specific offset in a file. |
| jar_add_fileC | Add a file from disk into the JAR. |
| jar_add_file_contentC | Write text content as a new file in the JAR. |
| jar_compile_javaC | Compile Java source code and optionally inject into JAR. |
| jar_diffC | Show differences between original and modified file. |
| jar_restore_fileB | Restore a file from backup to undo modifications. |
| jar_preset_saveC | Save a named preset of constant edits for reuse. |
| jar_preset_applyC | Apply a saved preset of constant edits. |
| jar_preset_listB | List all saved edit presets. |
| jar_repackC | Repack the modified JAR file with all changes. |
| jar_scaffold_modC | Generate a minimal Minecraft mod JAR structure. |
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 100 tools
Many tools have overlapping purposes across search, hex, decompilation, and session management. For example, pattern_scan, pattern_scan_all, search_binary_pattern, hex_search, and jar_search_opcodes are all pattern/byte searches, while load_game, open_game, mod_this_game, and detect_engine all initialize game contexts. This creates a high risk of misselection.
Most names use snake_case with readable prefixes like jar_ and gorebox_, but the verb/noun ordering is mixed: pattern_scan and hex_read are noun-first, while build_and_deploy and find_gameplay_values are verb-first. It is readable but not a single predictable convention.
100 tools is an extreme surface for one server, well beyond the 15-tool guideline. The set is bloated with overlapping utilities and multiple engine-specific clusters, making discovery and selection unwieldy.
The surface covers a broad game-modding lifecycle: engine detection, Unity/Unreal/Godot/JAR analysis, native disassembly, mod generation, compilation, deployment, verification, and repair. Minor gaps exist, such as Godot mod generation/repacking and explicit mod uninstall, but core workflows are covered.