feat(remote): log reverse-MCP initialize handshake + protocol versions - #77
Merged
Conversation
…sions #74/#75 revealed the agent DOES connect to the oab server but never calls tools/list. The stall is between connect and list — the inner MCP initialize handshake, which #75 deliberately left unlogged. Log it, since MCP requires the client to initialize right after connecting (it's not the agent's choice). - initialize: log the client's requested `protocolVersion` vs the version the server answered; flag a **PROTOCOL MISMATCH** (warn) when they differ — the suspected reason a connected agent aborts before tools/list. - notifications/initialized: log it (a notification, so it never reached the outcome match). Its presence means the handshake completed; its absence right after an initialize points at a rejected handshake. Logging only — no behaviour change. If the log confirms a version mismatch, the fix (echo the client's protocolVersion instead of the hardcoded 2024-11-05, + advertise tools.listChanged) is a follow-up. No local src-tauri build (dep tree OOMs this box, as with #74/#75); CI build-test covers the compile.
brettchien
added a commit
that referenced
this pull request
Aug 18, 2026
…lize (#79) Confirmed by the #77 log on a live management session: reverse-MCP initialize — PROTOCOL MISMATCH: client requested 2025-06-18, server answered 2024-11-05 The reverse-MCP `initialize` shim answered a hardcoded `2024-11-05`. The agent runtime requested `2025-06-18`; the downgrade is why it completed the handshake (sent `initialized`) yet never issued `tools/list` — so the management agent saw no oab tools. Echo the client's requested `protocolVersion` instead of pinning one. Our initialize is a thin shim over the already-initialized oab-mcp sidecar, and `tools/list`/`tools/call` are forwarded verbatim (the response shape is stable across these versions), so echoing is safe; fall back to `2024-11-05` only when the client omits a version. With this, the #77 log should read "client requested X, server answered X" (no mismatch) and `tools/list` should follow — confirming the fix on the live session. No local src-tauri build (dep tree OOMs this box); CI build-test covers the compile.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#74/#75 moved the "management sees no oab tools" symptom forward: the Activity log now shows the agent does connect to the oab server (
reverse-MCP — agent connected), but there's notools/listafter it. MCP requires the client to sendinitializeright after connecting (it's protocol-mandated, not the agent's choice), so the stall is in that inner handshake — which #75 deliberately left unlogged.What (logging only, no behaviour change)
protocolVersionvs the version the server answered, and flag aPROTOCOL MISMATCH(warn) when they differ. A mismatch is the leading hypothesis for why a connected agent aborts beforetools/list(the server currently answers a hardcoded2024-11-05).match). Its presence means the handshake completed; its absence right after an initialize points at a rejected handshake.Reading the result
initialize … client requested X, server answered X+initializedthen notools/list→ handshake fine, list problem elsewhere.initialize … PROTOCOL MISMATCHand noinitialized→ the agent rejected our handshake — the fix is to echo the client's version (follow-up).initializeat all after connect → the agent connected but never handshook (different bug).Follow-up (not in this PR)
If the log confirms a mismatch: echo the client's
protocolVersioninstead of the hardcoded2024-11-05, and advertisecapabilities.tools.listChanged.Verification
src-taurinot built locally (dep tree OOMs this box, as on #74/#75); CIbuild-testcovers the compile. Additive logging using patterns already in the file.🤖 Generated with Claude Code