AFL++ MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AFLPP_DIR | No | Path to AFLplusplus directory (must be inside AFLPP_MCP_ROOT) | $AFLPP_MCP_ROOT/AFLplusplus |
| AFLPP_MCP_ROOT | No | Root directory for AFL++ workspace (default: current working directory) | current working 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
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| aflpp.list_toolsA | List AFL++ MCP tools and their short descriptions. |
| aflpp.helpA | Get detailed help for a tool (schema + description). |
| aflpp.versionA | Get AFL++ and server version information. |
| aflpp.init_workspaceA | Create a workspace under workspaces/ with standard subdirectories: in,out,targets,build,logs,dicts,repros,reports. |
| aflpp.detect_build_systemC | Detect a likely build system for a project path (heuristic). |
| aflpp.build_instrumentedC | Run a constrained build command with AFL++ compiler wrappers and copy the resulting artifact into the workspace targets/ directory. |
| aflpp.build_cmplog_variantA | Build a CMPLOG-instrumented variant by setting AFL_LLVM_CMPLOG=1 during compilation (LLVM mode) and copy the artifact into the workspace targets/ directory. |
| aflpp.import_corpusA | Import a seed corpus into workspaces//in/ from a file or directory within the workspace root. |
| aflpp.list_corpusA | Summarize a corpus directory (file count and total size). |
| aflpp.list_builtin_dictionariesA | List AFL++ builtin dictionaries shipped in the AFLplusplus/dictionaries directory. |
| aflpp.attach_dictionaryA | Attach a dictionary file to a job name (stored as a job config to be used by start_fuzz). |
| aflpp.dry_runA | Run a short harness validation directly against the target (not afl-fuzz): checks input mode, stability, and basic performance signals. |
| aflpp.showmapC | Run afl-showmap for a single testcase and return a summary of the trace. |
| aflpp.coverage_summaryC | Measure corpus coverage using afl-showmap -C on an AFL++ output directory. |
| aflpp.analyze_testcaseC | Run afl-analyze on a testcase to identify critical input regions. |
| aflpp.whatsupD | Run afl-whatsup on an AFL++ output directory. |
| aflpp.preflight_checksA | Run lightweight preflight checks before starting afl-fuzz (core_pattern, CPU scaling, corpus non-empty). |
| aflpp.start_fuzzC | Start an afl-fuzz job in the workspace (non-blocking). |
| aflpp.start_fuzz_clusterC | Start a multi-instance afl-fuzz campaign (master + secondary instances). |
| aflpp.suggest_fuzz_cluster_mixC | Suggest a multi-core campaign mix (instance_overrides) for aflpp.start_fuzz_cluster. |
| aflpp.stop_fuzzA | Stop a running afl-fuzz job by PID (SIGTERM then SIGKILL). |
| aflpp.statusA | Get job status by parsing fuzzer_stats and queue/crashes/hangs counts (with deltas since last call). |
| aflpp.campaign_summaryC | Summarize a multi-instance campaign by parsing fuzzer_stats for each instance directory. |
| aflpp.generate_progress_plotC | Generate an AFL++ progress plot for a job or campaign (wraps afl-plot). |
| aflpp.list_findingsC | List crash and hang findings with stable IDs and paths. |
| aflpp.repro_crashA | Reproduce a finding by running the target command directly with the testcase; captures stdout/stderr and writes a repro bundle under repros/. |
| aflpp.crash_reportC | Write a crash report for a finding (dedup signature + repro info + sanitizer frames if present). |
| aflpp.casr_reportC | Generate clustered crash reports using casr-afl (if installed). |
| aflpp.minimize_corpusB | Minimize a corpus using afl-cmin and store it as a new corpus directory in the workspace. |
| aflpp.minimize_testcaseB | Minimize a single testcase using afl-tmin and store the minimized testcase under repros/. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| aflpp-agent-workflow | Agent workflow: build/instrument -> init workspace -> import/minimize corpus -> dry run -> fuzz -> monitor -> triage/repro/minimize -> (optional) dict/CMPLOG. |
| aflpp-harness-workplan | Harness workplan: learn usage -> write LLVMFuzzerTestOneInput harness -> genesis corpus -> build CMPLOG/ASAN/vanilla -> run coordinated fuzz campaign(s). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| AFL++ MCP config | Server configuration (workspace root, limits, allowlist). |
| AFL++ MCP quickstart | Curated workflow notes for the fuzzing agent. |
| AFL++ docs: fuzzing_in_depth | Upstream AFL++ documentation: fuzzing_in_depth.md (local checkout). |
| AFL++ docs: CmpLog | Upstream AFL++ documentation: instrumentation/README.cmplog.md (local checkout). |
| AFL++ docs: env_variables | Upstream AFL++ documentation: docs/env_variables.md (local checkout). |
TDQS
Scored across 30 tools
Most tools have clear, distinct purposes. Minor overlap exists between status, whatsup, and campaign_summary, which all report on fuzzing progress, and among crash-related tools (repro_crash, crash_report, casr_report), but descriptions provide enough distinction.
The majority follow a verb_noun pattern with underscores (init_workspace, start_fuzz, list_findings). A few exceptions like whatsup and showmap break the pattern, and casr_report uses an abbreviation, but the overall convention is consistent.
At 30 tools, the set exceeds the 25-tool threshold for 'too many'. While the AFL++ domain is complex, several meta tools (help, version, list_tools) and overlapping status/report functions could be consolidated, making the count feel heavy.
The tool set covers the core fuzzing lifecycle: workspace setup, building, corpus management, execution, monitoring, and crash analysis. A notable gap is the lack of a 'list running jobs' tool, but most workflows are supported end-to-end.