* Allow decoding Decodable type directly from Value
Summary: I noticed we are not converting value associated with response to the strong types requests recorded
This change will help to decode the value type later once we support the rest of plumbing (next commit)
* Store and pass original request when response arrives
Summary: Looks like there were multiple issues with parsing response:
1. It appears that we would mistakenly pass response both for response and request arguments in the private func handleResponse(_ response: Response<AnyMethod>, for request: Any)
2. Later I couldn't figure out how to win against swift type system, so ended up creating a type-erased request to store in the pendingRequests instead of original type under Any (that wouldn't allow to downcast original type later)
Test Plan:
1. Standup iMCP client from https://github.com/loopwork-ai/iMCP
2. Create a dummy project setting up MCP client against "/private/var/folders/26/8gncz37x7slbfrr95d9jcr400000gn/T/AppTranslocation/62ADEC4D-3545-4E98-A612-0E6DF52CE525/d/iMCP.app/Contents/MacOS/imcp-server" and call initialize
Note response is being parsed correctly and client.initialize() does not hang indefinitely
* Fix warning: 'Cast from Client.AnyPendingRequest to unrelated type Client.PendingRequest<Any> always fails'
* Fix warning: 'Conditional cast from NWError to NWError always succeeds'
* Uncomment code in RoundtripTests
* Formatting
* Reorganize declarations
* Inline JSONDecoder extension
* Expand roundtrip tests
---------
Co-authored-by: Sash Zats sash@zats.io <>
Co-authored-by: Mattt Zmuda <mattt@loopwork.com>
Changes AsyncStream to AsyncThrowingStream to ensure network errors are correctly propagated to callers. Updates receive() to handle errors from the underlying message stream.
Adds a Configuration struct to control server behavior around client initialization.
When strict mode is enabled, server enforces MCP spec requiring clients to initialize
before sending requests. Default mode is more permissive for non-compliant clients.
