Add Debugger MCP - #1211
Add Debugger MCP#1211UvuvDev wants to merge 6 commits into
Conversation
|
One of the other issues I'm considering is when agents call tools/list (which for some reason, 5.5 Luna did 15 times), the more tools we list the more tokens we waste. So I am not sure about how to include certain functionality. At the moment I think we are at about 12,000 tokens per list call. Adding the TTD, GDB reverse, etc would add around 40,000 tokens to that, which I would like not to do. My best solution I can think of is abstracting the non-core steps (things that aren't step, register read, etc.) behind subcommands, and doing a tree of commands. If it only hits the TTD branch .1% of the time, then we don't need to show it every time. We would have to benchmark this against different workflows to see if this is actually cheaper though, because maybe the AI starts calling tools/list 5x more often or something. |
…workaround to not have to statically link Debugger and MCP togetherx
…n attach and connect now
This reverts the 4-commit RPC-over-loopback-socket prototype (rpc_server.py and its tests). It was always a workaround for not being able to statically link the debugger plugin's tools into Binary Ninja's MCP server; now that core exposes a plugin API for registering MCP tools in-process, the RPC server, its auth token file, and its discovery file are unnecessary. The reverted commits stay in history for reference; the new implementation follows in subsequent commits. This reverts commits 71aed25, 1520176, 6c17725, and c0eb781.
1 participant
Adds a debugger MCP. I would like some discussion quality wise, as I am still kind of unsure about the way I set this up. I made a quick RPC server that connects to the MCP, so we are going like this:
The reason for this is that the bundled MCP is compiled into the core of Binary Ninja. Making a custom build of the debugger or not including the debugger would then crash Binary Ninja. So the way I see it, there is 2 possible solutions:
I'm not actually sure which one would be better. Currently, all of my code is written for 1, as it is what I thought of first. Functionality wise it works quite well. I can successfully one shot things on crackmes.one. I am open to restarting this with 2 if we decide it makes more sense.