[Bug] Satellite ignores transport_type and always uses Streamable HTTP

[bytefrostdev]

Severity: Critical

This bug prevents SSE-based MCP servers from working with DeployStack, even when correctly configured.

Summary

When adding an HTTP/Remote MCP server with SSE (Server-Sent Events) transport type, the satellite ignores the configured transport and always attempts to connect using Streamable HTTP, resulting in "Method Not Allowed" errors.

Environment

• DeployStack: Latest (deployed Dec 6, 2025)
• Satellite: deploystack/satellite:latest
• MCP Server: Self-hosted mcp-proxy exposing an SSE endpoint

Steps to Reproduce

1. Add new MCP server in GUI:
   • Transport Type: SSE (Server-Sent Events)
   • URL: https://mcp.example.com/sse
2. Complete wizard and install to team
3. Check satellite logs

Expected Behavior

Satellite connects using SSE transport.

Actual Behavior

Satellite attempts Streamable HTTP POST request, which fails:

ERROR: Tool discovery failed for server-team-abc123 after 27ms using MCP SDK: Streamable HTTP error: Error POSTing to endpoint: Method Not Allowed

Verification: Database Has Correct Values

SELECT name, transport_type, remotes FROM "mcpServers" WHERE name = 'MyServer';

Result:

   name   | transport_type |                              remotes                                 
----------+----------------+----------------------------------------------------------------------
 MyServer | sse            | [{"type":"sse","url":"https://mcp.example.com/sse","headers":{}}]

✅ transport_type = sse
✅ remotes[0].type = sse
❌ Satellite still uses Streamable HTTP

What We Tested

1. Created server with SSE from start - Same error
2. Edited existing server to change transport type - Same error
3. Deleted and recreated server - Same error
4. Restarted satellite - Same error
5. Restarted entire stack (docker compose down && up) - Same error
6. Verified database values - All correct, satellite ignores them

Satellite Log Analysis

The satellite logs the server URL but never logs the transport type when connecting:

INFO: Added MCP server configuration: server-team-abc123
    server_name: "server-team-abc123"
    server_url: "https://mcp.example.com/sse"
    enabled: true

No transport_type field is logged, suggesting it's not being read from the config.

Comparison: Working vs Broken

Server	Transport	Works?
Context7	stdio (local npx)	✅ Yes
SSE Server	sse (remote)	❌ No

Root Cause Hypothesis

The satellite's remote tool discovery code defaults to Streamable HTTP transport without checking the transport_type or remotes[].type fields from the backend config.

Suggested Fix

In the satellite's remote discovery manager, when connecting to a remote MCP server:

// Current behavior (broken)
const transport = new StreamableHTTPTransport(serverUrl);

// Should be
const transportType = serverConfig.transport_type || serverConfig.remotes?.[0]?.type || 'http';
const transport = transportType === 'sse' 
  ? new SSETransport(serverUrl)
  : new StreamableHTTPTransport(serverUrl);

Impact

• All SSE-based remote MCP servers are broken
• Only stdio (local) servers work correctly
• This blocks users migrating existing mcp-proxy based setups to DeployStack

Workaround

None found. The transport type cannot be overridden.

[Lasim]

fixed with: https://github.com/deploystackio/deploystack/releases/tag/satellite-v0.13.1