Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-80 chars, mostly short), and input schemas are present with Zod validation. However, parameter descriptions are minimal or absent, most params lack context for LLM selection. Output schemas are not documented; responses are JSON-stringified without field-level guidance. Error handling is minimal: HoroshopApiError exists but recovery guidance is absent. The horoshop_call_api tool is a dangerous catch-all that accepts arbitrary function names and params, violating single-responsibility and creating injection risk. No pagination, rate limiting, or idempotency guarantees. Naming is verb-forward (good), but parameter names lack type suffixes (order_id vs order_id_number).

• Remove horoshop_call_api entirely. Replace with explicit, named tools for each Horoshop API endpoint (e.g., horoshop_get_order_notes, horoshop_create_order). Each tool should have a clear, single responsibility.
• Add detailed parameter descriptions to list_orders and list_products. Document valid filter keys, expected types, and provide examples: 'filters: object with keys like status (string), date_from (ISO 8601), limit (1-100). Example: {"status": "completed", "limit": 50}'.
• Document output schemas for all tools. Specify which fields are returned, their types, and which are safe to pass to downstream tools. Example for get_order: 'Returns {id, status, customer_name, total_price, items: [{product_id, quantity, price}]}'.
• Add pagination to list_orders and list_products. Accept limit (1-100, default 20) and offset (default 0) parameters. Return total_count and next_offset in response so LLM can iterate.
• Enhance error handling. Catch HoroshopApiError and return structured error responses with actionable guidance: '{error: "Invalid order ID", suggestion: "Order IDs must be numeric. Try horoshop_list_orders() to find valid IDs."}'