Loading ToolBench
MCP server wrapping SANS SIFT forensic tools as typed, structured MCP functions for digital forensics and incident response analysis. Provides memory forensics, disk analysis, Windows artifacts parsing, network analysis, browser artifacts, email analysis, cloud artifacts, registry analysis, file carving, Linux forensics, anti-forensics detection, document analysis, threat intelligence, system health monitoring, investigation state management, and evidence indexing.
DeepSIFT has 6 tools with clear forensic intent and mostly complete schemas. Tool names follow verb_noun pattern (scan_*, list_*, query_*, index_*). Descriptions are present and substantive (avg ~150 chars), explaining WHAT and WHEN. However, parameter descriptions are sparse or missing in several tools (e.g., 'source' in index_evidence lacks detail on valid values; 'limit' in query_evidence has no range guidance). Output schemas are not formally documented, responses are wrapped in JSON but structure is inferred from code. Error handling is minimal: no recovery guidance, no categorization of retryable vs fatal errors. Security is reasonable (read-only tools, no secrets in params) but lacks explicit permission declarations and audit trail documentation.
Report what is in the indexed evidence store (row counts per artifact source).
Index the FULL rows of a parsed artifact into the queryable evidence store, so you can later pull subsets without dumping everything into context. Point it at a CSV file or a directory of CSVs the tools wrote (e.g. 'exports/shellbags', 'exports/mft', 'exports/userassist'). Returns the row count.
Lists all available YARA rule sets in the yara_rules/ directory. Use this to discover what hunting rules are available before scanning.
Query the indexed evidence store and return ONLY matching rows (token-bounded) — the scalable way to reach the full artifact set. Substring match across all columns; optionally restrict to one source and cap the number of rows.
Scan a file with YARA rules and return all matches. Built-in rule sets: suspicious_strings, webshells, ransomware, rats, packers. You can also provide an absolute path to a custom .yar file.
Output schemas not formally documented. Responses are wrapped in JSON but structure (fields, types, nesting) is inferred from code, not declared in tool definitions. LLMs cannot reliably plan downstream calls or extract fields.
Parameter descriptions incomplete or missing. 'source' in index_evidence has no guidance on valid values or format. 'limit' in query_evidence lacks range (min/max). 'rule_set' in scan_* tools mentions 'built-in' and 'custom .yar file' but no validation rules or error cases.
Error handling lacks recovery guidance. _run() catches TimeoutExpired and FileNotFoundError but returns raw error strings. No categorization (retryable vs fatal), no actionable next steps for LLM (e.g., 'YARA not installed, install via apt-get install yara').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Scan a memory image for YARA rule matches using Volatility's yarascan plugin. More thorough than file scanning — finds matches in memory-resident code, decrypted payloads, and injected shellcode that may not exist on disk.
No pagination or result limits documented for query_evidence. Default limit=50 is hardcoded but not stated in description. Large result sets could exhaust context window; no guidance on when to paginate or how to iterate.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only but this is not declared in schema. Agents cannot infer safety properties without explicit hints.