MCP: Expose Debugger and Runtime Patching

What is the feature you'd like to have?
Please provide a clear and concise description of what you want.

I would like the integrated Binary Ninja MCP server to expose the existing Debugger functionality directly through MCP.

This should allow an LLM/agent to:

• Attach to or launch a process
• Continue, pause and step execution
• Read registers and memory
• Add/remove software and hardware breakpoints
• Receive breakpoint/debugger events
• Write process memory for runtime/memory patching
• Apply and test runtime patches

The goal is to control these capabilities through native MCP tools, without requiring a separate MCP server or Python API as an intermediate layer.

Is your feature request related to a problem?
If applicable, please provide a clear and concise description of what the problem is.

MCP currently provides extensive static analysis capabilities, but an LLM cannot directly interact with the running process through the Binary Ninja Debugger.

For example, an agent can identify an interesting instruction during static analysis, but cannot then set a hardware breakpoint, continue execution, inspect the registers/memory when it hits, or modify the running process to test a hypothesis.

A typical workflow would be:

"Static analysis → breakpoint → continue → inspect runtime state → patch/test → continue analysis"

Are any alternative solutions acceptable?
Please provide a clear and concise description of any alternative solutions or features you've considered.

The preferred solution is to expose the existing Debugger and runtime functionality as native MCP tools.

A separate debugger MCP server would technically be an alternative, but using the integrated Binary Ninja MCP server would provide a much cleaner workflow and keep static analysis and debugging in the same Binary Ninja session.

Additional Information:
Please add any other context or screenshots that would help us understand your feature request here.

It would be useful to support both:

• Binary patching – modifying the analyzed binary
• Memory/runtime patching – modifying a running process

Hardware breakpoints are particularly useful for this workflow.

Windows Time Travel Debugging would also be interesting to expose through MCP where supported, but is not required for the initial implementation.

The exact MCP tool design is open for discussion; the main requirement is that the existing Binary Ninja Debugger can be fully controlled through MCP.

Start by reviewing the integrated Binary Ninja MCP server and the existing Debugger functionality to map the requested capabilities and session boundaries. Define the native MCP tool design and verify that it supports process attach or launch, execution control, state inspection, breakpoints, events, and binary or runtime patching without a separate server.