Feature Request: MCP Transport Expansion Support for STDIO and SSE for the TryPost MCP server

[githb-ac]

TryPost already has a remote MCP server with an HTTP endpoint and OAuth or Bearer-token authentication, which is the right foundation for a hosted SaaS product. This feature request proposes expanding the transport layer of that existing MCP offering to support both STDIO and SSE in addition to the current remote HTTP setup, so TryPost becomes easier to use across local desktop clients, developer environments, headless automation, and broader MCP host ecosystems. Comparisons of MCP transports consistently position STDIO as useful for local tools and desktop clients, while SSE is commonly used for remote streaming/networked integrations.

Summary

Add native STDIO and SSE transport support to the existing TryPost MCP server so users can connect in whichever mode best fits their environment: STDIO for local client compatibility and developer convenience, SSE for remote streaming compatibility, and HTTP for the current hosted cloud use case. TryPost already exposes a remote MCP endpoint at https://app.trypost.it/mcp/trypost, so this request is about transport flexibility and compatibility rather than creating MCP support from scratch.

Why This Matters

Right now, TryPost appears to be positioned primarily as a remote HTTP MCP server, which is strong for cloud workflows but less flexible for users whose MCP tools or desktop clients prefer local STDIO-style integration. Transport guidance across the MCP ecosystem typically recommends STDIO for local development and single-machine tooling, while SSE is better suited to remote/networked use cases where a long-lived service can stream responses over HTTP. Supporting both would reduce onboarding friction, improve compatibility with more MCP clients, and make TryPost more appealing to both developers and AI-agent users operating across different execution environments.

Proposed MVP

STDIO transport support for local MCP client usage, allowing TryPost’s MCP tools to be launched or proxied in environments that expect a local process connection rather than a remote URL; STDIO is widely described as the easiest option for local tooling and development.

SSE transport support for MCP clients that prefer or require Server-Sent Events for remote streaming workflows over HTTP.

Clear transport-specific setup docs showing when to use HTTP, STDIO, or SSE, plus sample configs for popular MCP clients.

A lightweight local bridge or launcher option for STDIO mode so desktop tools can connect to TryPost without forcing users to manually build their own proxy layer.

Transport auto-detection or a guided chooser in docs so users can quickly select the best mode for Claude-style desktop clients, CI agents, or self-hosted automations.

Unified auth model across transports so OAuth or Personal Access Tokens work consistently regardless of whether the client connects via remote HTTP, SSE, or a local STDIO bridge.

Compatibility matrix documenting which features are identical across transports and where limitations apply, especially around streaming, session handling, and headless agents.

Logging and diagnostics for MCP connections so developers can troubleshoot transport-specific failures more easily.

Product Impact

This would make TryPost’s MCP offering feel more complete and more developer-friendly without changing the core value of the product. For a cloud SaaS, remote HTTP should remain the primary mode, but adding STDIO and SSE would broaden the addressable MCP ecosystem, improve interoperability, and remove one of the main friction points technical users hit when their preferred client expects a different transport strategy.