HexForge Gateway
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HEXFORGE_URL | No | The base URL of the HexForge Gateway (must already be running). Defaults to http://localhost:8080. | http://localhost:8080 |
| HEXFORGE_API_KEY | No | API key required only if the Gateway has AUTH_ENABLED=true. |
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 |
|---|---|
| list_workspacesA | List every workspace that exists on the Gateway. |
| get_or_create_workspaceA | Get or create a workspace by name - idempotent, safe to call every time you start working on something. |
| list_knowledgeA | List a workspace's knowledge base entries - reports (auto-generated from finished workflows), notes, summaries, chat history. |
| chat_with_workspaceA | Send a message in a workspace's ongoing chat and get a reply, with real multi-turn history (not a one-shot completion) - useful for asking questions about accumulated findings without re-explaining context every time. |
| decompile_apkA | Decompile an APK to readable Java-like source with jadx, for reading and searching - unlike decode_apk, the output is read-only and cannot be rebuilt into an APK. Output lands under the workspace's jadx output directory. Requires jadx on PATH. |
| decode_apkA | Decode an APK's resources to editable XML and disassemble code to smali with apktool (unlike jadx, the result can be rebuilt). Requires apktool on PATH. |
| build_apkA | Rebuild an APK from an apktool-decoded (and possibly edited) project directory. The result is unsigned - sign it separately before installing. Requires apktool on PATH. |
| identify_packerA | Fingerprint the compiler, packer, obfuscator, and anti-debug/anti-VM techniques used in an APK, via APKiD's YARA rules. Requires apkid on PATH (pip install apkid). |
| scan_secretsA | Recursively scan a directory (e.g. jadx/apktool output) for likely hardcoded secrets - AWS/Google API keys, private key headers, Slack/GitHub tokens, JWTs. A curated high-precision starting set, not exhaustive - not a replacement for a maintained secret-scanner on anything that actually matters. |
| search_codeA | Search a directory tree for a regex pattern - e.g. permission strings in decompiled output. |
| read_fileA | Read a single file's contents by absolute path - e.g. a decompiled source file from decompile_apk's output, or a manifest from decode_apk's. Fails if the path is a directory (use list_files first) or doesn't exist. |
| list_filesA | List a directory's immediate contents (or every file beneath it, with recursive) - e.g. to see what decompile_apk or decode_apk produced before reading individual files. |
| adb_devicesA | List connected Android devices/emulators. Requires adb on PATH. |
| adb_shellA | Run a shell command on a connected Android device via adb. As powerful as |
| adb_installB | Install an APK on a connected device via adb. |
| adb_logcatA | Dump and tail the current logcat buffer from a connected device (a snapshot, not a live stream). |
| frida_list_processesA | List running processes (or installed apps) on a device via Frida. Requires frida-tools on PATH and a matching frida-server on the device. |
| frida_traceA | Spawn or attach to a process, inject a Frida script, and capture whatever it emits within a bounded time window (this isn't a real interactive Frida session - it runs the script, waits, then stops it). Requires frida-tools + a matching frida-server on the device. |
| summarize_textA | Summarize arbitrary text (e.g. tool output) using the Gateway's configured AI provider. |
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 19 tools
Every tool targets a distinct action and resource: decode vs decompile are clearly differentiated by rebuildability, adb_* tools each handle a specific adb operation, and frida_trace vs frida_list_processes cover different dynamic analysis aspects. No two tools appear to do the same thing.
The majority of tools follow a verb_noun snake_case pattern (decode_apk, build_apk, scan_secrets). Minor deviations like 'adb_devices' and 'chat_with_workspace' break the pure verb_noun pattern but are still understandable and predictable given the tool's domain.
With 19 tools, this is slightly on the high side of the ideal range, but each tool serves a distinct purpose in the APK analysis and dynamic instrumentation workflow. The count is justified by the breadth of static analysis, file management, ADB, and Frida capabilities, and none feel redundant.
The tool surface covers the full lifecycle of APK analysis: static decoding/decompiling, rebuilding, packer identification, secret scanning, code search, dynamic analysis via ADB and Frida, plus workspace and knowledge management. Minor gaps like a signing tool (explicitly noted as external) and perhaps a network capture tool prevent a perfect score, but the core workflows are well supported.