How do I use re-angr?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@re-angr build control flow graph for function 'main' in /bin/ls" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

re-angr

by Heretek-RE

Overview Schema Source Related Servers Discussions Admin

Python

Local

re-angr

MCP server for angr (UC Santa Barbara, BSD) — symbolic execution + CFG + reaching-definitions. The "I have a heavy constraint problem and want a second opinion" tool.

Why

The other RE-AI MCP servers handle most RE tasks well. But there are two cases where angr's approach is materially different from re-triton's:

CFG construction. angr's CFG is built statically (no execution, no emulation) and is one of the most accurate in the open-source world. re-rizin.analyze_function is faster but uses different heuristics; cross-validating with angr catches edge cases.
Reaching definitions. angr's dataflow analysis is what makes re-mba-deobfuscate reliable. An MBA identity like x + y == (x & y) + (x | y) looks like real arithmetic, but the reaching-defs graph reveals that (x & y) and (x | y) were defined from the same source — the identity is a no-op substitution.

re-angr exposes both, and re-triton for the same constraint problem. The two together give the analyst a much stronger signal than either alone.

Related MCP server: angr-mcp

Architecture

The Python MCP server is a thin wrapper around an angr-cli Python helper installed by install.sh:

Claude Code (MCP stdio)
  │
  ▼
re-angr server (Python, this directory)
  │  subprocess.run(...)
  ▼
angr-cli (small Python script, wraps the angr API)
  │
  └─ angr>=9.2 (pip-installed, the actual binary analysis platform)

The subprocess boundary is intentional: angr keeps long-lived AngrProject objects, which don't survive across JSON-RPC calls cleanly. The helper spawns a fresh Python process per call, which matches the per-tool-call model the MCP server uses.

Tools

Tool	What it does
`check_angr`	Health check — return angr + cle versions
`build_cfg`	Build a control-flow graph of a binary (or one function)
`symbolic_exec`	Run angr symbolic execution starting at an address
`reaching_definitions`	Compute the def-use graph for a function

Install

./install.sh installs angr>=9.2 from PyPI.

To install standalone:

pip install 're-angr[core]'

Requirements

Python 3.11+
angr>=9.2 (BSD, on PyPI)
No system dependencies

Degraded mode

If angr-cli is not installed, every tool returns {"status": "WARN", "error": "angr-cli not installed; run install.sh", ...}. The Python MCP server itself always loads so Claude Code can surface the install hint.

Pairing with `re-triton`

re-triton is the fast first-call symbolic executor (Triton 1.0 with Quarkslab's bindings). re-angr is the cross-validation pass:

Use re-triton.solve_constraint for "what input reaches this branch?" (fast, in-process).
Use re-angr.symbolic_exec for "does another symbolic executor agree?" (slower, but independent).
Use re-angr.reaching_definitions for "where was this variable defined?" (Triton doesn't compute this — it's a static dataflow analysis).

For MBA-obfuscated arithmetic: re-triton.solve_constraint solves the symbolic equation; re-angr.reaching_definitions shows the variable is a no-op substitution. Both together is a strong "this is a known identity" signal.

For CFG construction: re-rizin.analyze_function is the fast first call; re-angr.build_cfg is the cross-validation pass. Discrepancies (e.g. angr sees an indirect call that rizin doesn't) are worth investigating.

Available Tools

4 tools

build_cfgA

Build a control-flow graph of path (optionally one function).

Args: path: PE / ELF / MachO to analyze function: optional function name (e.g. "main") — when given, only the CFG of that function is returned; when None, the full program CFG is returned.

Returns::

{"path": "...",
 "function": "..." | null,
 "nodes": [{"addr": N, "size": M, "successors": [...]}],
 "edges": [{"src": N, "dst": M, "kind": "fall-through|jmp|call|ret"}]}

The CFG is the first thing an analyst needs for VM detection (high incoming-edge count on a single block = dispatcher candidate) and for binary comprehension in general.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`function`	No

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided so description carries full burden. It describes the return format and use case but omits performance, limitations, or error conditions. Partially adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main action, and structured with Args/Returns sections. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description covers purpose, parameters, and return but lacks details on side effects, permissions, or prerequisites. Adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining 'path' as PE/ELF/MachO and 'function' as optional with default None behavior, plus return format. Adds significant meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it builds a control-flow graph of a binary path, optionally for a single function. This distinguishes it from sibling tools like symbolic_exec and reaching_definitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when to use the CFG (first thing for VM detection, binary comprehension) but does not explicitly state when not to use or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_angrA

Return angr-cli + angr package version + Python import probe.

Reports WARN (not ERROR) when the helper or the Python module is not importable. The fallback chain for the CLI binary: $RE_ANGR_CLI_PATH -> <server>/bin/angr-cli -> PATH. The Python import probe (added in v2.9.1 to fix Gap 23) runs import angr; import cle in a subprocess using the same Python interpreter the MCP server runs under. The CLI check alone is insufficient: the CLI can be installed while the server's interpreter lacks the angr package, which causes downstream tools (build_cfg, symbolic_exec, reaching_definitions) to emit No module named 'angr'.

Status is OK only when BOTH the CLI is present AND the Python import probe succeeds. Otherwise status is WARN with a concrete install hint.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description thoroughly explains the fallback chain, the import probe logic, the distinction between CLI and Python import, and the conditions for OK vs WARN status, which is highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but well-structured, with clear explanations. It could be slightly more concise, but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return status (OK/WARN) and provides concrete install hints, making it complete for its purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100%. The description does not need to add parameter info, meeting the baseline for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns version info and import probe results. It distinguishes from siblings like build_cfg, reaching_definitions, and symbolic_exec by being a health check for angr dependencies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used before running other angr tools to ensure dependencies are available, but it does not explicitly state when to use it or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reaching_definitionsA

Compute the reaching-definitions graph for function.

A reaching definition is "where was the value used at instruction X defined?" angr computes the dataflow analysis statically. The output is a def-use graph: every variable gets a list of definitions; every instruction that reads a variable gets the list of definitions that may reach it.

Useful for the re-mba-deobfuscate skill: the MBA identity x + y == (x & y) + (x | y) looks like arithmetic, but the reaching-defs graph reveals that (x & y) and (x | y) were both defined from the same source — the identity is a no-op substitution.

Args: path: PE / ELF / MachO function: function name (e.g. "main")

Returns::

{"path": "...", "function": "...",
 "defs": [{"variable": "...", "defined_at": "0x..."}],
 "uses": [{"at": "0x...", "reads": ["var1", "var2"]}]}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`function`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the analysis is done statically and describes the output as a def-use graph. However, it does not disclose error handling (e.g., missing function) or performance implications. The return structure is outlined but side effects are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and includes an example usage. It is structured with paragraphs, args, and returns. A bit verbose but each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides an expected return format. However, it lacks details on error cases, limitations (e.g., large functions), or prerequisites. For a non-trivial analysis tool, more completeness would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description adds essential meaning: 'path: PE / ELF / MachO' and 'function: function name (e.g., "main")'. While helpful, it does not specify constraints like file format validation or path requirements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Compute the reaching-definitions graph for *function*' and explains what reaching definitions are with a concrete example for the re-mba-deobfuscate skill. It distinguishes itself from sibling tools like build_cfg and symbolic_exec by focusing on dataflow analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is 'Useful for the re-mba-deobfuscate skill' but does not explicitly specify when to use or not use this tool versus alternatives. No exclusions or comparisons to siblings are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

symbolic_execA

Run angr symbolic execution starting at address.

Args: path: PE / ELF / MachO to analyze address: entry point as a hex string (e.g. "0x401000") args: optional list of symbolic-arg names (default: none — angr marks stdin / argv as symbolic depending on the binary's entry point conventions)

Returns::

{"path": "...",
 "address": "0x401000",
 "states_explored": N,
 "constraints": [{"path": [...], "expr": "..."}],
 "dead_ends": N}

The output is a partial trace — angr explores until either all paths are explored or the timeout is hit. The result is useful for cross-validation: "angr and Triton both find this MBA identity holds" is a much stronger signal than either alone.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`address`	Yes
`args`	No

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully carries the burden of behavioral disclosure. It explains the tool is a partial trace, explores until timeout or all paths, describes return values, and notes default behavior for args. No annotations exist, so this is comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured as a docstring with clear sections. Every sentence adds value, including purpose, parameter details, return format, and use case. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameters, return format, and limitations (partial trace, timeout). It could mention default timeout or how to set it, but is generally complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds significant meaning: path is PE/ELF/MachO, address is hex string, args are optional symbolic-arg names with default behavior explained. It compensates well for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Run angr symbolic execution starting at *address*', specifying the tool and key input. It distinguishes the tool from siblings (build_cfg, check_angr, reaching_definitions) by focusing on symbolic execution and mentioning cross-validation with Triton.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for symbolic execution and cross-validation with Triton, but does not explicitly state when to use this tool over alternatives. No direct comparison or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Jun 10, 2026
- First observedbuild_cfg
- First observedcheck_angr
- First observedreaching_definitions
- First observedsymbolic_exec

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-10 19:46 across 4 tools

Disambiguation5/5

Each tool targets a distinct binary analysis operation: CFG construction, installation verification, dataflow analysis, and symbolic execution. There is no overlap in their purposes or outputs.

Naming Consistency4/5

All tool names use snake_case and are descriptive, but they mix verb_noun (build_cfg, check_angr) with noun_phrase patterns (reaching_definitions), leading to minor inconsistency.

Tool Count4/5

Four tools cover a focused set of angr-based analyses, each earning its place. The count feels appropriate for a specialized server, though slightly limited for broader reverse engineering tasks.

Completeness3/5

The set covers CFG, dataflow, and symbolic execution but lacks fundamental operations like disassembly or function enumeration, which may force agents to rely on external tools for basic analysis.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
Android Security Analyzer A
io.github.ako2345
MCP server for static security analysis of Android source code
Security Code Analysis Testing & QA Tools
422
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1

Related MCP Servers

IDA Pro MCP
Code Execution Developer Tools
mrexodia
A
license
C
quality
A
maintenance
MCP Server for automated reverse engineering with IDA Pro.
Updated 17 days ago (2026-08-28 18:08 UTC)
43
995 PyPI
12,013
MIT
angr-mcp
Code Analysis Penetration Testing
karimodm
A
license
Not graded
quality
D
maintenance
Exposes angr binary-analysis capabilities (symbolic execution, taint analysis, CFG recovery) as MCP tools for vulnerability exploration and exploit development.
Updated 9 months ago (2025-12-03 15:12 UTC)
9
MIT
re-mcp
Code Analysis Developer Tools
jtsylve
A
license
Not graded
quality
B
maintenance
A multi-backend MCP server that exposes binary analysis capabilities from IDA Pro and Ghidra, allowing LLMs to directly drive reverse-engineering tools via natural language.
Updated 6 days ago (2026-09-09 13:55 UTC)
152
Apache 2.0
re-rizin
Code Analysis Developer Tools
Heretek-RE
A
license
Not graded
quality
C
maintenance
MCP server exposing the rizin CLI for static binary analysis of executables.
Updated 3 months ago (2026-06-10 19:50 UTC)
MIT

re-angr

Why

Architecture

Tools

Install

Requirements

Degraded mode

Pairing with re-triton

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Pairing with `re-triton`