Server has 6 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with type definitions. However, descriptions lack depth, they state WHAT but not WHEN or WHY to use each tool. Parameter descriptions are minimal (e.g., 'News category' without explaining valid values or defaults). Output schemas are not documented, LLMs cannot predict response structure. Error handling is present but generic ('Cannot fetch article' with no recovery guidance). No tool annotations (readOnlyHint, etc.). Tool naming is reasonable (verb_noun pattern: get_*, fetch_*, read_*) but some tools overlap in purpose (read_article, full_article, summarize_article all fetch the same resource differently), creating ambiguity for LLM selection.

• Document output schemas for all tools. Example for latest_news: 'Returns {category: string, count: int, articles: [{title, link, published, summary}]}'. This lets LLMs predict response structure and chain tools correctly.
• Expand tool descriptions to 80-150 chars. Example: 'Fetch the latest news articles from a category (home, world, business, etc.). Use this to discover recent articles; then call read_article or summarize_article to get full content. Limit defaults to 5 articles.'
• Consolidate read_article, full_article, and summarize_article into a single fetch_article tool with a 'format' parameter (enum: 'full', 'summary', 'chunked'). This eliminates ambiguity and reduces tool count.
• Add actionable error messages. Instead of 'Cannot fetch article', return: 'Failed to fetch article from URL (network timeout after 10s). Verify the URL is valid and the site is accessible. Try again in 30s.' Include the invalid value and constraint.
• Add readOnlyHint: true to all tool schemas in FastMCP. This signals to agents that these tools are safe to retry and do not modify state, enabling smarter retry logic.