Server has 6 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools are READ_ONLY and lack error handling guidance. Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Parameter descriptions exist but lack actionable constraints. No output schemas documented. Tool naming is verb-forward (fetch_, get_, list_) which is good, but parameter naming inconsistencies (e.g., 'feed' vs 'source_id') and missing enum constraints on several tools reduce clarity. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Error responses not visible in code, likely return raw API errors without recovery guidance.

• Document output schemas for all tools. E.g., fetch_news should return {articles: [{title, url, source, publishedAt, description}], fetchedAt, source}. This enables LLMs to chain results into downstream tools.
• Add error recovery guidance to descriptions. E.g., 'If SIATA is unavailable, try fetch_news for air quality mentions. If rate-limited, retry after 60 seconds.'
• Distinguish fetch_news, get_news, and get_all_news in descriptions. Clarify: fetch_news queries multiple RSS sources in parallel; get_news queries a single feed; get_all_news is an alias for fetch_news with all sources. Remove redundancy.
• Add readOnlyHint and idempotentHint annotations to all tools in the MCP server registration. This signals to LLMs that these tools are safe to retry and cache.
• Replace free-form 'feed' and 'source_id' parameters with strict enums. E.g., source_id: enum [telemedellin, eltiempo_medellin, minuto30, vivir_poblado, centropolis, google_news_medellin, all]. This prevents hallucinated values.