MCP Server for Moon Injector - provides tools for DLL injection, process manipulation, debugging, and workspace management via Moon Injector native C++ engine and BlackBone
The server defines 15 tools with explicit schemas and descriptions visible in index.js. Naming convention is generally strong (verb_noun pattern: list_processes, inject_dll, eject_dll, etc.). Descriptions are present and substantive (average ~180 chars, within baseline 34-392 range). However, several critical gaps reduce the score: (1) Missing output schemas, no tool documents what fields/structure it returns, preventing LLM planning for downstream calls. (2) Parameter descriptions are sometimes vague; e.g., 'processIdentifier' lacks context on where to find a PID or how to obtain it. (3) Error handling guidance is absent, no recovery hints if injection fails or a process cannot be found. (4) Security-sensitive tools like inject_dll and terminate_process lack confirmation/dry-run patterns and explicit permission documentation. (5) Some tools have optional parameters with no clear defaults (e.g., crashReportsDirectory in get_crash_reports, does it default to a well-known dir?). (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite high-risk operations. Most tools are READ_ONLY or WRITE/DESTRUCTIVE, but LLMs cannot see these risk labels in the MCP protocol.
Verify if a dynamic link library was compiled in Debug mode and check whether valid PDB symbols exist before running debug injection.
Create a new workspace profile in the Moon Injector SQLite database using native C++ DBHandler.
Delete an existing workspace profile and its associated dynamic link library configurations using native C++ DBHandler.
Eject and unload a previously injected Dynamic Link Library module from a target process memory space using native C++ BlackBone engine.
Retrieve all crash dump reports, stack traces, and local variable state generated by the debug watcher.
Retrieve all supported injection techniques in Moon Injector with technical details, stealth ratings, and driver requirements.
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract required fields. E.g., inject_dll likely returns injection status/result, but the response structure is invisible to the LLM.
Missing error handling and recovery guidance. If inject_dll fails (e.g., target process not found, invalid DLL path, permission denied), the description does not hint at recovery steps or what the LLM should try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Retrieve the full JSON stack trace tree, exception code, registers, and local variables for the most recent crash.
Get all dynamic link libraries and modules loaded into the memory space of a specific process using native C++ BlackBone engine.
Retrieve all saved workspaces from Moon Injector SQLite database using native C++ DBHandler.
Get all saved dynamic link library paths assigned to a specific workspace profile using native C++ DBHandler.
Inject a Dynamic Link Library (.dll) into a target process memory using Moon Injector native C++ and BlackBone engine, with optional Visual Studio-style crash debugger watcher.
List all currently running processes in Windows using Moon Injector native C++ routine with Process ID, Process Name, and Architecture (x86/x64).
Resume a frozen/suspended target process after inspecting crash state.
Synchronize and update the dynamic link library list for a given workspace profile using native C++ DBHandler.
Cleanly terminate a frozen/crashed target process after inspecting crash state.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in MCP response, despite clear risk levels. LLMs cannot distinguish read-only tools from destructive ones without annotations. E.g., terminate_process is DESTRUCTIVE but has no annotation to warn the LLM.
Destructive/irreversible operations lack confirmation or dry-run patterns. inject_dll (IRREVERSIBLE) and terminate_process (DESTRUCTIVE) should support a confirm_before_execute pattern or return 'pending_confirmation' to prevent accidental destructive agent actions.
Parameter defaults unclear and may hide surprises. E.g., crashReportsDirectory in get_crash_reports is optional but no default is documented, does it use a well-known system path or fail if omitted? Similarly, injectionMethod in inject_dll defaults to 'standard' per description but no validation ensures fallback behavior.
Chaining IDs missing. E.g., list_processes returns process details but no documented output; inject_dll accepts processIdentifier but if get_process_modules returns a 'process' object with a 'pid' field instead of 'processIdentifier', the LLM must reason about the mapping. Output schemas should ensure field names match parameter expectations.
No permission or scope declaration. These are sensitive security tools (process termination, DLL injection) but the descriptions do not state what permissions the agent needs (e.g., 'requires admin privileges', 'requires write permission to target process'). Audit trails and permission gates are absent.
Generic/ambiguous parameter names. 'processIdentifier' is clear, but 'moduleName' in eject_dll says 'file name or path', ambiguous. Should it be module_name or module_path? If the tool returns module objects from get_process_modules, the response should include a 'module_name' field for direct passthrough.