This server has a single tool with critical structural and description deficiencies. The tool name is grammatically awkward ('format_telegram_post' is slightly verbose but acceptable), but the real issues are: (1) the description, while present, is 193 characters and reads like marketing copy rather than LLM-optimized guidance; (2) the input schema is minimal, only a 'text' parameter with a basic string type and description; (3) no output schema is documented anywhere in the code; (4) the tool delegates all logic to Claude API rather than implementing deterministic formatting, making it non-idempotent and unreliable; (5) error handling is minimal and provides no recovery guidance; (6) the implementation exposes API keys as implicit parameters (ANTHROPIC_API_KEY) without secret injection patterns. The codebase shows no tool annotation hints, no pagination, no structured output documentation, and no field-level descriptions for responses. The baseline for a single-tool server requires at minimum documented output schemas, proper error classification, and clear composition guidance, none of which are present.

• Document the full output schema in code comments or JSDoc: { formatted_text: string, character_count: number, warning?: string }. Specify that formatted_text is guaranteed ≤220 chars.
• Add input parameter constraints: mark 'text' as required, specify minimum length (e.g. 1 char) and maximum length (e.g. 5000 chars), and add validation that rejects empty strings with a clear error message.
• Implement deterministic formatting logic in TypeScript instead of delegating to Claude. Rules: (1) if text ≤220 chars, return as-is (optionally add emojis via a fixed mapping); (2) if >220 chars, truncate to 200 chars, add '…' suffix, and add relevant emoji. This ensures idempotency and faster responses.
• Refactor error handling to categorize errors and provide recovery guidance. Example: if text is empty, return { error: 'Text parameter required. Provide a non-empty Telegram post.', is_retryable: false }. If text exceeds API limits, return { error: 'Post too long. Max 5000 characters. Provided: N chars.', is_retryable: false }.
• Rewrite tool description as LLM-optimized guidance: 'Formats Telegram posts for X/Twitter (220 char max). Truncates long text, preserves key info (names, numbers), adds emojis. Call this to adapt channel posts before publishing to X. Returns formatted_text (≤220 chars) and character_count. Input text is required (1 - 5000 chars).'
• Document no additional tools needed. The server is single-purpose, mark it as such. If the server grows, consider splitting into tools like 'validate_tweet_length' and 'reformat_for_x' so agents can compose steps.