The server provides 12 tools with explicit JSON schemas and descriptions. Most tools have reasonable naming (verb_noun pattern) and input schemas are well-formed. However, there are significant gaps: (1) Missing output schema documentation for all tools, LLMs cannot predict what fields to expect in responses; (2) Several parameter descriptions lack detail about constraints, formats, and valid ranges; (3) Error handling guidance is minimal, most tools just return error text without recovery hints; (4) Some parameter choices force extra lookups (e.g., chatId as string requires user resolution); (5) No parameter validation descriptions for edge cases like ringDurationSeconds max=60. Tools like messages_getHistory have good descriptions, but tools like status_getCurrent and status_setEmoji lack enough detail about emoji ID formats and collectible requirements. The rubric baseline for param descriptions is 72 chars average; many here fall short. Definition quality is above-average for community servers but falls short of production-grade (70+) due to missing output schemas and incomplete parameter documentation.
Tools (12)
call_requestwriteauthsource verified77/100
Initiate a phone call to a user (ring their phone). The call will be automatically discarded after a short delay. Only works with individual users, not groups or channels.
No output schemas documented for any tool. LLMs cannot predict response structure, which prevents them from planning downstream tool calls or extracting specific fields reliably.
Parameter descriptions lack constraint details (format, length, valid ranges). E.g., 'emojiId' has no documentation of format; 'until' accepts 'ISO-8601 string or Unix timestamp' but examples missing; ringDurationSeconds states max but no validation guidance. Rubric baseline: 72 chars avg param description.
Document output schemas for all 12 tools. Use TypeScript interfaces or JSON Schema to define response structure. Example for messages_sendText: 'Returns {success: boolean, message_id: string, timestamp: number, text: string}', this enables LLMs to chain calls.
Expand parameter descriptions to include format/constraint details. E.g., 'ringDurationSeconds (number, 1-60, default 15): Seconds to ring before auto-disconnect. Values >60 are capped to 60. Peer must pick up within this window or call auto-discards.' Replace inferential language ('e.g.') with formal constraints (enums, ranges).
Add recovery guidance to error responses. Instead of 'Error initiating call: [message]', return structured errors like {error: 'CALL_FAILED_USER_NOT_FOUND', suggestion: 'Try dialogs_list() to confirm the user\'s chatId, then retry with correct ID', details: {...}}.
Clarify parameter semantics and dependencies. E.g., for status_setEmoji, explicitly state in both emojiId and clear descriptions: 'Mutually exclusive: provide emojiId to set emoji, or clear=true to remove status. Providing both is an error.' Use JSON Schema 'oneOf' to enforce this at schema level.
Add pagination support to list tools. dialogs_list currently returns up to 50 dialogs with no next_cursor or offset mechanism. Add 'offset' and 'total_count' to response schema so LLM can paginate large result sets without context bloat.
Explain when to use overlapping tools. Add to dialogs_list description: 'Use this to see all chats. For detailed info about one chat (members, pinned messages, settings), use dialogs_getInfo.' Similarly, clarify wait_for_reply (blocking, single message) vs messages_getHistory (non-blocking, batch).
Error handling provides no recovery guidance. Tools return bare error text (e.g., 'Error initiating call: [message]') without hinting at next steps. Try search_users() with a partial name.'
Parameter names/semantics force extra lookups. 'chatId' accepts 'User ID or username' but requires internal resolution via client.resolveUser(). Should accept human-friendly identifiers (usernames) directly.
Complex parameter relationships underdocumented. status_setEmoji: emojiId is 'required unless clear=true', but this mutual exclusion is not explicit in schema or both param descriptions. status_listCollectibles: 'owner' param valid values unclear (only 'self'? other users?).
Tool descriptions lack context for selection. 'dialogs_getInfo' vs 'dialogs_list', unclear when to use each. 'status_getCurrent' doesn't explain peerId format (is it a username, ID, or 'self'?). State WHAT the tool does, WHEN to use it, and any prerequisites.'
Validate inputs early with specific error messages. E.g., if chatId is invalid, return 'Invalid chatId: must be a username (alphanumeric) or numeric user ID. Got: "[input]". Example: @username or 123456789' instead of generic error.
Document status parameter formats. For status_setEmoji, explain emojiId format (hex string? numeric? length?), isCollectible use cases (when would I use this?), and 'until' format with examples ('2024-12-31T23:59:59Z' or '1735689599').
Split composite concerns if any. Review call_request: does it need to handle both voice and video calls, or should these be separate tools? Current design is reasonable, but document the design choice.
Add operation type hints to descriptions. Add annotations like 'DESTRUCTIVE: This sends a message. Cannot be undone.' to guide agent behavior.