Server provides 5 tools with consistent verb-based naming (all start with 'get_'). Tool descriptions are present but generic (average 95 chars, well below the 194-char baseline for A+ tools). Input schemas are complete with proper JSON Schema types, constraints (min/max), and descriptions. However, descriptions lack LLM-optimization depth, they do not explain WHEN to use each tool vs similar ones, WHAT happens on calls, or recovery guidance on failure. Parameter descriptions are adequate (average 68 chars) but lack format hints and dependency guidance. Output schemas are partially documented via Pydantic models (ArticleOut, TrendingTermOut) visible in code, but not clearly linked in tool definitions. Error handling exists via ErrorHandlingMiddleware but no tool-level recovery guidance is provided. The 'topic' parameter in get_news_by_topic lists 60+ hardcoded examples in the description instead of declaring an enum constraint, this invites hallucinated topic values and wastes tokens. The 'summarize' parameter defaults to true and attempts LLM Sampling (deprecated pattern), falling back to NLP; this creates undocumented behavior divergence. Overall, tools are functional and usable but lack the depth and precision expected of production-grade agent tools.

• Convert the hardcoded topic list in get_news_by_topic into a proper enum constraint in the schema. Remove the list from the description and declare: {"type": "string", "enum": ["WORLD", "NATION", "BUSINESS", ...]}. This prevents hallucination and self-documents valid values.
• Expand tool descriptions to 150-200 chars. For each tool, answer: What does it do? When should I call it instead of similar tools? Example: 'Find articles by keyword from the last N days. Use this when searching for articles on a specific topic; use get_top_news for broad trending stories, or get_news_by_location for geographic focus.'
• Document the output schema explicitly in each tool description or in a separate schema field. Example: 'Returns a list of ArticleOut objects with fields: title, url, publish_date, summary, keywords, authors, images, canonical_link, meta_description.' This helps LLMs plan downstream processing.
• Remove reliance on LLM Sampling (deprecated). Either integrate the summarization logic directly into the tool (e.g., use spaCy or NLTK extractive summarization server-side) or remove the summarize parameter. If keeping the parameter, document exactly which algorithm is used and when fallback occurs.
• Add pagination support. Return total_count and next_offset in responses. Update tool descriptions: 'Returns up to max_results articles. Use offset parameter to fetch next page. Returns total_count to indicate if more results are available.'
• Add error recovery guidance to tool descriptions. Example: 'If the location is not found, the tool returns a list of suggestions. If articles cannot be fetched, returns an empty list with an error field explaining the issue (e.g., "location_not_found", "rate_limited").' This guides LLM retry logic.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry