MCP server for fetching and analyzing Telegram channel messages and recommendations using the Telegram Bot API
The server defines 3 tools with action-verb names (get_*, expand_and_collect) and reasonable high-level descriptions. However, parameter schemas lack critical detail: parameter types are all declared as 'string' (hours_back, depth) when they should be 'number' or 'integer'; no enum constraints on channel names or depth limits; parameter descriptions are minimal and lack format guidance (e.g., 'hours_back' says 'Number of hours' but doesn't specify range, units, or default behavior). Output schemas are entirely undocumented, callers have no visibility into what fields ChannelMsg and SimilarChannel return, making it impossible for LLMs to plan downstream calls or extract relevant data. Error handling is absent from tool definitions. The tool 'expand_and_collect' conflates two responsibilities (expand + collect), violating single-concern principle. Parameter descriptions fail to mention that hours_back and depth accept numeric string input, creating ambiguity for LLMs. No validation rules documented (e.g., depth max 2, hours_back range). Overall, definitions are baseline functional but lack the rigor needed for reliable agent use.
Performs a full pipeline: takes seed channels, expands to similar channels (depth up to 2), collects last N hours of messages from all channels, and returns the full dataset for analysis. Returns both the expanded channel list and all collected messages.
Fetches recent messages from one or more Telegram channels. Returns messages posted within the specified number of hours with metadata including channel info, message ID, date, text content, view and forward counts, and direct message link.
Returns Telegram channels recommended as similar to specified seed channels. Deduplicates results across multiple seed channels and returns channel username, title, and subscriber count.
Parameter types are all declared as 'string' but should be 'number' or 'integer' (hours_back, depth). This forces LLMs to pass numeric values as strings and guess at conversion semantics.
No output schema documentation. ChannelMsg and SimilarChannel types are defined in code but not exposed in tool definitions. LLMs cannot predict return structure, field names, or types, preventing intelligent chaining and data extraction.
Parameter constraints not documented: hours_back has no min/max bounds (what if LLM passes 10000?); depth max 2 is mentioned in description but not enforced via schema constraints; channels parameter format (comma-separated, with/without @) is mentioned but not formally constrained.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool 'expand_and_collect' combines two distinct operations (expand to similar channels + collect messages), violating single-responsibility principle. Should be split into 'expand_channels' and 'collect_messages' so agent can compose them independently.
Parameter descriptions are sparse and lack implementation guidance. 'hours_back' says 'Number of hours to look back for messages. Default: 24' but doesn't specify range (1-365?), whether fractional values are allowed, or error behavior if invalid. 'channels' says 'Comma-separated list' but doesn't clarify if 'channel name' means username or display title.
No error handling guidance in tool definitions. What happens if a channel doesn't exist? If rate-limited? If 2FA required? LLMs receive no recovery path and cannot adapt behavior on failure.
No pagination or result limits documented. get_messages could return thousands of messages; get_similar_channels could return hundreds of channels. No limit, offset, or cursor parameters. Risk of context window exhaustion and degraded LLM reasoning.