erdgraph
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ERDGRAPH_KET | No | Set this to use a ket binary under another name. ket is optional; with it on PATH, every build and label gets a content ID and lineage. | |
| ERDGRAPH_HOME | No | The workspace directory used by erdgraph. Defaults to ~/.local/share/erdgraph. | ~/.local/share/erdgraph |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| buildsA | List ingested builds (newest last) with Steam build id and ket manifest CID. |
| overviewC | Counts, sections and label status totals for a build (default: newest). |
| findB | Substring search (case-insensitive) across classes, labels, exports, strings and imports. |
| class_infoC | RTTI class: bases (with offsets), derived classes, vtables with labelled slots, and constructor/destructor candidates (functions that take the vtable's address). |
| function_infoC | Everything the graph knows about the function containing addr: bounds, fragments, labels, vtable slots, callers, callees, imports called, strings and globals touched. |
| disassembleB | Annotated disassembly. With whole_function, starts at the containing function's start and includes its chained fragments; otherwise starts exactly at addr. |
| xrefs_toC | Code references to an address (function, global, string, vtable, IAT slot). |
| callgraphC | Breadth-first call graph around a function. direction: callees | callers. |
| global_infoC | What lives in a global: writers, readers, and the RTTI classes whose vtables the writers take, which usually identifies a singleton pointer's type. Also the nearest qualified-name strings the writers reference. |
| read_memoryC | Static bytes from the image, with qword interpretation and names for pointer-looking values. |
| make_signatureB | Shortest unique AOB pattern at addr, with RIP-relative and branch operands wildcarded. |
| scan_signatureB | Find an AOB pattern ('48 8B 05 ?? ?? ?? ??') in code sections. Returns up to 16 matches. |
| propose_labelC | Record a proposed name with its evidence. Creates a ket node (edge: proposes) under the build node and stores a signature so the label can be ported to later builds. |
| review_labelC | Confirm or refute a label ('confirms' | 'refutes'). Creates a ket node linked to the proposal. |
| labelsC | List labels, filtered by status (proposed|confirmed|refuted|ported|superseded) and name substring. |
| port_labelsC | Carry proposed/confirmed labels from one build to another via their signatures. |
| harvest_namesB | Propose names from embedded qualified-name strings (e.g. 'CS::FieldArea::IsEnableFastTravel') referenced by exactly one function. Labels land as 'proposed' at confidence 0.55 for review. |
| sqlB | Read-only SQL over the build graph. Tables: functions, classes, class_bases, vtables, vtable_slots, exports, imports, strings, xrefs(insn_va, func_va, dst, kind), labels, sections, meta. |
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 18 tools
Most tools target clearly distinct operations (e.g., disassemble vs. callgraph vs. xrefs_to), but there is minor overlap: find can search labels that labels also lists, and propose_label vs. harvest_names both create proposed labels. Descriptions clarify the boundaries, so confusion is limited.
Tool names mix noun-style (builds, overview, find, class_info, sql) with verb_noun-style (port_labels, make_signature, scan_signature, propose_label, review_label, harvest_names). The pattern is not consistent, though all names remain readable and understandable.
18 tools is slightly above the typical 3–15 range, but each tool covers a distinct aspect of reverse-engineering graph analysis (builds, classes, functions, disassembly, xrefs, callgraph, globals, memory, signatures, labels, SQL). The count is reasonable for the domain, though not minimal.
The surface covers the core lifecycle: build overview, search, class/function/global inspection, disassembly, xrefs, callgraph, signatures, and label proposal/review/listing/porting. Minor gaps exist, such as no explicit label deletion or update operation and no xrefs_from tool, but these are workable via SQL or new proposals.