Loading ToolBench
AI-native memory research MCP server for reverse engineering
memscope-mcp provides 12 tools with complete input schemas and descriptions. However, there are significant gaps in definition quality: (1) Tool names lack consistent verb prefixes, many are bare nouns ('processes', 'modules', 'scan') rather than verb_noun patterns like 'list_processes' or 'scan_memory'. (2) Descriptions are present but often lack critical actionable detail: they do not clearly state what state changes occur (e.g., 'attach' caches data but doesn't say if it persists across calls), prerequisites, or recovery paths when operations fail. (3) Parameter descriptions are sparse, many lack format constraints, ranges, or examples. (4) Output schemas are not explicitly documented in the provided source, forcing inference of response structures. (5) Error handling is not visible in tool definitions; no guidance for LLM recovery. (6) No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk stratification (WRITE vs READ_ONLY). The server targets reverse engineering and memory manipulation, high-risk operations that require defense-in-depth documentation and error guidance. Overall, the definitions are functional but well below production-grade quality.
Attach to process and cache module bases. Returns pid, key_modules (base/size), saved_scripts list, scripts_dir, and log_file path. Use pid parameter when multiple processes share the same name (e.g., svchost.exe). Use processes() tool first to find the right PID. Examples: attach("Game.exe") or attach("svchost.exe", pid=1820)
Execute Lua code with access to memory reading/writing functions and the Lua engine environment.
List loaded modules with base addresses, sizes, and paths. Set refresh to rebuild the module snapshot and advance its generation.
List running processes with smart filtering. Returns array of {pid, name, path, parent_pid, threads, command_line, services[]}. Services are auto-included for svchost processes. Filters (combine as needed): filter - Substring match on process name pid - Exact PID lookup (returns single process) parent - Only processes with this parent PID service - Only processes hosting this service (e.g., "EventLog") Examples: processes(service="EventLog") - Find which svchost hosts EventLog processes(filter="svchost") - All svchosts with their services processes(pid=1820) - Details for specific PID processes(parent=700) - Children of services.exe
Read raw memory bytes from the attached process at a specified address.
Tool names lack consistent action verbs. 'processes', 'modules', 'scan', 'smart_dump' are bare nouns or vague descriptors. LLM cannot infer intent from name alone. Should be 'list_processes', 'list_modules', 'scan_memory', 'dump_memory_smart'.
No output schemas documented in tool definitions. Tool responses are inferred but not formally specified. LLM cannot predict response structure for downstream planning. Every tool must have documented outputSchema.
No tool annotations despite clear risk stratification. Tools marked WRITE (write, write_typed, execute_lua) should have destructiveHint=true. READ_ONLY tools should have readOnlyHint=true. Annotations enable LLM to reason about side effects and reversibility.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2025-06-18+ | v2 |
Read and interpret memory as a specific type (int8, int16, int32, int64, uint8, uint16, uint32, uint64, float, double, etc.).
Resolve a chain of pointers in memory to find the final address.
Scan memory for pattern matches using memory scanning engine with support for wildcards, offsets, and relative references.
Scan memory for multiple patterns in a single pass for efficiency.
Intelligently dump memory regions with automatic type detection and formatting.
Write raw bytes to memory in the attached process.
Write a value to memory as a specific type.
Descriptions lack state-change clarity and prerequisites. 'attach' does not say if attachment persists or is per-session. 'scan' and 'scan_many' do not document performance implications or result set limits. 'execute_lua' does not describe sandbox/safety boundaries.
Parameter descriptions are sparse or missing format/range constraints. 'pattern' in scan/scan_many lacks syntax specification (hex? bytes? wildcards?). 'address' in read/write/read_typed/write_typed lacks format (hex string? decimal? leading 0x?). 'data' in write lacks encoding detail (hex? ASCII? binary?).
No error handling or recovery guidance in tool definitions. What happens if attach() fails? If scan() times out? If write() hits permission denied? LLM has no guidance to recover or suggest alternatives.
execute_lua is extremely permissive and dangerous. Description does not document what functions are available, what memory restrictions exist, or how to handle runtime errors. Code injection risk is high. Requires strict sandboxing documentation and example safe code patterns.
scan() and scan_many() lack result limits. If a pattern matches 100,000 times, returning all results will exhaust context. Description must cap max_results and explain pagination behavior.