This improves the flow by automatically connecting to an exisitng lldb
instance, if one is found.
Future improvements include:
* Launching a binary if an instance isn't detected.
* Multiplexing if multiple instances are detected.
This adjusts the ProtocolServer command to default to create a new
connection listening on `localhost:0` and adds a new `ServerMetadata`
details to `~/.lldb/mcp/lldb-<pid>.json` to record information about the
current MCP server.
This can be consumed by the lldb-mcp binary to establish a connection
from an LLM client.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Currently, the server keeps running until we call Stop from its dtor in
the static destruction chain. This is too late: the server should stop
when the plugin gets terminated.
This PR adopts JSONTransport in the MCP server implementation. It
required a slight change in design in the relationship between the two
server classes. Previously, these two had an "is-a" connection, while
now they have a "has-a" connection.
The "generic" protocol server in Protocol/MCP now operates using a
single connection (Transport). This matches the design in DAP where each
DAP instance has its own connection. The protocol server in Plugins
still supports multiple clients and creates a new server instance for
each connection.
I believe the new design makes sense in the long term (as proved by DAP)
and allows us to make the server stateful if we choose to do so. There's
no reason that multiple client support can't live in the generic
protocol library, but for now I kept it in ProtocolServerMCP to avoid
creating unnecessary abstractions.
This is a reland of #155034 but with significant changes to the tests.
The unit tests now test the generic server implementation, which matches
the original intent. This also means the test are now single threaded
and therefore fully deterministic using the MainLoop.
This PR adopts JSONTransport in the MCP server implementation. It
required a slight change in design in the relationship between the two
server classes. Previously, these two had an "is-a" connection, while
now they have a "has-a" connection.
The "generic" protocol server in Protocol/MCP now operates using a
single connection (Transport). This matches the design in DAP where each
DAP instance has its own connection. The protocol server in Plugins
still supports multiple clients and creates a new server instance for
each connection.
I believe the new design makes sense in the long term (as proved by DAP)
and allows us to make the server stateful if we choose to do so. There's
no reason that multiple client support can't live in the generic
protocol library, but for now I kept it in ProtocolServerMCP to avoid
creating unnecessary abstractions.
This is a continuation of #152188, which started splitting up the MCP
implementation into a generic implementation in Protocol/MCP that will
be shared between LLDB and lldb-mcp.
For now I kept all the networking code in the MCP server plugin. Once
the changes to JSONTransport land, we might be able to move more of it
into the Protocol library.
This moves all the generic MCP code into the new ProtocolMCP library so
it can be shared between the MCP implementation in LLDB (built on the
private API) and lldb-mcp (built on the public API).
This PR doesn't include the actual MCP server. The reason is that the
transport mechanism will be different between the LLDB implementation
(using sockets) and the lldb-mcp implementation (using stdio). The goal
s to abstract away that difference by making the server use
JSONTransport (again) but I'm saving that for a separate PR.
This PR moves the MCP protocol code into its own library
(`lldbProtocolMCP`) so the code can be shared between the
`ProtocolServerMCP` plugin in LLDB as well as `lldb-mcp`. The goal is to
do the same thing for DAP (which, for now, would be used exclusively
from `lldb-dap`).
To make it clear that it's neither part of the `lldb` nor the
`lldb_private` namespace, I created a new `lldb_protocol` namespace.
Depending on how much code would be reused by lldb-dap, we may move more
code into the protocol library.
Expose debuggers and target as resources through MCP. This has two
advantages:
1. Enables returning data in a structured way. Although tools can return
structured data with the latest revision of the protocol, we might not
be able to update before the majority of clients has adopted it.
2. Enables the user to specify a resource themselves, rather than
letting the model guess which debugger instance it should use.
This PR exposes a resource for debuggers and targets.
The following URI returns information about a given debugger instance:
```
lldb://debugger/<debugger id>
```
For example:
```
{
uri: "lldb://debugger/0"
mimeType: "application/json"
text: "{"debugger_id":0,"num_targets":2}"
}
```
The following URI returns information about a given target:
```
lldb://debugger/<debugger id>/target/<target id>
```
For example:
```
{
uri: "lldb://debugger/0/target/0"
mimeType: "application/json"
text: "{"arch":"arm64-apple-macosx26.0.0","debugger_id":0,"path":"/Users/jonas/llvm/build-ra/bin/count","target_id":0}"
}
```
Rather than having one MCP server per debugger, make the MCP server
global and pass a debugger id along with tool invocations that require
one. This PR also adds a second tool to list the available debuggers
with their targets so the model can decide which debugger instance to
use.
This PR adds an MCP (Model Context Protocol ) server to LLDB. For
motivation and background, please refer to the corresponding RFC:
https://discourse.llvm.org/t/rfc-adding-mcp-support-to-lldb/86798
I implemented this as a new kind of plugin. The idea is that we could
support multiple protocol servers (e.g. if we want to support DAP from
within LLDB). This also introduces a corresponding top-level command
(`protocol-server`) with two subcommands to `start` and `stop` the
server.
```
(lldb) protocol-server start MCP tcp://localhost:1234
MCP server started with connection listeners: connection://[::1]:1234, connection://[127.0.0.1]:1234
```
The MCP sever supports one tool (`lldb_command`) which executes a
command, but can easily be extended with more commands.
