Review library for protocol completeness

[eiriktsarpalis]

We should conduct a review checking that all facets of the MCP specification are being implemented by this library.

Known issues

• Logging is not implemented. It's an optional utility capability (server to client). Configuration should be added on the client side to easily integrate with logging. Very few users will want to actually implement a client-side handler for this. Server side configuration could also be added to integrate directly with a logger. I am not sure the protocol model matches logging extensions, so might need to make the mapping configurable (nice-to-have).
• Authorization (also optional) is also not implemented, but I am not sure any MCP SDK implements that fully according to spec, and most don't at all.
• There are also some request / response schemas which support free-form _meta / additional properties patterns not implemented. Some of these are not particularly pleasant outside weakly typed languages, so in the local branch where I'm doing such a completeness pass I'm considering just using JsonElement for them. Not sure what the best way to support these is - will find some examples later.
• Notification capability flags are not enforced server side. Servers must not send notifications to clients that are not declared in capabilities. This is currently possible to do as a server author.

[PederHP]

Logging is not implemented. It's an optional utility capability (server to client). Authorization (also optional) is also not implemented, but I am not sure any MCP SDK implements that fully according to spec, and most don't at all.

There are also some request / response schemas which support free-form _meta / additional properties patterns not implemented. Some of these are not particularly pleasant outside weakly typed languages, so in the local branch where I'm doing such a completeness pass I'm considering just using JsonElement for them. Not sure what the best way to support these is - will find some examples later.

[eiriktsarpalis]

Thanks Peder, I've transcribed your points into checkboxes in my OP. Feel free to edit my post to modify/append as appropriate.

[PederHP]

Added additional comments about logging to the OP.

[stephentoub]

Is support for subscring to and unsubscribing from resources implemented? I see the delegates, but I'm not clear on when those are invoked.

[PederHP]

Is support for subscring to and unsubscribing from resources implemented? I see the delegates, but I'm not clear on when those are invoked.

It is supported on a protocol level, but implementing the logic is currently up to the user. I think a convenience programming model which encapsulates a resource collection and wraps the list / get logic of that capability could also handle this on the server side.

So I'd say in terms of protocol completeness: yes - but in terms of library/SDK completeness: no.

(And I realize that what I call convenience is what many, if not most, others consider core SDK functionality. But the raw MCP implementation is there, so a library user could handle these whether client or server, with the current support. They'd just be on their own, but that's also the case for implementing list / get. But I do agree that such functionality should be added, but that it should also be possible to hook directly into the protocol and provide a custom implementation if one wants to do that.)

[stephentoub]

It is supported on a protocol level

I'm missing even that part. McpServer has the delegates, but what invokes then? Are they supposed to be hooked up to some incoming notification/request?

[PederHP]

It is supported on a protocol level

I'm missing even that part. McpServer has the delegates, but what invokes then? Are they supposed to be hooked up to some incoming notification/request?

I'll add integration tests. If I missed something, I'll find out, and add it. But I think it should be there - it's just a handler, there's no logic - nothing on the server which invokes, as the subscription is initiated by the client.

It's up to the implementation of the server (ie library user) to store the subscriptions and to send notification events. Likewise, it's up to the client when to create subscriptions and how to handle notification events.

This is where the resource wrapper will be handy. The vast majority of users would just want a collection of resources and to have built-in subscription, list, list change and get functionality, and not provide custom handlers.

[PederHP]

Yeah, there's a bug in the SubcribeToResources and UnsubscribeToResources implementation. I am fixing it now. The types are not right. I'll have a PR with a fix before long.

Edit: #89 fixes the issues (there was also a handler registration issue).