Three tools with basic verb-noun naming (get_*, search_*). All have descriptions and input schemas present. However, descriptions are minimal (10-50 chars for tool summaries; parameter descriptions exist but lack detail on constraints, formats, and error recovery). No output schema documentation. No error handling guidance. Parameters lack validation constraints (e.g., limit bounds not enforced in schema, only in code). No tool annotations (readOnlyHint, etc.). Schemas are present but sparse, missing examples, format specs, and chaining IDs. This is a functional but minimal implementation typical of community servers.

• Document output schema for each tool. E.g., get_random_joke_tool returns {joke: string, id: string}. search_jokes_tool returns {total_jokes: int, results: [{joke: string, id: string}]}. This enables LLMs to chain tools and extract fields.
• Add constraint metadata to search_jokes_tool's 'limit' parameter in the schema: use minimum: 1, maximum: 30 in JSON Schema. Remove the constraint logic from the docstring and let the schema be the source of truth.
• Wrap external API calls in try-catch blocks and return structured error responses. E.g., 'API error: icanhazdadjoke.com returned 404 for joke_id "invalid-id". Try search_jokes_tool to find valid IDs.' This guides LLM recovery.
• Expand tool descriptions to 50-150 chars. E.g., get_random_joke_tool: 'Fetch a random dad joke. Use this when the user wants a surprise joke without a specific topic. Returns joke text and ID for reference.'
• Add tool annotations to the FastMCP decorator. Mark all three tools with readOnlyHint=true and idempotentHint=true so agents know they are safe to retry and do not modify state.