A read-only MCP server that gives an AI agent static reverse-engineering tools over Ghidra/r2/capa/floss/angr/jadx, with untrusted samples analyzed inside a no-network bubblewrap sandbox.
re_capabilities — health check: which RE backends (Ghidra, r2/rizin, capa, floss, angr, jadx, apktool, bwrap) are installed and their versions; call it first.
analyze_binary — full host-side static triage of a native binary (ELF/PE/Mach-O/.so): Ghidra decompile → capa → floss (opt) → sink ranking → angr (opt), returning JSON with ranked suspicious functions, capabilities and strings. For own/in-scope/CTF samples only.
sandbox_analyze_binary — the same triage but isolated in a bubblewrap chamber (--unshare-all, no network, dropped capabilities, cgroup mem/PID/CPU limits, host read-only, target never executed). For untrusted/third-party samples.
sandbox_selftest — runs the shipped sandbox script's --selftest to prove live that network egress fails and host writes are blocked (PASS/FAIL per check).
decompile_function — decompile exactly one function to C text + signature via Ghidra headless, by name or address (e.g. main, check_license, 0x401160).
list_symbols — fast r2/rizin inventory (seconds, no Ghidra) of functions, imports or strings, useful for picking decompile targets.
analyze_apk — Android APK triage: extracts native lib/*/*.so (optional arch filter) and runs each through static triage; sandboxed by default, unpacks but executes nothing.
All tools are read-only — nothing is patched, rebuilt or executed — and long-running Ghidra steps can take minutes.
Provides tools for Android native-lib triage, analyzing native .so libraries within APKs to rank suspicious functions and inventory symbols, imports, and strings, sandboxed by default.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sandboxed-re-mcp sandbox analyze this untrusted binary and rank suspicious functions"
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.
A security-first reverse-engineering MCP server. It gives an AI agent (Claude Code, Cursor, any MCP client) a small, read-only set of static reverse-engineering tools over a proven, auditable stack — and runs every untrusted sample inside a no-network bubblewrap chamber that never executes the target.
Status — v0.1.0, early but gated. The surface is small and the API may still move, but nothing merges unless the isolation proof runs green in CI. We would rather ship a narrow tool whose guarantees are real than a broad one whose guarantees are hopes.
Scope / lawful use. For software you own, in-scope bug-bounty targets, CTFs, abandonware, and interoperability research permitted by law. Read-only by design: it never patches, rebuilds, or executes the target. See
SECURITY.mdand the Threat Model.
Related MCP server: retriage
A wave of "AI reverse-engineers anything over MCP" tooling is genuinely useful — broad,
convenient, well-packaged. The best-known of them, morluto/rea,
covers an impressively wide surface (native, mobile, web, firmware, network, WASM, managed code).
On raw breadth, REA leads, and this project does not try to match it.
This project makes a different, narrower bet: when you point an analysis tool at a hostile binary, the thing that matters most is isolation and auditability, not feature count. That is exactly the axis where broad orchestrators tend to be weakest — many run their dynamic/runtime paths with your own user privileges and no container at all.
★ The honest one-liner: REA optimizes for breadth; airgap-re optimizes for
safety and auditability on the native-static lane — the lane where you actually touch
untrusted code.
A stdio MCP server (Python, one pinned dependency) that orchestrates a pre-existing RE stack:
Backend | Used for |
Ghidra (headless) | per-function decompilation, function inventory |
| full static triage → ranked suspicious functions |
r2 / rizin | fast symbol/import/string inventory |
jadx / apktool (native-lib path) | Android APK native |
bubblewrap (bwrap) | the isolation chamber for untrusted samples |
It contains no RE logic of its own — it is a thin, auditable bridge. That is a deliberate feature: the whole server is small enough to read in one sitting (~1,200 lines of own code).
Tool | What it does |
| health check: which backends are present + versions |
| full host-side static triage of a native binary (own/in-scope) |
| same triage, isolated (no network, cgroup caps) — for untrusted samples |
| live proof of the isolation guarantees (no analysis target needed) |
| one function → C via Ghidra |
| fast r2/rizin inventory (functions / imports / strings) |
| Android native-lib triage (sandboxed by default) |
The server holds no RE logic; it validates input, picks the trusted vs. sandboxed path, and shells
out to a pre-existing backend stack. The sandbox boundary is the product — everything below
bubblewrap is treated as hostile when the sample is third-party.
flowchart TD
A[MCP client / AI agent] -->|tool call + path| B[re_mcp.server]
B --> V{_validate<br/>abs path, is-file, size cap}
V -->|invalid| E[JSON error]
V -->|valid| P{trusted or untrusted?}
P -->|own / in-scope| H[analyze_binary<br/>host-side triage]
P -->|untrusted| S[sandbox_analyze_binary]
subgraph chamber[bubblewrap chamber: --unshare-all, caps dropped, host read-only, cgroup caps]
S --> T[re_triage.py]
T --> G[Ghidra headless]
T --> C[capa / floss]
T --> N[angr optional]
end
H --> T2[re_triage.py host-side]
B --> R[list_symbols: r2 / rizin]
B --> D[decompile_function: Ghidra]
B --> K[analyze_apk: native .so, sandboxed]
T --> O[(ranked JSON<br/>via /out, host-temp)]
chamber -.no network, no host write.-> X((egress impossible))Full data flow, properties, and the trust boundary: docs/architektur.md.
Every claim below has a test that fails the build if the guarantee breaks
(tests/test_sandbox_isolation.py).
The tests drive the shipped script (engine/sandbox_analyze.sh --selftest), not a
hand-rolled command — so the guard covers the exact code the server runs. Removing
--unshare-all from the shipped script turns the egress test red (verified by sabotage).
No egress. The chamber runs bwrap --unshare-all, which removes the network namespace.
An outbound connection is not blocked by policy — it is structurally impossible.
→ test_shipped_script_blocks_egress
Host filesystem is read-only, except one throwaway /out (a mktemp dir) that is removed
on exit; writes to host paths fail. → test_shipped_script_host_readonly
Resource caps. A cgroup MemoryMax + MemorySwapMax=0 makes a memory-bomb OOM-killed
instead of taking the host down. → test_cgroup_memory_cap_enforced
The target is never executed. The pipeline is purely static; the sample is mounted read-only and analysed as data.
Run the proof yourself:
pip install -e ".[dev]"
pytest -v # includes the isolation proof (needs bubblewrap)No custom seccomp-BPF filter is applied. bwrap applies none by default, and a wrong filter
would silently break Ghidra/Python. Isolation here rests on namespaces (--unshare-all) +
capability drop + read-only binds + cgroup limits — not on a syscall filter we cannot verify.
A reviewed seccomp profile is possible future work, not a current claim.
morluto/rea)The left column is measured by benchmark/run_benchmark.py on this
repo (see benchmark/REPORT.md). The right column is from REA's public repo /
README and our 2026-10-12 tool review — external, not measured here.
Dimension | airgap-re | REA (morluto/rea) |
Tool breadth | native + APK-native (focused) | very broad — REA leads |
Untrusted-sample isolation | bwrap no-net + cgroup, never executed | no sandbox; runtime paths run with your user rights |
Runtime dependencies | 1 direct ( | ~35 npm (per our review — different counting basis) |
Setup footprint | local; does not write into your agent config |
|
Auditability | ~1,200 lines of own code | large tree (~2,255 files, per our review) |
License | MIT | MIT |
If you need the widest possible toolbox on trusted inputs, REA is a strong choice. If you need to analyse someone else's binary without handing it your privileges, this is built for that.
git clone https://github.com/NEO849/airgap-re
cd airgap-re
python -m venv .venv && . .venv/bin/activate
pip install -e .
# System tools (analysis backends — bring your own, like any RE tool):
# bubblewrap (required for the sandbox), radare2/rizin, Ghidra (headless),
# optional: capa, floss, jadx, apktool, angr venv.
sudo apt-get install -y bubblewrap radare2Register with your MCP client (stdio). Example ~/.claude.json fragment:
{
"mcpServers": {
"airgap-re": {
"type": "stdio",
"command": "/path/to/.venv/bin/python",
"args": ["-m", "re_mcp.server"],
"env": { "REMCP_GHIDRA_HEADLESS": "/opt/ghidra/support/analyzeHeadless" }
}
}
}All paths auto-discover from PATH and common install locations; override any via REMCP_*
environment variables (see re_mcp/config.py). Confirm the wiring with the
re_capabilities tool — it reports which backends are present and their versions.
re_capabilities — see what's available.
list_symbols — fast overview, pick targets.
analyze_binary (own/in-scope) or sandbox_analyze_binary (untrusted) — ranked triage.
decompile_function — read the candidates.
Untrusted / third-party samples always go through sandbox_analyze_binary.
re_mcp/ server.py (MCP tools) · config.py (env/auto-discovery)
engine/ re_triage.py · sandbox_analyze.sh · apk_native_triage.sh · ghidra_scripts/
tests/ test_validate.py · test_sandbox_isolation.py (the proof)
benchmark/ run_benchmark.py → REPORT.md
docs/ architektur.md (data-flow diagram)See docs/architektur.md for the data-flow and trust boundaries,
THREAT_MODEL.md for what the sandbox does and does not defend against,
and CONTRIBUTING.md to hack on it.
MIT — see LICENSE.
Android-APK-Triage: zieht native Libs (lib//.so) und jagt jede durch re_triage.py (Ghidra-Dekompilat -> capa/floss -> Sink-Rang). Deckt die native Schicht ab, die jadx/apktool nicht sehen. 'arch' optional, z.B. 'arm64-v8a' (sonst alle). 'sandbox' (Default True): läuft in der bwrap-Kammer (keine Ausführung, kein Netz). READ-ONLY, entpackt nur, führt NICHTS aus der APK aus. Eigene / in-scope APKs.
| Name | Required | Description | Default |
|---|---|---|---|
| arch | No | ||
| path | Yes | ||
| sandbox | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses READ-ONLY, no execution of APK contents, no network, and that sandbox=True runs inside a bwrap chamber by default. It stops short of describing output shape or any resource/rate considerations, but the critical safety profile is fully covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the tool's identity and pipeline come first, then per-parameter notes, then the safety guarantees. No sentence is padding, and the telegraphic style keeps the whole definition compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers behavior, parameters, and scope. The one real gap is disambiguation from the closely related sibling tools (analyze_binary, sandbox_analyze_binary), which an agent would have to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and largely does: 'arch' is documented as optional with an example value and an 'else all' default, and 'sandbox' is explained as default-True with its execution semantics. Only 'path' is left undocumented, but its meaning is self-evident from the required field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource chain: extracts native libs (lib/*/*.so) and runs each through re_triage.py (Ghidra -> capa/floss -> sink rank), explicitly scoping to the native layer jadx/apktool miss. The purpose is unambiguous, but it never differentiates itself from actual siblings like analyze_binary or sandbox_analyze_binary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing line 'Eigene / in-scope APKs' implies an authorization scope, and the native-layer framing hints at when this tool applies versus static APK unpackers. However, it never explicitly states when to choose this over analyze_binary or sandbox_analyze_binary, so the routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Volle statische Triage eines nativen Binaries (ELF/PE/Mach-O/.so) HOST-seitig via re_triage.py: Ghidra-Dekompilat -> capa-Capabilities -> floss-Strings (opt) -> Sink-Rang -> angr (opt). Liefert strukturiertes JSON (Top-verdächtige Funktionen, Capabilities, Strings). READ-ONLY. Für EIGENE / in-scope / CTF-Binaries. Fremde/untrusted Samples -> sandbox_analyze_binary. Kann mehrere Minuten dauern (Ghidra-Analyse).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| floss | No | ||
| symbolic | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does well: it declares READ-ONLY, discloses the multi-minute Ghidra runtime, and enumerates the analysis steps. It stops short of stating auth requirements or failure modes, but the safety and duration profile is unusually complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the pipeline and followed by return summary, safety, routing, and runtime. It is dense but every line earns its place; only the pipeline detail is slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description still summarizes them. Combined with safety, routing, and duration disclosure, this is nearly complete for a 3-param analysis tool; only parameter documentation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by mapping 'floss-Strings (opt)' and 'angr (opt)' to the floss and symbolic boolean toggles, but the required 'path' parameter and its expected format are never addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Volle statische Triage eines nativen Binaries') and enumerates supported formats (ELF/PE/Mach-O/.so). The pipeline (Ghidra -> capa -> floss -> sink ranking -> angr) makes the tool's exact scope unambiguous and distinguishable from siblings like decompile_function or re_capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('Für EIGENE / in-scope / CTF-Binaries') and a named alternative for the excluded case ('Fremde/untrusted Samples -> sandbox_analyze_binary'). This routes the agent correctly without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dekompiliert GENAU EINE Funktion (nach Name oder Entry-Adresse 0x...) via Ghidra-headless -> C-Text + Signatur. 'function' z.B. 'main', 'check_license' oder '0x401160'. READ-ONLY. Kann einige Minuten dauern.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| function | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does reasonably well: it flags READ-ONLY, warns of multi-minute latency, and states the output format. It omits preconditions such as whether the binary must be loaded/analyzed first, so there is a remaining gap but the core behavioral profile is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: purpose, argument form, safety note, and latency caveat in three short clauses. Slightly dense with parenthetical asides, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers the important callable details (exactly one target, argument forms, read-only, runtime). The only real omission is the undefined 'path' parameter and any load prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does this well for 'function' by explaining accepted forms ('main', 'check_license', '0x401160'), but 'path' is left completely undefined in both schema and description. Partial compensation justifies the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Dekompiliert GENAU EINE Funktion'), names the underlying mechanism (Ghidra-headless) and the output form (C-Text + Signatur). The 'GENAU EINE' scope explicitly distinguishes it from bulk siblings like analyze_binary or analyze_apk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clarifies the cardinality constraint ('exactly one function') and how to identify the target (name or 0x entry address), which is genuine routing guidance. However, it never states when to reach for this versus list_symbols or analyze_binary, nor any prerequisite (e.g. needing symbols first). Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schnelles Inventar via r2/rizin (ohne Ghidra, Sekunden). kind = 'functions' | 'imports' | 'strings'. Gut für den ersten Überblick / um Ziele für decompile_function zu finden. READ-ONLY.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | functions | |
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two useful traits: it is READ-ONLY and fast (r2/rizin, seconds, no Ghidra). It does not mention output size limits, truncation, or failure modes for invalid paths, so the behavioral picture is only partially filled in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short telegraphic fragments, front-loaded with what the tool is and what it returns. Nothing is padded, though the clipped style costs a little readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary, and the description supplies the allowed kind values, the read-only guarantee, and the intended workflow position. Only minor gaps remain around path semantics and result limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the kind parameter has no enum, so the description's explicit 'kind = functions | imports | strings' is the only source of allowed values and is essential. The path parameter is left unexplained, but its meaning is obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete resource (symbol inventory via r2/rizin, no Ghidra, seconds) and enumerates the three kinds of symbols it can return. It also implicitly distinguishes itself from the heavier sibling decompile_function, though it doesn't contrast with analyze_binary or analyze_apk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Gut für den ersten Überblick / um Ziele für decompile_function zu finden" gives an explicit first-pass recon role and names the natural follow-up tool. It stops short of stating when NOT to use it (e.g., when decompilation or full analysis is needed instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health-Check: welche RE-Backends sind verfügbar (Ghidra/r2/capa/floss/angr/jadx/apktool/bwrap)
Versionen. Immer zuerst aufrufen, wenn unklar ist, was geht.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the operation class (health check) and the returned content (available backends plus versions), implying a read-only, side-effect-free probe. It says nothing about permissions, latency, or failure behavior, but for a zero-argument probe the core behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler: the first names the operation and output, the second states when to invoke it. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values, and with zero parameters there is no input semantics to cover. Purpose plus invocation timing is all an agent needs, and both are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: a health check that reports which reverse-engineering backends are available and their versions, and it enumerates those backends (Ghidra/r2/capa/floss/angr/jadx/apktool/bwrap). It is clear on its own, but it does not distinguish itself from the overlapping sibling sandbox_selftest, which is also a self-diagnostic tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Immer zuerst aufrufen, wenn unklar ist, was geht" gives an explicit trigger condition (call first, when the available tooling is unclear). It provides clear usage context but no explicit exclusions or named alternatives, so it falls just short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wie analyze_binary, aber ISOLIERT in einer bubblewrap-Wegwerfkammer: --unshare-all (KEIN Netz -> Egress strukturell unmöglich), keine Capabilities, cgroup Mem/PID/CPU-Limits, Host read-only, kein Host-Secret. Für UNTRUSTED / fremde Samples. Braucht bwrap (bubblewrap). READ-ONLY, Ziel wird NIE ausgeführt.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| floss | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden and it delivers richly: unshare-all with no network, no capabilities, cgroup Mem/PID/CPU limits, read-only host, no host secrets, requires bwrap, target never executed. That covers safety profile, resource limits, prerequisites, and non-execution semantics — far beyond a typical tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the key differentiator (ISOLIERT / bubblewrap), then a tight list of isolation properties, then the usage condition. Slightly dense with jargon but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Behavioral and usage context is complete, and output schema covers returns. But with 0% parameter description coverage and no mention of path/floss semantics or the bwrap dependency failing, an agent calling this could be surprised. Adequate but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, so the description should compensate but does not mention path or floss at all. However, the parameter names are self-explanatory (path, floss boolean) and the output schema exists. Baseline 3 for partially self-documenting params with no description support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (sandbox_analyze_binary = analyze a binary isolated), and explicitly contrasts with sibling analyze_binary ('Wie analyze_binary, aber ISOLIERT...'). But it's phrased as a comparison and the actual analysis performed is never enumerated; an agent knows it's analysis-in-a-sandbox but not what output to expect beyond the output schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing rule: 'Für UNTRUSTED / fremde Samples' tells exactly when to prefer this over analyze_binary. The rest of the sentence describes the isolation guarantees that select this tool. Nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Beweist LIVE die Isolations-Garantien der AUSGELIEFERTEN Sandbox (keine Analyse eines Ziels): ruft exakt engine/sandbox_analyze.sh --selftest auf — denselben bwrap-Aufbau (inkl. --unshare-all) wie die echte Analyse. (1) Netz-Zugriff schlägt fehl, (2) Host-Schreiben scheitert. PASS/FAIL je Check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so well: it names the exact invoked script and bwrap setup, and enumerates the two behaviors verified (network access fails, host writes fail) plus the PASS/FAIL-per-check output shape. It omits runtime/duration and any side effects of the selftest itself, keeping it at 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the target-analysis exclusion are front-loaded, then the mechanism, then the enumerated checks. It is dense but every clause earns its place; only slight verbosity in the German compound phrasing keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and it still previews the PASS/FAIL-per-check result format. For a zero-parameter verification tool, nothing an agent needs in order to decide or call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is trivially complete (100% coverage, empty properties) and the description has nothing to compensate for. Baseline 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Beweist LIVE die Isolations-Garantien der AUSGELIEFERTEN Sandbox") and immediately scopes it against siblings with "keine Analyse eines Ziels", so an agent can distinguish it from sandbox_analyze_binary and the other analysis tools without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical "keine Analyse eines Ziels" tells the agent when this tool is NOT the right choice (target analysis), which routes it toward the analyze_* siblings. It stops short of explicitly naming an alternative or stating the trigger condition (e.g. "run after deploying the sandbox"), so a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_apkanalyze_binarydecompile_functionlist_symbolsre_capabilitiessandbox_analyze_binarysandbox_selftestScored across 7 tools
Most tools target clearly distinct operations (capability check, symbol inventory, single-function decompile, full triage, APK triage, sandbox selftest). The main ambiguity is analyze_binary vs sandbox_analyze_binary, whose names are nearly identical, but descriptions strongly disambiguate them via the host-vs-untrusted-sample rule. decompile_function also overlaps with the decompilation phase inside analyze_binary, though its single-target scope keeps it separable.
Names follow a mostly predictable snake_case verb_noun pattern (decompile_function, list_symbols, analyze_binary, analyze_apk, sandbox_selftest). The sandbox_ prefix is used consistently as a qualifier. The only deviation is re_capabilities, which is a noun phrase with a domain prefix rather than a verb_noun action.
Seven tools is well-scoped for a reverse-engineering server: each covers a distinct stage (backend discovery, fast inventory, targeted decompile, full host triage, sandboxed triage, sandbox verification, APK triage). No obvious redundancy or filler tools.
The surface covers the core static RE workflow: discover backends, inventory symbols, decompile a function, run full triage, and do so safely in a sandbox for untrusted samples including APKs. Minor gaps remain, e.g. no explicit cross-reference/call-graph query, no disassembly view, and no dynamic execution, but these are reasonable omissions for a static, read-only toolset.
Signed sandbox verdicts on any artifact, plus an agent marketplace. No key, no signup, no payment.
Hunt zero-days by talking to binaries. 40+ tools. Hosted, OAuth + SSO, invite: hi@byteray.ai
Read-only smart-contract security intelligence for autonomous agents.
Membrane for AI agents: threat intel you can check, IOC enrichment, pre-install package checks.
