hexvero
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hexvero_openA | Register a local file or directory for analysis. Returns its id, size, hash and detected format. Ids are stable per content. |
| hexvero_listB | List targets opened in this session. |
| hexvero_closeA | Release a target and its retained analysis. |
| hexvero_analyzeA | Run the built-in analyzer for the target's format (ELF/PE/Mach-O, Go, .NET, WASM, EVM, SQLite, plist, APK, ZIP, Electron ASAR, JavaScript apps, source maps, HAR). Returns a summary, findings with confidence, limitations, a compact overview and the collections available for paging. Large JavaScript apps are read in batches: when |
| hexvero_collectionA | Page through one named list from the analysis, e.g. symbols, imports, exports, sections, libraries, types, methods, pinvokes, selectors, instructions, tables, columns, requests, endpoints, permissions, components, modules, edges, ipcChannels, findings. Use hexvero_analyze to see which exist. |
| hexvero_stringsC | Printable ASCII (and optional UTF-16LE) strings with offsets and tags (url, path, email, ip, format, secret-ish, base64-ish). |
| hexvero_bytesA | Read a bounded window (max 64 KiB) of the target as hex plus an ASCII gutter. |
| hexvero_exportA | Write the complete analysis as JSON to a file and return its path and size. Use this instead of paging when you need everything. |
| hexvero_recoverA | Write recoverable sources into a new directory: the modules of a webpack/Rspack/browserify/esbuild bundle (one file each plus hexvero-bundle.json with requires/exports), or the original files embedded in a source map (sourcesContent). No engine needed; nothing is executed. |
| hexvero_unknownsB | Record a material question the investigation could not answer (with what was already checked), list open or resolved unknowns, or resolve one. Unknowns are exported with the analysis so reports never silently drop them. |
| hexvero_compareA | Diff one collection between two targets: added, removed, changed (with the fields that differ) and unchanged items, matched by key (auto-detected: name, channel, id, path, url, type+name … or pass key, a+b for composites). States completeness; unknown items are neither added nor removed. Each list pages on its own (list + offset). Without collection: counts per shared collection, to pick one. |
| hexvero_checkA | Apply a release policy (inline JSON or file) to two builds, as |
| hexvero_sourcemapB | Map a generated line/column of a source map target back to its original source, line, column and name. |
| hexvero_providersA | Detect optional external engines (radare2/rizin, Ghidra) and the operations each supports. |
| hexvero_provider_runB | Run one engine operation on a target: functions, disassemble, decompile, strings, imports, xrefs (references to an address), callers, callees, callgraph or search (names + strings). Output is bounded and cached. |
| hexvero_call_graphA | Bounded call-graph neighborhood around a function (callers, callees or both, by depth and node count), or the shortest call path from root to goal. One engine run per target, cached; levels state what was cut. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| investigate_feature | Trace how a feature, string or API is represented in a local target, from discovery to evidence. |
| compare_versions | Diff two builds of the same software: what was added, removed or changed, with evidence. |
| triage_binary | Hardening, toolchain, dependencies and suspicious indicators of an executable or library, without running it. |
| map_electron_app | Main/preload/renderer boundaries, IPC surface and security posture of an Electron application. |
| explain_apk | Permissions, components, deep links, native code and SDKs of an APK and what they imply. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools target distinct actions, but hexvero_provider_run overlaps heavily with hexvero_strings and hexvero_call_graph by including strings, callers, callees, and callgraph operations. The analyze/collection distinction is explained well, but the generic provider runner creates real selection ambiguity.
All tool names use a consistent hexvero_ prefix and lowercase snake_case, avoiding camelCase or mixed delimiters. The only minor inconsistency is semantic style: some names are verbs (open, close, analyze) while others are nouns (collection, bytes, unknowns).
Sixteen tools is slightly above the typical 3-15 range, but the domain is broad: binary/app analysis, extraction, comparison, policy checks, and recovery. Each tool appears to earn its place, though the general provider_run tool adds some surface area that dedicated tools already cover.
The surface covers target lifecycle, analysis, paged collection extraction, raw bytes/strings, export, comparison, policy checking, bundle/source recovery, and unknown tracking. Minor gaps remain, such as no clearly separate metadata/status retrieval beyond open/list and some overlap rather than missing core workflows.