Server has 6 tools with basic descriptions and input schemas. All tools are READ_ONLY and follow verb_noun naming (get_*, web_search, define_word). However, descriptions are generic (avg ~60 chars, well below the 194-char baseline), lack WHEN/WHY context, and parameter descriptions are minimal. No output schemas documented. Error handling returns plain text rather than structured guidance. Parameters lack enums where appropriate (e.g., joke category, news country). No tool annotations (readOnlyHint, etc.). Schemas are present but sparse, most parameters have type and description, but lack constraints (min/max, patterns, enums). This is typical community-server quality: functional but not LLM-optimized.

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this when the user asks about current weather in a specific city') and WHAT it returns (e.g., 'Returns temperature, humidity, wind speed, and conditions').
• Convert plain-text responses to structured JSON. E.g., get_news_headlines should return {articles: [{title: string, source: string, url: string, publishedAt: ISO8601, summary?: string}], total: int}. This enables LLM field extraction and chaining.
• Add enums to constrained parameters: get_random_joke.category = enum [programming, misc, dark, pun, spooky, christmas]; get_news_headlines.country = enum [us, gb, de, fr, ...] (or document valid ISO codes).
• Enhance error messages with recovery hints. E.g., 'Cryptocurrency not found: bitcoin. Try common symbols: BTC, ETH, SOL, or call list_cryptocurrencies() for full list.'
• Add tool annotations to schema. Mark all tools with readOnlyHint: true in the tool definition so agents know they are safe to call without confirmation.

Inferred effective spec: 2026-07-28+.

• Official extensions adopted: Apps