openclaw - 💡(How to fix) Fix [Feature]: Native MCP HTTP/SSE transport support — current mcpCapabilities guard

Summary

Roadmap question on whether the http: false, sse: false guard in dist/acp/translator.js will be lifted, allowing native consumption of HTTP and SSE MCP transports by OpenClaw agents.

Problem to solve

The guard mcpCapabilities: { http: false, sse: false } in dist/acp/translator.js blocks HTTP and SSE MCP transports from being consumed by OpenClaw agents. Users who want to use HTTP-based or SSE-based MCP servers currently have to patch the file locally or run a bridge process (e.g., freema/openclaw-mcp, Composio). The community has open feature requests (#29053, #4834, #8188) and PR #5121 (igorhvr) added partial server-side support, but there's no clear public signal on the timeline for native client support.

Proposed solution

Either: (a) Lift the http: false, sse: false guard behind a config flag with appropriate tests, allowing users who need HTTP/SSE MCP transports to opt in, OR (b) Publish/confirm the timeline for native MCP HTTP+SSE client support in an upcoming release so the community can plan around it.

Open questions:

• Is the current guard intentional (security posture, transport-quality concerns) or temporary pending native support?
• Would a community PR to lift the guard (with config flag + tests) be in scope, or is the team planning to do this in-house as part of a larger MCP overhaul?

Alternatives considered

• Local patching of dist/acp/translator.js per install (works but breaks on every OpenClaw update; not maintainable)
• Bridge processes like freema/openclaw-mcp or Composio (functional but adds a separate process to operate and monitor; not native)
• Waiting indefinitely without signal on roadmap (blocks downstream planning)

Impact

Affected: Operators and integrators using HTTP/SSE-based MCP servers with OpenClaw. Severity: Medium — workarounds exist but add fragility and operational cost. Frequency: Whenever a user attempts to wire an HTTP or SSE MCP transport (increasingly common as the MCP ecosystem matures). Consequence: Maintenance burden of local patches, extra process to run/monitor for bridges, and uncertainty about whether to invest in workarounds vs wait for native.

Evidence/examples

• The guard itself: dist/acp/translator.js → mcpCapabilities: { http: false, sse: false }
• Existing community workaround: github.com/freema/openclaw-mcp
• Commercial workaround: Composio's OpenClaw integration
• Public DIY guide: Rapha-btc gist documenting the patch path
• Related upstream work: PR #5121 (partial server-side MCP support)
• Open feature requests: #29053, #4834, #8188

Additional information

Asking because I'm evaluating whether to invest time in a downstream integration approach versus waiting for native support. Either path is fine — I'd just like to know which one to plan around.

Thanks for the work on OpenClaw. — Randy / FME Consultants