Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
IDADIRNoPath to IDA Pro installation directory
GHIDRA_INSTALL_DIRNoPath to Ghidra installation directory

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
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/ui": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
close_databaseA

Close a database and terminate its worker process.

Specify database when multiple are open. Fails if the DB is not attached to the current session unless force=True. When other sessions still use the DB, detaches this session but keeps the worker alive.

save_databaseA

Save the current database to disk (may take minutes for large DBs).

Specify database when multiple are open. Fails if the DB is not attached to the current session unless force=True. Progress notifications are sent every 5s during long saves.

list_databasesA

List all open databases with metadata (includes opening/analyzing status).

wait_for_analysisA

Block until database(s) finish opening and optional auto-analysis.

Single: pass database to wait for one DB. Multi: pass databases list — returns when at least one is ready. Work on the ready one, call again for the rest.

While analysis runs, the backend thread is blocked — tool calls queue.

list_targetsA

List available targets (processors, loaders, languages, etc.).

open_databaseA

Open a binary or existing IDA database (.i64/.idb) for analysis.

Returns immediately with "opening": true — call wait_for_analysis before using other tools on this database. Re-opening an already-open database returns the existing worker.

Multiple binaries: use a separate subagent per binary. Each agent calls open_database then wait_for_analysis. Do NOT serialize open+wait calls — that blocks parallel loading.

force_new=True is destructive: deletes existing .i64/.idb and all prior analysis. Use only for stale/incompatible DBs.

Fat Mach-O: requires explicit fat_arch (e.g. arm64). Error lists available slices. Use distinct database_id per slice for concurrent analysis. fat_arch must be omitted for non-fat files and existing databases.

search_toolsA

Search hidden tools by regex (pinned tools excluded; use .* for all).

Returns one-line signatures by default. Use detail="detailed" for parameter schemas, or follow up with get_schema(tools=[...]).

Hidden tools must be called via call, batch, or execute — direct calls will fail because they are not in the client tool list.

get_schemaA

Get parameter schemas for specific tools by name (pinned and hidden).

Use after search_tools or before execute/batch to check parameter types and return shapes. Pass detail="full" for complete JSON schemas.

Hidden tools must be called via call, batch, or execute — direct calls will fail because they are not in the client tool list.

executeA

Run Python code that chains tool calls. Use await invoke(name, params) to call tools; use return to produce output.

database is auto-injected into every invoke — omit it from params. Override per-call with explicit database for cross-database work.

When NOT to use execute

  • Single tool call → use the call meta-tool (or the direct tool if pinned).

  • N independent calls → use batch (lower overhead, per-item errors). → Otherwise, use the batch meta-tool for sequential multi-tool execution with per-item error collection and progress reporting.

  • Check if a tool has a built-in batch parameter first (e.g. get_strings filters=[...]).

When to use execute

Multi-step pipelines — chaining one tool's output into another:

decomp = await invoke("decompile_function", {"address": "0x1234"})
addrs = re.findall(r'sub_([0-9A-Fa-f]+)', decomp["pseudocode"])
xrefs = [await invoke("get_xrefs_to", {"address": f"0x{a}"}) for a in addrs]
return {"decomp": decomp, "xrefs": xrefs}

Cross-database parallel queries — use asyncio.gather with explicit database params. Same-database calls are serialized by the worker.

Reference

  • Blocked tools: open_database, close_database, wait_for_analysis, list_targets, and meta-tools (search_tools, get_schema, execute, batch, call) must be called directly. save_database and list_databases are allowed.

  • Addresses are strings: "0x401000", "4010a0", or symbol names.

  • filter_pattern is Python regex — use re.escape() for literals.

  • Available imports: asyncio, collections, functools, itertools, json, math, operator, re, struct, typing. No FS/network I/O.

  • Paginated results have items, total, offset, limit, has_more — always check has_more.

  • Use get_schema(tools=[...]) to look up parameter names and types.

  • Return only what you need — filter before returning to save context.

batchA

Run 2+ independent tool calls in a single request with per-item error collection.

Preferred over execute for independent calls (no sandbox overhead). Examples: decompile/disassemble N functions, rename N symbols, set N comments, fetch N xrefs.

Use execute only when chaining one tool's output into another.

database is auto-injected into each operation — omit from params. Override per-operation with explicit database for cross-DB work.

callA

Call any tool by name, including hidden tools not in the client tool list.

Use for single hidden-tool calls. For multiple calls, prefer batch.

Prompts

Interactive templates invoked by user choice

NameDescription
survey_binaryOne-call binary triage. Produces an executive summary of the binary: what it is, what it does, key areas of interest, and recommended next steps.
analyze_functionFull single-function analysis. Decompiles, maps data flow, identifies strings and constants, and summarizes behavior.
diff_before_afterPreview the effect of renaming or retyping on decompiler output. Decompiles before and after, then shows what changed.
classify_functionsClassify functions by behavioral patterns to prioritize analysis effort.
find_crypto_constantsScan for known cryptographic constants to identify crypto algorithms in use.
auto_rename_stringsSuggest function renames based on unique string references. Does not apply changes — presents suggestions for review.
apply_abiApply known ABI type information to identified functions (e.g. syscalls, Windows API wrappers, libc stubs).
export_idc_scriptGenerate an IDAPython script that reproduces all user annotations (renames, types, comments) for portability to another IDB.

Resources

Contextual data attached and managed by the client

NameDescription
databases_resourceAll open databases with worker status (supervisor-level)

TDQS

A4.2/5.0

Scored across 11 tools

Disambiguation4/5

Most tools have clearly distinct roles: database lifecycle, target listing, and tool discovery are well-separated. The main ambiguity is between call, batch, and execute, which all invoke tools, but the descriptions provide enough use-case distinction to guide selection.

Naming Consistency4/5

The naming mostly follows a clear verb_noun snake_case pattern (open_database, save_database, list_databases, search_tools). The meta-tools deviate with bare verbs (execute, batch, call), and there is minor singular/plural inconsistency, but the pattern is still predictable overall.

Tool Count5/5

11 tools is well within the ideal range for a purpose-built server. Each tool serves a necessary role: database lifecycle management, target discovery, hidden tool access, and execution orchestration. No tool feels redundant or superfluous.

Completeness4/5

The visible surface covers the full database lifecycle (open, wait, save, close, list) and provides meta-tools to discover and invoke hidden analysis tools. The only minor gap is that direct analysis operations are not visible in the pinned tool list, but this is clearly intentional and workable through search_tools/call/batch/execute.

Maintenance

ActivityMaintained
ResponsivenessResponsive