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 adjusts the `Request`/`Response` types to have an `id` that is
either a string or a number.
* Merges 'Error' into 'Response' to have a single response type that
represents both errors and results.
* Adjusts the `Error.data` field to by any JSON value.
* Adds `operator==` support to the base protocol types and simplifies
the tests.
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.
