Loading ToolBench
MCP server for public Telegram channels — profiles, subscriber counts, posting cadence, and the channels Telegram itself considers similar.
This server demonstrates strong naming conventions, excellent parameter documentation, and well-structured schemas. All three tools follow the verb_noun pattern (telegram_*) and have comprehensive descriptions (170-250 chars each). Input schemas are fully specified with proper type constraints and enum fields. However, output schemas are not explicitly documented in the code, only inferred from markdown/json format responses. Error handling is present but minimal, with no recovery guidance for common failures (e.g., 'channel not found'). Tool annotations are correctly applied (readOnlyHint, openWorldHint). The implementation shows maturity in design but lacks the error resilience and output schema documentation expected of A-grade tools.
Look up a public Telegram channel: title, description, exact subscriber count, creation date, verification and scam flags, and how often it posts. Use to check whether a channel is real, how large it is, and whether it is still alive — a channel with 200k subscribers and nothing published this year is a common and invisible failure.
Telegram's own global search over public channels and groups, by title and handle. Good for seeding a topic; telegram_similar_channels is what expands a seed into a neighbourhood. Short topical words work better than sentences.
Return the channels Telegram itself recommends alongside a given channel — its own topical judgement, not a keyword match, so it surfaces channels that share an audience without sharing vocabulary. The way to discover channels whose names you do not already know: start from one you do and walk outward. Large channels return roughly a dozen; small or very new ones return none.
Output schemas not documented. Tools return either markdown prose or raw JSON based on 'format' parameter, but the structure of these responses (fields, types, nesting) is not formally documented. LLMs cannot reliably extract structured data or plan downstream chaining without knowing what fields to expect.
No error recovery guidance. Tools lack descriptions of what to do when a channel is not found, API rate limits are hit, or the upstream service is unavailable. Errors are returned as plain text without actionable recovery steps ('Channel not found, try search_channels()' or 'Rate limited, retry in 30 seconds').
Overloaded 'channel' parameter accepts multiple formats (@handle, bare handle, t.me link). While documented, this forces the LLM to reason about valid formats and risks passing invalid values. A parameter type suffix (channel_handle vs channel_link) would be clearer.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No pagination support. telegram_similar_channels and telegram_search_channels return all results without limit or offset parameters. If a search returns hundreds of channels, the response token count could balloon, diluting context and increasing hallucination risk.
Parameter 'cadence' (telegram_channel) and 'enrich' (telegram_similar_channels) have side effects (extra API calls) but are not clearly flagged as optional optimizations. Parameter descriptions could emphasize cost trade-offs: 'Include posting rate... Costs one extra API call. Default true.' is good, but no guidance on when to omit for cost savings.