Six tools with basic descriptions and minimal parameter documentation. All tools are READ_ONLY and follow verb_noun naming (get_*). However, descriptions are generic (10-50 chars), lack context on when to use each tool, and most parameters are undescribed. No output schemas documented. Error handling is minimal, tools return raw API responses without guidance on failures. The get-chuck-joke-by-category tool has a single parameter with a description, but others lack parameter documentation entirely. No tool annotations (readOnlyHint, etc.) despite all being read-only.

• Expand tool descriptions to 50-200 chars. Include WHAT the tool does, WHEN to use it, and what it returns. E.g., 'Fetch a random Chuck Norris joke from the public API. Use this for humor or entertainment. Returns a single joke string.' vs current 'Get a random Chuck Norris joke'.
• Add parameter descriptions for get-chuck-joke-by-category. Document the 'category' parameter with valid values or a reference to get-chuck-categories. E.g., 'Category name (e.g., "dev", "food", "sport"). Call get-chuck-categories to list all available categories.'
• Document output schemas for all tools. Specify that responses contain a 'content' array with a 'text' field. This enables LLMs to extract and chain results.
• Add error handling with recovery guidance. Wrap external API calls in try-catch blocks and return actionable errors. E.g., 'Failed to fetch joke from chucknorris.io. The service may be temporarily unavailable. Try again in a few seconds.'
• Add tool annotations. Mark all tools with readOnlyHint=true in the MCP server registration to signal safety and reduce agent hesitation.