Loading ToolBench

Reading the current corpus…

cc-telegram-bot MCP server · C · ToolBench

cc-telegram-bot

Presents options to the user as tappable inline buttons in Telegram. Allows Claude to ask users for input via interactive buttons.

2026-07-28+STDIO1 tools

61/100

Definition Quality77

Protocol Readiness45

Supportability45

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Single tool 'ask_user' has a complete input schema with proper types and constraints (minItems: 2, maxItems: 10). Description is clear and action-oriented (194 chars), explaining the Telegram button flow and critical instruction to STOP after calling. However, output schema is not documented, the response is hardcoded text with no structured return type specification. Parameter descriptions are adequate but lack format guidance. No error handling guidance for edge cases (e.g., file read failures, missing context). Security is reasonable (file-based IPC, directory permissions 0o700) but not formally documented in tool metadata.

Tools (1)

ask_userread onlysource verified77/100

Present options to the user as tappable inline buttons in Telegram. IMPORTANT: After calling this tool, STOP and wait. Do NOT add any text after calling this tool - the user will tap a button and their choice becomes their next message. Just call the tool and end your turn.

Issues (5)

HIGHtool ↗

Output schema not documented. Tool returns hardcoded text response; LLM cannot infer structure or plan downstream actions. Per pattern:tool, all tools must document return types.

ask_user

HIGHrecovery-guide ↗

No error handling guidance. Tool silently falls back to shared context file if per-user file missing; LLM receives no indication of degradation. Per pattern:recovery-guide, errors must guide next steps.

ask_user

MEDIUMtool-description ↗

Parameter descriptions lack format constraints. 'question' and 'options' lack guidance on length limits, character restrictions, or encoding.

ask_user

MEDIUMscope-declaration ↗

Security model not exposed in tool metadata. File-based IPC, directory permissions, and context file lookup are implementation details; tool definition does not declare permissions or audit requirements per pattern:scope-declaration.

ask_user

Recommendations

Document output schema: specify that response is {type: 'text', text: string} and explain that the LLM should expect user input in the next message after calling this tool.
Add error handling guidance: 'If context file not found, ask the user to restart the bot with /start. If buttons do not appear, check Telegram bot permissions.'
Enhance parameter descriptions: 'question (string, 1-500 chars): The prompt to display. options (array of 2-10 strings, each 1-100 chars): Button labels the user can tap.'
Declare permissions in tool metadata: add a 'permissions' field or note in description: 'Requires: read:telegram_context, write:ask_user_requests. Audit: all calls logged with user_id, chat_id, timestamp.'
Clarify idempotency: 'Each call generates a unique request ID. Repeated calls with identical question/options create separate button prompts. Not idempotent, do not retry without user confirmation.'

Score history

Overall score trend

First recorded score · v2 rubric

61/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	61	2026-07-28+	v2