Spec compliance issues

[stallent]

@mattt I'm finding more and more details that are not matching the spec. Again, if this framework is both sides of the equation it works just fine, but starts failing in more and more places when hitting other MCP servers that are spec compliant. Current example... MCP's Server.Capabilities.Resources.list is required to exist in the models and without it the client will no ask a server for its resources. yet that property is not part of the spec. That means we cannot call any other MCPServer's resources because none are sending this. Here is the spec's ServerCapabilities "resources" definition

"resources": {
     "description": "Present if the server offers any resources to read.",
     "properties": {
          "listChanged": {
               "description": "Whether this server supports notifications for changes to the resource list.",
                "type": "boolean"
           },
          "subscribe": {
                   "description": "Whether this server supports subscribing to resource updates.",
                     "type": "boolean"
            }
       },
       "type": "object"
},

So I guess my question is more related to if your intention is for this framework to be primarily used when on both sides of the client and server. 100% fine but helps me decide the path I may take.

Thanks!

[stallent]

Just to clarify, its not that i'm being a spec pedant, its the client simply won't work with any servers not using this framework (which is all of them. lol)

[mattt]

Hi @stallent. This library came out of our work on iMCP, and its current state reflects the requirements of that app. But our intention is to build a full, spec-compliant implementation of MCP. I appreciate your patience as we work towards that.

I just opened #15, which addresses what I understand to be the problem from this issue. To restate the problem you're describing, which is twofold:

1. The current implementation of Server.Capabilities.Resources defines nonstandard read and list capabilities.
2. The current implementation of Client.listResources and Client.readResources include a specific check for that capability. This causes requests to fail because servers won't include that capability.

[mattt]

This is now resolved in version 0.4.0.

[stallent]

Thank you!! And we are using this thing pretty deeply now so i pre-apologize if wear you out. lol. Fair warning... an issue about SSE support will be opened soon... (we already are using it with our own transport but since its part of spec i wonder about built in support for it vs the diy network transport that is there at the moment)

[mattt]

It looks like HTTP+SSE is soon to be replaced: modelcontextprotocol/modelcontextprotocol#206. I had hesitations about HTTP+SSE, but think this streamable HTTP looks nice.

[stallent]

@mattt excellent. i hadn't see that post yet. fwiw the SSE implementation was thankfully super easy so we aren't blocked at all while we wait for the streamable HTTP. Also, happy to help as any of these items are ready to be tackled.