fix(mcp): align MCP client with mcp-go server protocol

[Mnehmos]

Related GitHub Issue

Closes: #4189

Description

This PR resolves an incompatibility between Roo Code's MCP client and mcp-go servers. The primary issue was a protocol mismatch where mcp-go expects the mcp-session-id in HTTP headers, while the older SDK version sent it as a query parameter, causing connection failures.

The solution involves two main changes:

1. SDK Upgrade: The @modelcontextprotocol/sdk dependency is updated from ^1.9.0 to ^1.12.1. This upgrade provides access to the modern StreamableHTTPClientTransport, which correctly handles session IDs in headers.
2. Transport Logic Refactor: The connection logic in src/services/mcp/McpHub.ts has been refactored. It now attempts to connect using StreamableHTTPClientTransport first. If that fails and the server was originally configured as sse, it gracefully falls back to the deprecated SSEClientTransport to maintain backward compatibility with older MCP servers.

Additionally, a persistent TypeScript type-narrowing error within the connection logic was resolved by refactoring the conditional if/else if block into a switch statement. This improves both type safety and code readability.

Test Procedure

1. Unit and Integration Tests: The existing test suite was run to ensure no regressions were introduced by the changes.
   • Run pnpm test from the src directory. All tests should pass.
2. Manual Verification:
   • Configure a mcp-go server in the MCP settings.
   • Start Roo Code and verify that it successfully connects to the mcp-go server. The server logs should show a successful connection, and its tools should be available in the Roo Code interface.
   • Configure an older, SSE-based MCP server.
   • Verify that Roo Code successfully connects using the SSE fallback mechanism.

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (pnpm lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (pnpm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

N/A - This is a non-visual, backend change.

Documentation Updates

• No documentation updates are required.

Additional Notes

This change significantly improves the reliability of MCP connections and aligns Roo Code with the latest version of the Model Context Protocol.

Get in Touch

Mnehmos

<!-- ELLIPSIS_HIDDEN -->

----

> [!IMPORTANT]
> Fix protocol mismatch by updating SDK and refactoring transport logic in `McpHub.ts`.
> 
>   - **Behavior**:
>     - Update `@modelcontextprotocol/sdk` in `package.json` from `^1.9.0` to `^1.12.1` to use `StreamableHTTPClientTransport`.
>     - Refactor `connectToServer()` in `McpHub.ts` to use `StreamableHTTPClientTransport` first, fallback to `SSEClientTransport` if needed.
>     - Handle `sse` and `streamable-http` types in a unified switch case.
>   - **Refactor**:
>     - Replace `if/else if` with `switch` in `connectToServer()` for type safety and readability.
>   - **Misc**:
>     - Update error handling and logging in `McpHub.ts`.
> 
> <sup>This description was created by </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=RooCodeInc%2FRoo-Code&utm_source=github&utm_medium=referral)<sup> for c5f4a595c4a64976fb82a0b67d8e53394fba3bc7. You can [customize](https://app.ellipsis.dev/RooCodeInc/settings/summaries) this summary. It will automatically update as commits are pushed.</sup>

<!-- ELLIPSIS_HIDDEN -->

[daniel-lxs]

Hey @Mnehmos, thank you for your contribution.

I think this is great since our MCP implementation seems to be quite outdated, I reviewed your PR and left some questions and suggestions.

Let me know what you think!

[daniel-lxs]

The fallback mechanism only handles transport creation errors, not connection failures. If StreamableHTTPClientTransport is created successfully but fails during the actual connection attempt, there's no fallback to SSE.

Is this intentional or should we consider implementing connection-level fallback:

let transport: StreamableHTTPClientTransport | SSEClientTransport
let connectionSuccessful = false

// Try StreamableHTTP first
try {
  transport = new StreamableHTTPClientTransport(new URL(configInjected.url), {
    requestInit: { headers: configInjected.headers }
  })
  await client.connect(transport)
  connectionSuccessful = true
} catch (streamableError) {
  if (configInjected.type === "sse") {
    // Fallback to SSE
    transport = new SSEClientTransport(/* SSE config */)
    await client.connect(transport)
    connectionSuccessful = true
  } else {
    throw streamableError
  }
}

This provides more robust error handling for actual connection failures.

[daniel-lxs]

Is logging needed here? If so can we use something else than console.log?

[daniel-lxs]

The removal of client.connect(transport) seems incorrect. According to the MCP SDK documentation, you must explicitly call client.connect(transport) to establish the connection before setting the status to "connected".

The current code creates transport objects and immediately marks connections as "connected" without actually establishing the protocol handshake. This will likely cause failures when attempting to use MCP server capabilities.

Am I missing something?