Three small protocol methods/notifications we're missing that round out basic MCP support. Grouped because they're each small on their own.
1. `ping`
Trivial bidirectional keepalive. Clients use it to detect dead connections.
```json
// request
{"jsonrpc": "2.0", "id": 1, "method": "ping"}
// response
{"jsonrpc": "2.0", "id": 1, "result": {}}
```
Handler is one cond branch in `mcp-server--handle-message`. The server should also be able to send pings to the client, though that can be deferred.
2. `logging/setLevel` + `notifications/message`
Lets the client set a log level on the server, and receive server-emitted log messages as notifications. Would replace / complement our current `mcp-server--debug` which only goes to `Messages`.
- Add `logging` capability to the initialize response
- Handle `logging/setLevel` to store client-requested level
- Route `mcp-server--debug` / `--info` / `--error` through a function that emits `notifications/message` to connected clients when their level allows it (in addition to the existing `Messages` output)
Useful for end users debugging integration issues without having to enable debug mode in Emacs.
3. `notifications/progress`
For long-running tool calls. Client passes a `_meta.progressToken` in the request; server can emit progress notifications referencing that token.
```json
{
"jsonrpc": "2.0",
"method": "notifications/progress",
"params": {
"progressToken": "abc123",
"progress": 0.5,
"total": 1.0,
"message": "scanning buffer 50/100"
}
}
```
Ties into the blocking/worker discussion. Progress doesn't un-block Emacs, but at least tells the client the tool is still working instead of hung. Mostly useful for `eval-elisp` on expensive expressions and future long-running tools.
Server side: expose a function like `mcp-server-progress-notify` that tool handlers can call, looking up the progress token from the current request context. Requires tracking the current request during tool execution.
Acceptance
Each can ship independently:
Three small protocol methods/notifications we're missing that round out basic MCP support. Grouped because they're each small on their own.
1. `ping`
Trivial bidirectional keepalive. Clients use it to detect dead connections.
```json
// request
{"jsonrpc": "2.0", "id": 1, "method": "ping"}
// response
{"jsonrpc": "2.0", "id": 1, "result": {}}
```
Handler is one cond branch in `mcp-server--handle-message`. The server should also be able to send pings to the client, though that can be deferred.
2. `logging/setLevel` + `notifications/message`
Lets the client set a log level on the server, and receive server-emitted log messages as notifications. Would replace / complement our current `mcp-server--debug` which only goes to `Messages`.
Useful for end users debugging integration issues without having to enable debug mode in Emacs.
3. `notifications/progress`
For long-running tool calls. Client passes a `_meta.progressToken` in the request; server can emit progress notifications referencing that token.
```json
{
"jsonrpc": "2.0",
"method": "notifications/progress",
"params": {
"progressToken": "abc123",
"progress": 0.5,
"total": 1.0,
"message": "scanning buffer 50/100"
}
}
```
Ties into the blocking/worker discussion. Progress doesn't un-block Emacs, but at least tells the client the tool is still working instead of hung. Mostly useful for `eval-elisp` on expensive expressions and future long-running tools.
Server side: expose a function like `mcp-server-progress-notify` that tool handlers can call, looking up the progress token from the current request context. Requires tracking the current request during tool execution.
Acceptance
Each can ship independently: