Wrap `telegram-mcp` with `mcp-cli` to reduce tool-definition context bloat and improve invocation performance

[chigwell]

As an MCP client user (e.g., IDE/agent integrator), 
I would like to run `telegram-mcp` via `mcp-cli` 
so that tool definitions are handled out-of-band 
and tool invocations remain fast and prompt/context usage stays minimal.

Background

telegram-mcp has grown to 84+ tools. Embedding or repeatedly transmitting large tool schemas can increase context-window usage and slow down interactions. A recommendation from the community is to wrap the project using mcp-cli (https://github.com/philschmid/mcp-cli), which is reported to significantly reduce tool-definition “bloat” and keep invocations snappy by delegating schema/tool handling to a CLI wrapper.

Scope / Notes

• Introduce an mcp-cli-compatible wrapper/entrypoint for telegram-mcp.
• Preserve current behavior for existing users who start telegram-mcp without mcp-cli (backward-compatible invocation).
• Add documentation and examples for adopting the wrapper in common MCP host setups.

Acceptance Criteria

• The repository provides an mcp-cli-compatible wrapper/entrypoint that launches telegram-mcp as an MCP server without requiring users to paste/inline tool definitions into prompts.
• The wrapper exposes the same tool set and parameters as the current telegram-mcp server (no functional regression in available tools).
• A user can install and run the wrapper using standard project instructions (documented), resulting in a working MCP server connection.
• Documentation is added/updated:
  • “Why mcp-cli” rationale (context reduction + performance motivation).
  • Installation steps and prerequisites.
  • Example configuration snippet(s) for connecting via mcp-cli.
  • Migration guidance for existing users (legacy invocation vs. mcp-cli wrapper).
• The wrapper supports passing through configuration required by telegram-mcp (e.g., environment variables / config file path) without breaking existing configuration patterns.
• Startup and invocation remain reliable:
  • Server starts successfully via the wrapper on a clean environment following the docs.
  • At least one end-to-end smoke test (or CI check) validates the server can start and respond to a minimal tool call through the wrapper.
• Dependency/versioning is handled explicitly:
  • mcp-cli dependency is pinned or constrained to a compatible range.
  • Release notes (or CHANGELOG entry) mention the new wrapper option and any breaking changes (ideally none).
• The PR includes a brief verification section describing how the wrapper was tested locally.

Deliverables

• Wrapper/entrypoint files required for mcp-cli integration.
• Updated README with usage instructions and examples.
• CI or scripted smoke test demonstrating successful startup and a basic interaction via the wrapper.

[xamgore]

Tool bloating is the main downside for this MCP for sure.