Moderate quality with consistent structure across tools. All 6 tools have explicit registrations with names, descriptions, and input schemas. Descriptions are present but generic (emoji-heavy, lack context on WHEN to use each tool or dependencies between them). Parameter schemas are well-formed with types and descriptions, but missing constraints (no enums, no min/max bounds for 'top' parameter). Output schemas are completely undocumented, the code constructs TextContent responses but LLMs have no visibility into what fields/structure to expect. No error handling guidance provided. Tool naming follows verb_noun pattern (get_*) which is good, but 'get_customers' vs 'get_customer_details' distinction is only clear from description, not name alone. All tools are READ_ONLY which is appropriate, but responses in the code sample are truncated and do not show structured field documentation.

• Document output schema for each tool. Example for get_customers: 'Returns array of customer objects with fields: id (string), displayName (string), address (object with city, street), phoneNumber (string), email (string). Maximum 20 items returned.'
• Add min/max constraints to 'top' parameter. Change description to: 'Maximum number of results to return (1 - 100, default: 20). Results are truncated to the limit; use pagination if you need more.'
• Enhance descriptions with WHEN-TO-USE context. Example: 'Get a paginated list of all customers. Use this for discovery or bulk review. For details on a specific customer, call get_customer_details() with their ID.'
• Add error handling to docstrings. Example: 'If customer_id is invalid, returns error: "Customer not found. Try search_customers() with a partial name." If API is unavailable, error is retryable.'
• Rename tools for clarity: get_customers → list_customers; get_customer_details → get_customer_by_id. Or clarify in description: 'Returns a summary list; see get_customer_details for full profile.'
• Implement and document pagination. Add offset and limit parameters, or cursor-based pagination. Document in output: 'Returns total_count and next_cursor if more results exist. Use cursor in next call to fetch next page.'
• Support human-friendly lookups. Modify get_customer_details and get_item_details to accept either ID or name/number. Internally perform lookup if needed. Document: 'Accepts customer_id (exact match) or customer_name (partial match with search).'

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

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