38 tools with consistent naming (verb_noun pattern) and brief descriptions. All tools have descriptions (10-50 chars, below the 50-200 char LLM-optimized baseline). Parameter schemas are present but sparse, most tools lack detailed type info, constraints, and descriptions for individual parameters. No input validation guidance or error recovery hints visible. Output schemas not documented. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not mapped to tool annotations in the MCP protocol. Composition is sound (each tool does one thing), but descriptions are too terse to guide LLM selection effectively.

• Expand tool descriptions to 80-150 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and any prerequisites. Example: 'Get the authenticated user's home timeline. Use this to see posts from followed accounts. Requires active session.' (vs. current 'Get the timeline for the authenticated account').
• Document all parameter schemas with explicit types, constraints, and descriptions. For search_posts, specify: query (string, 1-300 chars), limit (integer, 1-100, default 20), cursor (string, optional, for pagination).
• Add output schemas to tool descriptions or a separate schema registry. Example: 'Returns {posts: [{uri, author, text, likeCount, repostCount, createdAt}], cursor: string}'.
• Map risk annotations to MCP tool annotations. Use readOnlyHint: true for READ_ONLY tools, destructiveHint: true for DESTRUCTIVE tools, idempotentHint: true for idempotent operations.
• Add error recovery guidance. Example for create_post: 'If text exceeds 300 chars, use create_thread instead. If auth fails, call whoami to verify session.'