Skip to content

chore: bump go-sdk to v1.8.0 and detect input validation failures as tool errors - #10019

Merged
k-anshul merged 1 commit into
mainfrom
anshul/bump-mcp-go-sdk
Oct 14, 2026
Merged

k-anshul merged 1 commit into
mainfrom
anshul/bump-mcp-go-sdk

Conversation

@k-anshul

Copy link
Copy Markdown
Member
  • Bumps github.com/modelcontextprotocol/go-sdk from v1.4.1 to v1.8.0. Split out of Add external MCP servers as mcp connectors with per-user OAuth #10009, which needs it for the external MCP client.
  • Since go-sdk v1.7, input schema validation failures are tool error results instead of invalid params protocol errors. isMCPInputValidationFailure detects both, so the retry for stringified tool arguments still runs. MCP clients now get these failures as tool errors.
  • From v1.6, the SDK no longer applies cross-origin protection by default. This is safe: the runtime endpoint only accepts bearer tokens, and the admin endpoint's cookie is SameSite=Lax with CORS that disallows credentials.

Checklist:

  • Covered by tests
  • Ran it and it works as intended
  • Reviewed the diff before requesting a review
  • Checked for unhandled edge cases
  • Linked the issues it closes
  • Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
  • Intend to cherry-pick into the release branch
  • I'm proud of this work!

Developed in collaboration with Claude Code

…s tool errors

Since go-sdk v1.7, input schema validation failures are tool error results, not protocol errors.
Without detecting them, the retry for stringified tool arguments never runs.
@k-anshul k-anshul self-assigned this Oct 14, 2026
@k-anshul
k-anshul merged commit 4de6b7b into main Oct 14, 2026
19 of 21 checks passed
@k-anshul
k-anshul deleted the anshul/bump-mcp-go-sdk branch October 14, 2026 13:47
nishantmonu51 added a commit that referenced this pull request Oct 21, 2026
…mp to v1.8.0 (#10039)

* fix: MCP requests no longer share an AI session after the go-sdk bump to v1.8.0

Since go-sdk v1.8.0, a stateless streamable HTTP handler neither reads nor sets the
Mcp-Session-Id header (SEP-2567), and ServerOptions.GetSessionID is not consulted.
Rill runs both its MCP servers stateless and keys AI sessions on that header, so after
#10019 every request to the runtime's /mcp endpoint created its own ai_sessions row,
and the admin service's unified MCP server stopped issuing session IDs, so it never
forwarded one to the runtime.

Issue and preserve the header in Rill's own HTTP middleware instead of relying on the
SDK: a request without a session ID gets a new one, and every response carries the
session ID it was served with, which MCP clients echo on subsequent requests. This does
not depend on the SDK's MCPGODEBUG=allowsessionsinstateless compatibility flag, which
is removed in v1.9.

Tests assert that all the requests of one client connection share one AI session, on
both the 2025 protocol versions (initialize handshake) and the 2026-07-28 version.

* fix: address review on MCP session IDs

- Retry the session lookup when the insert races with a concurrent request that addresses the same new session ID
- Return no server for non-POST MCP requests, so probes do not create AI sessions
- Reject malformed client-supplied session IDs in the middleware
- Export the header name and drop duplicate comments and a redundant guard
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.

2 participants