Five tools with basic verb-noun naming (get_*, search_*) and present descriptions. However, descriptions are generic (10-50 chars), lack context on WHEN to use each tool, and omit prerequisites. Parameter descriptions exist but are minimal. No output schemas documented. Error handling returns raw error messages without recovery guidance. All tools are read-only, reducing risk, but composition is weak, no pagination despite list tools, no chaining IDs in responses.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what structure it returns. E.g., 'Get a paginated list of products. Use this for browsing; use search_products to find by title/vendor/tags. Returns product_id, title, price, inventory_count.'
• Document output schemas for all tools. Specify which fields are returned (product_id, title, price, etc.), their types, and which are required for downstream calls.
• Add pagination support: include offset/limit or cursor-based pagination, return total_count, and document in descriptions. Cap results at 50 items per call.
• Enhance error handling: categorize errors as retryable (network timeout, rate limit) vs user-fixable (invalid product_id, malformed query). Return actionable messages: 'Product not found. Try search_products() to find by title.'
• Add parameter constraints: use enums for status values (open|closed|cancelled|any), specify numeric ranges (limit 1-250), and explain what each value means in the description.