Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
UGM_CONFIGNoPath 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.8/5.0

Scored across 100 tools

Disambiguation2/5

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.

Naming Consistency3/5

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.

Tool Count1/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues