Should there be an MCP server to enable control of the Dart debugger?

[gspencergoog]

It seems like often the LLM ends up conjecturing about what is happening in the code and going in circles just because it's conjecture is just wrong. Allowing it to step through running code with the debugger could be really helpful as another tool it could use to see what the stack and context is at a certain point.

Not sure what the tool interface would look like, but it probably would need some thought to make it so the LLM can figure out how to use it.

It should probably be able to:

• Set breakpoints, even conditional ones.
• Control execution with pause, run, step over, step into, step out, return.
• Print variable values
• Get the stack
• Get the current state (running, stopped).

Perhaps this is a separate "Debugging" MCP server to keep from adding too many tools to the existing Dart MCP server.

[jakemac53]

It would be nice to leverage the debug adapter protocol and a generic MCP server that works with that. For example I just found this one dap-mcp MCP Server https://share.google/wOixhNyr0YeoRqE3M

[gspencergoog]

Oh, cool, does the Dart debugger already speak the debug adaptor protocol?

[jakemac53]

cc @DanTup might know the answer to that

[jakemac53]

Fwiw I think the general idea with DAP is that you slot an adapter between the actual debugger and the thing that wants to speak DAP. So we would need a dart debugger -> DAP adapter.

[DanTup]

Oh, cool, does the Dart debugger already speak the debug adaptor protocol?

Yeah, we have DAP implementations ("Debug Adapters") that sit in front of the VM Service (the dart debug_adapter and flutter debug_adapter commands). These are what VS Code uses (Dart-Code just helps VS Code start them and build the launch/attach request config).

I'm not sure whether it would make more sense here for the editor (eg. VS Code) to expose debugging tools to the model, or whether we the model should just be able to run the whole debug adapter. The first would be more visible to the user (which may or may not be good), but it would also need to be work done by each editor (I had a look but couldn't find any issues in the VS Code tracker about this).

I don't know how well an LLM would be able to drive DAP directly though - there are a lot of requests and it's quite a complex protocol. It might work better with a simpler API over the top of it, but perhaps it's something that would be worth testing.