Loading ToolBench

Reading the current corpus…

claude-code-telegrammer MCP server · D · ToolBench

← Browse

claude-code-telegrammer

github.com/scitex-ai/claude-code-telegrammer

Custom Telegram MCP server + TUI auto-responder for running Claude Code as an autonomous Telegram agent

<=2025-11-25STDIO3 tools

52/100

Definition Quality58

Protocol Readiness47

Supportability45

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Three tools with clear verb-noun naming (get_*, download_*) and reasonable descriptions (100-150 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented in the provided source, parameter constraints lack enums/ranges, and error handling guidance is minimal. The download_attachment tool accepts multiple optional identifier patterns (file_id, row_id, chat_id) without clear mutual-exclusivity documentation. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.

Tools (3)

download_attachmentwriteauth50/100

Download a Telegram message attachment by file_id or row_id. Returns the local file path. Supports short-circuit caching: if the attachment was previously downloaded and the file still exists on disk, returns the cached path without re-downloading.

get_historyread onlyauth50/100

Retrieve message history from a Telegram chat with optional limit and offset parameters. Returns messages with coverage information indicating data completeness.

get_unreadread onlyauth50/100

Retrieve unread messages from a Telegram chat or across all chats. Returns messages with coverage information.

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., message IDs, timestamps, file paths) without knowing response structure.

get_historyget_unreaddownload_attachment

HIGHconstrained-input ↗

download_attachment accepts three optional identifier parameters (file_id, row_id, chat_id) without documenting mutual exclusivity or precedence. LLMs may pass conflicting combinations.

download_attachment

MEDIUMconstrained-input ↗

Numeric parameters (limit, offset) lack min/max constraints. LLMs could pass negative, zero, or absurdly large values (e.g., limit=-1 or limit=999999).

get_historyget_unread

MEDIUMtool-annotation ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint). download_attachment is marked WRITE but lacks destructiveHint; get_* tools lack readOnlyHint.

get_historyget_unread

Recommendations

Document output schemas for all three tools. Specify fields returned (e.g., get_history returns [{message_id, text, timestamp, sender_id, ...}], download_attachment returns {file_path, file_size, mime_type}).
Add min/max constraints to numeric parameters: limit (1 - 100, default 20), offset (0 - 10000, default 0). Include in parameter descriptions.
For download_attachment, clarify parameter precedence: 'Provide either file_id OR row_id. If both provided, file_id takes precedence. chat_id is optional and inferred from attachment record if omitted.'
Add tool annotations: readOnlyHint=true for get_history and get_unread; destructiveHint=true for download_attachment (writes to disk).
Include error recovery guidance in descriptions: 'If chat_id not found, call list_chats() to discover valid IDs.' 'If file download fails, check network and retry; if persistent, file may have been deleted.'

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

52/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	52	<=2025-11-25	v2