Enable Telegram MCP Server Transport Selection (STDIO vs HTTP) via Configuration

[chigwell]

As a platform engineer, 
I would like to run the Telegram MCP server either via STDIO or via HTTP 
based on an input parameter or environment variable, 
so that the same service can be deployed flexibly in local development 
and in networked/runtime environments.

Background

The current implementation starts the Telethon client and runs the MCP server exclusively using mcp.run_stdio_async(). This limits integration options to STDIO-only transports. Adding a configurable transport mode (STDIO or HTTP) will allow the MCP to be used by external services over HTTP without changing code for different deployments.

Acceptance Criteria

• The server supports two transport modes: stdio (current behavior) and http.
• Transport mode can be selected via:
  • An environment variable (e.g., MCP_TRANSPORT), and
  • A CLI input parameter (e.g., --transport), where CLI overrides the environment variable when both are provided.
• Default transport mode is stdio when neither CLI nor environment variable is set.
• When stdio is selected:
  • The server executes await mcp.run_stdio_async() exactly as it does today.
  • No functional regressions occur for existing STDIO integrations.
• When http is selected:
  • The server starts an HTTP listener on a configurable host and port.
  • Host and port are configurable via environment variables and/or CLI parameters (e.g., MCP_HTTP_HOST, MCP_HTTP_PORT, --host, --port).
  • Sensible defaults are applied if not provided (e.g., host 0.0.0.0, port 8000).
• Startup logs clearly indicate:
  • Selected transport mode,
  • If HTTP: the effective bind host/port and the base URL.
• If an unsupported transport mode is provided:
  • The server exits with a non-zero status code and prints a clear error message listing valid modes.
• Telethon client startup (await client.start()) occurs before starting either transport mode and is shared between both modes.
• Graceful shutdown is supported:
  • On termination signals, the HTTP server (if running) stops cleanly and the Telethon client disconnects.
• A minimal documentation update is provided (README or inline docstring) describing:
  • How to run in STDIO mode,
  • How to run in HTTP mode,
  • Configuration parameters and examples.

Notes / Implementation Considerations

• Transport selection should be implemented in main()/_main() without duplicating tool registration code.
• Consider adding a small configuration helper to resolve effective values in this priority order: CLI → ENV → defaults.
• HTTP mode should expose the same MCP tool surface as STDIO mode.

[glazec]

i got some progress here https://github.com/glazec/telegram-mcp. implemented oauth, web login and run on http. Will think about how to open an PR

[naqerl]

I'm interested in helping decompose the current draft. Since @glazec's branch is 69 commits ahead, I suggest starting with pure HTTP support (minus OAuth). This would solve the 'one MCP instance per agent' bottleneck I'm hitting right now.