CoderLegion MCP has 13 tools with complete input schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention well (create_post, edit_post, get_post, etc.). Descriptions are present but often generic, many lack context on WHEN to use the tool or what happens on failure. Parameter descriptions exist but are minimal (avg ~40 chars vs baseline 72). Critical gaps: no output schemas documented, no pagination guidance for list tools, no error recovery hints, and no tool annotations (readOnlyHint/destructiveHint). The create_post tool has 14 parameters with conditional logic (Launches-only, Videos-only fields) that is documented but not enforced via schema constraints. Missing: idempotency guarantees, rate-limit guidance, and confirmation patterns for destructive operations.

• Document output schemas for all 13 tools. Specify which fields are returned (e.g., post_id, slug, author, created_at, content_snippet) so LLMs can chain tools and extract IDs for follow-up calls.
• Add pagination to list_posts, search_posts, and browse_tag: include limit (default 20, max 100), offset/page, and total_count in response. State result cap in tool description.
• Add tool annotations: mark create_post, edit_post, add_comment, react_to_post, edit_profile with destructiveHint=true; mark get_* tools with readOnlyHint=true. This guides LLM reasoning about side effects.
• Enhance descriptions with WHEN/WHY context. E.g., 'List posts by a CoderLegion user. Use this to discover a user's published content; use search_posts to find posts across all users by keyword.' Add dependency hints: 'If you only have a username, call this first to get their post IDs.'
• For create_post, enforce category-specific parameters via schema: use oneOf to define separate schemas for Articles, Tutorials, Launches, and Videos. This prevents invalid field combinations and makes the tool self-documenting.