MCP client as a new subproject

[kubinio123]

DONE:

• existing code moved to server project
• protocol model moved to core project
• • json schema of MCP latest version is committed, sourced from https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/schema/2025-11-25
• • unit tests validate scala model against the schema
• new client project
• client and server conformance projects
• • runs https://github.com/modelcontextprotocol/conformance

CODE WISE:

• McpClient interface defines possible interactions client side
• McpClientImpl actual client implementation
• Transport[F[_]] main abstraction
• • StdioTransport a library default implementation for stdio, backend agnostic
• • StreamingStdioTransport for backend specific implementations (coming soon) like ZIO, Future, ox or other runtimes
• • HttpTransport a library default implementation for non streaming sttp backends
• • StreamingHttpTransport for backend specific implementations (coming soon); note: some MCP client features require streaming

I am not yet certain of correctness of those abstractions especially streaming ones. I would rather see them as extensions to base StdioTransport and HttpTransport instead. But I think I will get there once implementing a first streaming one soon.

Created a new GH label tier:2 SDK that I will use to flag followup issues when creating a issues "roadmap" for chimp.
Tiers are described here - https://modelcontextprotocol.io/community/sdk-tiers.

[adamw]

maybe the examples should live in a different package, to also show what imports you need

[kubinio123]

Yes, updating 👍

[adamw]

Review by my Claude review agents:

  Findings

  Critical

  - Transport abstraction conflates message-pipe with request/response correlation (client/transport/Transport.scala:8). send(msg): F[Option[JSONRPCMessage]] forces every transport to do correlation: StdioTransport does it via pending +
  SynchronousQueue; HttpTransport only works because the JSON-RPC reply happens to be the HTTP body; both Streaming* traits don't specify how this works. This is also why HttpTransport.onIncoming is a no-op (HttpTransport.scala:70) —
  server-initiated requests over HTTP are impossible today. Correlation should live in McpClientImpl; Transport should just be send: F[Unit] + onIncoming. The author's own uncertainty about streaming flows directly from this.
  - StdioTransport.send blocks indefinitely on q.take() (StdioTransport.scala:102) with no timeout and no cancellation. close() does not unblock waiters: drainPending() only runs when the reader loop ends, and readerThread.interrupt() won't
  interrupt a BufferedReader.readLine() blocked on the pipe (StdioTransport.scala:116-125). To force EOF, close() must also close proc.getInputStream (and ideally drain pending directly).
  - Malformed Accept header in HttpTransport (HttpTransport.scala:30): s"…${MediaType.TextEventStream.toString()}}" — stray trailing }. Some servers will reject the media-type list.

  Warnings

  - Server-notification listener exceptions are silently swallowed (McpClientImpl.scala:103) — at least log them.
  - installIncoming() discards the F effect at construction (McpClientImpl.scala:72); only works because the current transports' onIncoming is eager. Either return F[McpClient[F]] or document the requirement.
  - notificationListeners grows unboundedly with no deregistration (McpClientImpl.scala:194).
  - HttpTransport.scala:27 uses a local var request for an optional header — fold into the builder.

  Suggestions

  - Once correlation moves out of the transport, most of the AtomicReferences in McpClientImpl can go too.
  - serverCapabilities: Option[...] returning state from an AtomicReference is an API smell; the value is also returned from initialize().

[adamw]

so we support only two scenarios?

[kubinio123]

I think the implementation would support few more already especially auth/* related, they just require some implementation in this file. I didn't want to make the scope of single PR too large.

[adamw]

Ok, so currently we do support 2 scenarios, and that's expected :)

[adamw]

what happened to batch requests?

[kubinio123]

They aren't included anymore in latest spec version. They were there two versions ago (in version 2025-03-26). I thought let's code against the latest spec if we are doing a general rework of the project.

[adamw]

Ah of course, let's remove then

[kubinio123]

I've pushed some updates, from the claude review I addressed the ones that doesn't affect Transport as I am currently reworking that on a separate branch as part of #140.

[adamw]

Great, let's merge, one thing that we might want to do in this PR or a seaprate one before releasing - update the main README :)

[kubinio123]

Yep, I will make sure README is up to date before next release. Merging ✅