GetMCP targets the Model Context Protocol specification revision 2025-11-25 with negotiation back to 2025-06-18. This page is the authoritative answer to “does GetMCP support X?” — broken down by spec section.
The transport is Streamable HTTP (with an outbound message queue for server-initiated traffic). The legacy plain-SSE transport has been deprecated by the MCP spec and is intentionally not implemented — Streamable HTTP supersedes it. stdio isn’t supported as of now (it’s mostly relevant for locally-spawned subprocesses, which doesn’t fit the WordPress hosting model).
Legend
| Symbol | Meaning |
|---|
| ✅ | Fully implemented per spec |
| 🟡 | Partial — handler exists, but the server doesn’t yet emit it from internal events (e.g. a long-running tool won’t auto-fire progress; the emitter is callable from a custom hook) |
| ⚪ | Not implemented |
Lifecycle
| Method | Direction | Status | Notes |
|---|
initialize | Client → Server | ✅ | Protocol negotiation, capability declaration, server info |
notifications/initialized | Client → Server | ✅ | Acknowledges initialization complete |
ping | Either | ✅ | Round-trip health check |
| Method | Direction | Status | Notes |
|---|
tools/list | Client → Server | ✅ | Paginated; supports cursor continuation |
tools/call | Client → Server | ✅ | JSON Schema validation, parameter mapping, response transforms, per-tool rate limits |
notifications/tools/list_changed | Server → Client | ⚪ | Server-side tool config changes don’t auto-notify connected clients yet |
Resources
| Method | Direction | Status | Notes |
|---|
resources/list | Client → Server | ✅ | Paginated |
resources/templates/list | Client → Server | ✅ | URI templates for parameterised resources |
resources/read | Client → Server | ✅ | MIME-typed responses |
resources/subscribe | Client → Server | ✅ | Subscribes a session to URI-change notifications |
resources/unsubscribe | Client → Server | ✅ | Cancels a subscription |
notifications/resources/list_changed | Server → Client | ⚪ | Not emitted yet |
notifications/resources/updated | Server → Client | ⚪ | Not emitted yet |
Prompts
| Method | Direction | Status | Notes |
|---|
prompts/list | Client → Server | ✅ | Paginated |
prompts/get | Client → Server | ✅ | Renders parameterised template |
notifications/prompts/list_changed | Server → Client | ⚪ | Not emitted yet |
Sampling
| Method | Direction | Status | Notes |
|---|
sampling/createMessage | Server → Client | ✅ | Server can ask the client model for a completion (subject to client’s sampling capability) |
Logging
| Method | Direction | Status | Notes |
|---|
logging/setLevel | Client → Server | ✅ | Per-session log filter |
notifications/message | Server → Client | 🟡 | Emitter API is callable — see Server Logging Notifications. Existing tool calls don’t auto-emit; available via the getmcp_log_message_emit hook |
Completion
| Method | Direction | Status | Notes |
|---|
completion/complete | Client → Server | ✅ | Argument autocomplete for prompt + resource template parameters |
Progress & Cancellation
| Method | Direction | Status | Notes |
|---|
notifications/progress | Server → Client | 🟡 | Emitter API in place; built-in ToolExecutor is synchronous and doesn’t emit progress mid-run. See Progress Notifications |
notifications/cancelled | Client → Server | 🟡 | Handler accepts the cancel flag; the synchronous executor doesn’t poll it. See Cancellation Notifications |
Roots
| Method | Direction | Status | Notes |
|---|
roots/list | Server → Client | ✅ | Server can request the client’s local filesystem roots. See Roots List |
notifications/roots/list_changed | Client → Server | ✅ | Client signals the user changed their roots; server invalidates its cached copy |
Elicitation
| Method | Direction | Status | Notes |
|---|
elicitation/create | Server → Client | ✅ | Server can ask the client for typed user input mid-tool. See Elicitation |
Outbound Message Queue
The Streamable HTTP transport doesn’t yet open a long-poll SSE channel for server-initiated traffic. Instead, GetMCP buffers server-initiated messages (roots/list requests, progress notifications, log messages, elicitation requests) in a per-session transient queue and piggy-backs them onto the next HTTP response as a JSON-RPC batch.
So if you issue a tools/call, the response body may contain:
[
{ "jsonrpc": "2.0", "id": 7, "result": { "content": [...] } },
{ "jsonrpc": "2.0", "method": "notifications/progress", "params": { ... } },
{ "jsonrpc": "2.0", "id": "srv-12", "method": "roots/list", "params": {} }
]
Not Implemented
The following spec methods have no handler today:
notifications/tools/list_changednotifications/resources/list_changednotifications/resources/updatednotifications/prompts/list_changed
These are all “the server changed; come refresh” notifications. Clients re-list on their own cadence in practice, so this hasn’t been a blocker. Open a discussion at github.com/InfiWebs/getmcp if you need them prioritised.
The MCP specification is evolving rapidly. GetMCP’s protocol version is set in includes/transport/class-streamable-http.php and pinned to the spec revision it was tested against — initialize will negotiate down for older clients.
