Loading ToolBench
Volatility 3 memory triage over MCP. Exposes tools for digital forensics and incident response: session management, process tree analysis, network scanning, timeline generation, and finding management.
dfir-mcp has 7 tools with basic descriptions but critical gaps in schema documentation and parameter clarity. Tool names follow verb_noun convention (session_create, vol_pstree, finding_add) which is good. However, most tools lack visible input parameter schemas in the provided code, only session_create shows explicit parameter definitions (name, image_filename, os with types and descriptions). The remaining 6 tools (session_status, vol_pstree, vol_netscan, vol_timeline, finding_add, finding_list) show empty input schemas {} in the tool list, meaning no parameters are documented. Descriptions are present but brief (10-50 chars for most), below the 50-200 char LLM-optimized baseline. Error handling via _handle_errors decorator is present and returns structured error objects with status codes, which is good. However, no output schemas are documented, and no tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. The server lacks pagination support, result limits, and chaining IDs in responses. Security: path traversal check in session_create is present; no secrets in parameters detected.
pin an analyst/LLM observation to the case
list pinned findings for the active case
Start a new investigation case against a memory image.
Show the active case: image, plugins already run, findings pinned so far.
Run the network-connection plugin (windows.netscan or linux.sockstat, depending on the active case's OS) against the memory image. Returns connection count plus flagged anomalies (suspicious ports, processes not normally expected to make network connections) rather than the full raw connection table.
Run the process-tree plugin (windows.pstree or linux.pstree, depending on the active case's OS) against the memory image. Returns a structured process count plus a short list of flagged anomalies (unresolved parents, unexpected lineage, duplicate PIDs) rather than the full raw process tree.
6 of 7 tools have empty input schemas ({}). No parameter types, descriptions, or constraints visible for session_status, vol_pstree, vol_netscan, vol_timeline, finding_add, finding_list. LLMs cannot infer what parameters these tools accept or require.
No output schemas documented for any tool. Callers cannot know what fields to expect (e.g., does vol_pstree return process_count, anomalies, raw_rows?). Breaks tool chaining and forces LLMs to guess response structure.
Tool descriptions are too brief (10-50 chars for most). Below LLM-optimized baseline of 50-200 chars. Descriptions like 'unified chronological timeline from stored evidence' lack context on when to call, what it returns, and prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
unified chronological timeline from stored evidence
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot distinguish safe read-only tools from destructive ones. session_create and finding_add modify state but lack destructiveHint annotation.
No pagination, result limits, or chaining IDs documented. vol_pstree and vol_netscan return 'structured summary + anomalies' but no schema shows what fields are included or how to chain results to downstream tools.