Fix client parsing

[zats]

This addressed issue #7, tldr looks like client had no way of parsing response due to

1. Response arriving as a Value instead of strong type associated with request
2. Request casting to <Any> seem to constantly fail for me, introducing type-erased wrapper seem to fix it for me

There is a good chance I am not aware of the original thinking and missing something obvious to make it work 🙂

Original Issue Description:

I will prephrase my question by saying I am not sure at all that any of my findings are accurate.
I think I am seeing consistent failure of the client to handle responses due to 2 issues:

First of all it appears that we are passing response twice under

https://github.com/loopwork-ai/mcp-swift-sdk/blob/main/Sources/MCP/Client/Client.swift#L132-L133

Where instead we should be getting appropriate request from pandingRequests like so

if let response = try? decoder.decode(AnyResponse.self, from: data), let request = pendingRequests[response.id] {
  await handleResponse(response, for: request)
} ... 

Even fixing that locally downcast here https://github.com/loopwork-ai/mcp-swift-sdk/blob/main/Sources/MCP/Client/Client.swift#L329 fails

guard let typedRequest = request as? PendingRequest<Any> else { return }

Not sure if there is a way to tell Swift "don't worry about generic the original value was created with", it seem to consistently fail. Specifically I am debugging initialize sequence and so when I fix passing pending request, $ po request prints MCP.Client.PendingRequest<MCP.Initialize.Result>) , tho guard let typedRequest = request as? PendingRequest<Any> else { return } fails

Any ideas if I am holding it wrong? or we might need to store type-erased pending requests instead of Any?

[stallent]

Just so you don't feel alone... I just now ran into the same thing and trying to discern the best resolution

[stallent]

@zats and can confirm your branch fixes it. Again, no clue if it adheres to matttttttt's intentions but it most certainly unblocks me. Thank you!

[zats]

ay thanks Stephen, glad it works for you 🙂

[leoshimo]

Ran into the same issue + patched in a similar way!
I should've checked open issues / PRs first - thanks for the fix.

[stallent]

I no longer think this fix is correct. It appears to fix one thing and break another. Still trying to discern the intention....

[mattt]

Thanks again, @zats, for your help with this. And thanks to you, @stallent @leoshimo, for giving this a go and bearing with us.

@stallent Interesting! I'm also getting my head around these changes. What are you seeing now?

[stallent]

@mattt its related to using client.callTool. The tool is returning a successful response (Which works in the MCP Inspector), but its failing a typecast here during attempting to process the result:

private struct AnyPendingRequest {
private let _resume: (Result<Any, Swift.Error>) -> Void

init<T: Sendable & Decodable>(_ request: PendingRequest<T>) {
      _resume = { result in
          switch result {
          case .success(let value):
            if let typedValue = value as? T {

[stallent]

@mattt best i can tell with my bad eyes.. the spot i pointed to above, the .success(value) is an MCP.Value and in the pending request is expecting MCP.CallTool.Result

[zats]

hey folks, catching up on he conversation, thanks for digging depper
@mattt did I get it right you will take over the PR or can I contribute anything else?

[mattt]

@zats Yep! I'm very happy to take it from here. Will look closer at what @stallent is seeing. But overall, this is a substantial improvement, and I'm grateful for your contribution.

[mattt]

@stallent I just pushed 043ce65, which expands test coverage to include client-server round-tripping for listing tools and calling a tool. Does that match how you're using it? Or are the tests not exercising this correctly?

[stallent]

@mattt give me a few min to finish lunch and i'll pull and give it a go. and have more deets if its not.

[mattt]

@stallent No rush, I'm about to break for lunch myself. Since this seems to fix the issue reported in #8, I'll go ahead and merge it so we can cut a new patch release. If you see anything amiss, please open a new issue, and I'll get on fixing that ASAP.