Thanks for the suggestion!

The schema is correct in this case—we want to require all capabilities to be objects, because this gives flexibility in declaring different degrees of conformance. For example, with one of the standardized capabilities right now:

{
  "resources": {}
}

… means only "resources are supported, but no additional optional features on resources."

OTOH this:

{
  "resources": {
    "subscribe": true
  }
}

… means "resources are supported, and you can subscribe to changes on individual resources."

We want to encourage the same structure inside of experimental, with the idea that maybe sub-objects there could graduate into standardized, top-level capabilities later on.

Hope this clarifies things! It sounds like there is an issue in the Python example that we should fix, but the spec seems correct here. 🙂

I see, thanks for the clarification! That comment in the source code was the only documentation I could find about experimental capabilities, so it wasn't clear to me whether this was a bug or a feature.