Three tools with clear verb-noun naming (list_ideas, get_idea, create_idea) and reasonable descriptions (100-150 chars). All tools have input schemas with Zod validation and type definitions. However, parameter descriptions are minimal (10-30 chars), lacking actionable guidance on constraints, formats, and dependencies. Output schemas are not formally documented, responses are formatted as text rather than structured objects. Error handling is generic (API errors logged as text) with no recovery guidance. Missing tool annotations (readOnlyHint, destructiveHint) despite clear risk profiles.

• Expand parameter descriptions to 50-100 chars with explicit constraints. E.g., 'Page number for pagination (1-based, default: 1). Use to retrieve subsequent result sets.' and 'Results per page (1-100, default: 20). Larger values may slow response time.'
• Return structured JSON objects instead of formatted text. E.g., list_ideas should return {ideas: [{id, title, stage, author, reactions_count, comments_count, created_at}], pagination: {current_page, total_pages, total_count}} so LLMs can extract fields without parsing.
• Add tool annotations: server.tool(..., {...}, {readOnlyHint: true}) for list_ideas and get_idea; {destructiveHint: true} for create_idea. This signals safety properties to LLM clients.
• Implement structured error handling with recovery hints. E.g., if idea_id not found, return {error: 'Idea not found', code: 'NOT_FOUND', suggestion: 'Call list_ideas() to find valid idea IDs'}. Categorize errors as retryable vs. user-fixable.
• Document content format precisely in create_idea. E.g., 'Content is split into paragraphs by blank lines. Lines starting with # (single hash) become section headings. Markdown-style formatting is not supported, use plain text only.'