feat: add client capability schema

[olaservo]

Summary

Adds a JSON Schema for MCP client capabilities, providing a formal structure for documenting what features each client supports.

Closes #718

Acknowledgments

This schema builds on the work done by @jancurn in mcp-client-capabilities, which established the core capability structure and has catalogued 40+ clients. This PR extends that foundation with additional fields for transports, platforms, authentication, and metadata.

Changes

• docs/schemas/client-registry.json - JSON Schema definition

What's Included

This PR focuses solely on the schema definition. Intentionally not included:

• Client data - The mcp-client-capabilities repo already has the data. Once the schema is agreed upon, that data can be migrated.
• Validation scripts - Can be added in a follow-up PR once the schema is finalized.

Schema Overview

The schema tracks BOTH what clients declare to servers (sampling, elicitation, roots) AND which server capabilities clients can consume (tools, resources, prompts). This is intentionally broader than the MCP spec's ClientCapabilities interface.

Minimal entry:

{
  "my-client": {
    "title": "My Client",
    "url": "https://example.com",
    "protocolVersion": "2025-11-25"
  }
}

Full entry:

{
  "my-advanced-client": {
    "title": "My Advanced Client",
    "url": "https://example.com",
    "protocolVersion": "2025-11-25",
    "category": "cli",
    "platforms": ["windows", "macos", "linux"],
    "transports": { "stdio": {}, "streamableHttp": {} },
    "authentication": {
      "oauth": {
        "pkce": true,
        "dynamicRegistration": true,
        "clientIdMetadataDocument": true,
        "grantTypes": ["authorization_code", "refresh_token"]
      },
      "header": {}
    },
    "tools": { "listChanged": true },
    "resources": { "listChanged": true, "subscribe": true },
    "prompts": { "listChanged": true },
    "sampling": { "context": {}, "tools": {} },
    "elicitation": { "form": {}, "url": {} },
    "roots": { "listChanged": true },
    "completions": {},
    "logging": {},
    "tasks": {
      "list": {},
      "cancel": {},
      "requests": { "sampling": { "createMessage": {} } }
    },
    "metadata": {
      "vendor": "Some Vendor",
      "openSource": true,
      "lastVerified": "2026-01-17"
    }
  }
}

Features

Feature	Description
Capabilities	tools, resources, prompts, sampling, elicitation, roots, completions, logging, instructions, tasks
Status values	{} (supported), or { "status": "full|partial|unsupported|untested", "notes": "..." }
Categories	ide, chat, cli, automation, browser-extension, library, other
Platforms	windows, macos, linux, web, ios, android
Transports	stdio, sse, streamableHttp
Auth	oauth (with PKCE, dynamicRegistration, clientIdMetadataDocument, grantTypes), header, none
Metadata	vendor, openSource, sourceUrl, license, lastVerified, conformanceScore

Related

• modelcontextprotocol#1814 - Client compatibility matrix
• mcp-client-capabilities - Community client data

---

🦉 Generated with Claude Code and reviewed by me

[thoorp]

How about a section for security - CIMD, DCR, etc?

[olaservo]

How about a section for security - CIMD, DCR, etc?

@thoorp CIMD and DCR are specifically OAuth client registration methods, so I was thinking keeping them under authentication.oauth makes more sense semantically? I could see there being a security section making sense if we wanted to go deeper on other capabilities outside of oauth, is that what you were thinking?

[thoorp]

How about a section for security - CIMD, DCR, etc?

@thoorp CIMD and DCR are specifically OAuth client registration methods, so I was thinking keeping them under authentication.oauth makes more sense semantically? I could see there being a security section making sense if we wanted to go deeper on other capabilities outside of oauth, is that what you were thinking?

Sure. You may want to add it to the fully entry/example.

[olaservo]

How about a section for security - CIMD, DCR, etc?

@thoorp CIMD and DCR are specifically OAuth client registration methods, so I was thinking keeping them under authentication.oauth makes more sense semantically? I could see there being a security section making sense if we wanted to go deeper on other capabilities outside of oauth, is that what you were thinking?

Sure. You may want to add it to the fully entry/example.

@thoorp good call, added!