Both tools have minimal definitions. Tool names are acceptable (verb_noun pattern), but descriptions are extremely short (11-16 chars, well below the 34-char p10 baseline). Input schemas are empty objects with no properties, violating the requirement that parameters have type definitions. No output schemas are documented. No error handling guidance. Tools appear to be simple GET endpoints returning hardcoded data, but the MCP registration does not expose proper schemas or parameter documentation.

• Expand tool descriptions to 50-200 characters, explaining WHAT the tool does, WHEN to use it, and what data it returns. Example: 'Retrieve current sales metrics including total revenue, units sold, and top-performing products. Use this to answer questions about sales performance and trends.'
• Document output schemas explicitly. Define the structure of the returned objects (e.g., sales array contains id, name, description fields with types). This enables LLMs to extract and chain data correctly.
• Add input parameters if tools should accept filters (e.g., date_range, region, product_category). If truly parameterless, explain why in the description.
• Implement error handling that returns actionable messages. If data fetch fails, return 'Sales data unavailable. Try again in 30 seconds or contact support.' instead of a raw error.
• Add tool annotations (readOnlyHint: true) to signal these are safe read-only operations that can be retried without side effects.