Loading ToolBench
MCP server for scraping Telegram public channels and groups
This server has critical definition quality gaps. Of 15 tools, ALL lack proper input parameter descriptions in the schema. While tool names are action-oriented (scrape_*, get_*, login, logout, search), the parameter descriptions are minimal or missing type information within the actual schema objects. The server uses a STDIO-only transport, which automatically caps protocol readiness at 50. Most critically, input schemas show parameter descriptions inline (good), but lack proper JSON Schema typing in many cases. Error handling is minimal, most handlers return simple text responses without actionable recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear READ_ONLY vs WRITE distinctions documented in the brief. The tool descriptions themselves are adequate (60 - 120 chars), but parameter-level descriptions within schemas are inconsistent. Composition is poor: multiple overlapping tools (scrape_channel, scrape_channel_authenticated, api_scrape_channel; get_channel_info, api_get_channel_info) create unnecessary cognitive load for LLMs without clear distinction when to use each. No pagination support visible. Credentials (api_id, api_hash, phone_number) are accepted as parameters, a security anti-pattern.
Get channel details using the Telegram API
Disconnect from Telegram API
Scrape a Telegram channel using the API (fast and efficient)
Search within a Telegram channel using the API
Get only the channel/group information without scraping posts. Uses authenticated session if logged in.
Scrape a Telegram channel and return posts in markdown format. Uses authenticated session if logged in.
Credentials exposed as tool parameters (phone_number, api_id, api_hash), direct security anti-pattern. Secrets must never be parameters; they leak into agent logs and traces.
No tool annotations despite clear READ_ONLY vs WRITE semantics. Tools like scrape_* are read-only; login/logout/api_logout are write operations. Annotations missing: readOnlyHint, destructiveHint, idempotentHint.
Multiple overlapping tools for identical functionality without clear distinction. scrape_channel, scrape_channel_authenticated, api_scrape_channel all scrape channels; get_channel_info and api_get_channel_info both fetch metadata. LLMs will struggle to select between them.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | 2024-11-05+ | v1 |
Scrape a Telegram channel using authenticated session (can access restricted content)
Scrape ALL posts from a Telegram channel and save to file. Uses authenticated session if logged in. Returns file location.
Scrape posts within a specific date range. Uses authenticated session if logged in.
Scrape a Telegram group and return posts in markdown format. Uses authenticated session if logged in.
Manual scraping mode: Opens browser for you to login and navigate to any channel, then scrapes it
Login to Telegram using API credentials for fast, efficient scraping
Check if authenticated with Telegram
Authenticate with Telegram Web to access restricted content
Clear Telegram authentication cookies
Parameter descriptions in schemas are inconsistent and some lack proper JSON Schema type constraints. 'max_posts' uses type:number but no min/max bounds. 'limit' appears with conflicting names (limit vs max_posts in api_scrape_channel). LLMs cannot validate input without explicit constraints.
Error handling is minimal. Handlers return unstructured text responses ('❌ Error message') rather than structured error objects with error codes, actionable recovery guidance, or retryability hints. LLMs cannot parse recovery intent from emoji-prefixed strings.
No pagination or result-limiting visible in list-returning tools (api_search_channel accepts limit but no offset/cursor; api_scrape_channel returns potentially unbounded posts). Large result sets will exhaust context windows.
Tool descriptions for api_* tools do not clearly explain when to use them vs web-scraping equivalents. 'Fast and efficient' is vague. Should state: 'Requires Telegram API credentials from my.telegram.org. Use when authenticated; offers better reliability and filtering than web scraping.'
scrape_date_range has required parameter 'date_from' but optional 'date_to', relationship undocumented. If only date_from is provided, what is the end date? Current day? Must clarify parameter interdependencies.
api_scrape_channel has redundant parameters: both 'url' and 'channel' accept the same input; both 'max_posts' and 'limit' do the same thing. Overloaded parameters force LLMs to reason about which to pass, introducing ambiguity and failure modes.
Output schemas are not documented. Handlers return formatted markdown text; LLMs cannot extract structured data (channel_id, post_count, date_range) for downstream tool calls. No chaining IDs returned.