Skip to content

allow initialization after unsupported mcp discovery - #1458

Merged
RhysSullivan merged 4 commits into
UsefulSoftwareCo:mainfrom
tylergibbs1:agent/mcp-discover-fallback
Aug 28, 2026
Merged

allow initialization after unsupported mcp discovery#1458
RhysSullivan merged 4 commits into
UsefulSoftwareCo:mainfrom
tylergibbs1:agent/mcp-discover-fallback

Conversation

@tylergibbs1

Copy link
Copy Markdown

fixes #1449

executor mcp forwarded server/discover to the local streamable http endpoint before a session existed. the endpoint returned -32000 Server not initialized, and the stdio bridge closed before clients could fall back to initialize.

the bridge now answers that one unsupported pre-initialize method with -32601 Method not found. all other messages still pass through to the daemon, and requests after initialization are unchanged.

the raw stdio integration test sends discovery, initializes on the same connection, lists execute, and calls it successfully.

validation

  • bun run format:check
  • bun run lint
  • bun run typecheck
  • bun run test

tylergibbs1 and others added 4 commits July 24, 2026 01:00
Only initialize can open a session, so the streamable-HTTP transport
rejected every other pre-session method with HTTP 400 + -32000 Server not
initialized. Clients read that 400 as a transport failure and dropped the
connection, so a client opening with an optional server/discover probe
never got to fall back to initialize; over `executor mcp` it closed the
bridge outright.

Pre-session dispatch now answers any method other than initialize with
-32601 Method not found on a 200. Done in the shared host-mcp package and
wired into both session-creating sites, so the CLI bridge needs no shim.
The guard intercepted any POST body whose method was not initialize. That
answered 200 before the streamable-HTTP transport could run its own checks,
so a POST with a wrong Content-Type or an incomplete Accept got a success
instead of the transport 415/406, and a structurally invalid JSON-RPC
message (a fractional id, a non-object params, an unknown top-level field)
got -32601 instead of the transport parse error.

It now fires only where -32601 is the whole story: a POST that clears the
transport content negotiation and carries a valid JSON-RPC 2.0 request.
Validity comes from the SDK isJSONRPCRequest predicate, the same one behind
the transport JSONRPCMessageSchema.parse, so the two cannot drift.

Tests cover the real caller paths: the in-memory session store and the local
app handler both answer -32601 for a valid probe, and pass a notification, a
malformed id, a wrong Content-Type, and an incomplete Accept to the
transport.
@RhysSullivan
RhysSullivan merged commit 1908dd6 into UsefulSoftwareCo:main Aug 28, 2026
75 of 76 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MCP protocol: handle 'server/discover' before 'initialize'

2 participants