Token of Esteem presents a well-structured tool set with strong naming conventions, comprehensive descriptions, and detailed input schemas. All 9 tools follow verb-first naming (list_*, get_*, create_*, validate_*, cancel_*). Descriptions are consistently in the 100 - 300 character range, providing clear context for LLM selection. All tools with parameters include full JSON Schema definitions with type constraints, enums, and descriptive text. The SHIP_TO_SCHEMA and BRIEF_SCHEMA are properly reused, reducing duplication. However, output schemas are not documented in the source, we see input schemas clearly but no explicit documentation of what fields/types are returned from each tool. The stub server does not execute real orders, so error handling and recovery guidance cannot be fully assessed. Tool composition is excellent (single responsibility, clear chains), and parameter naming is precise (e.g., recipient_id vs first_name+ship_to distinction). The idempotency_key pattern in create_gift is a strong signal of production readiness.

• Document the output schema for every tool. Include return type (object, array, string), field names, types, and example structures. For example: 'Returns: { voices: [{ id: string, name: string, preferred_image_model: string }], ... }'. This enables agents to chain tools effectively.
• Add explicit schema: {} or schema: { type: 'object', properties: {} } to parameterless tools (list_voices, list_formats, list_image_models) so MCP tooling recognizes them as valid.
• Document error responses in tool descriptions. Example: 'On validation failure, returns { valid: false, errors: [{ field: string, reason: string }] }. On content policy rejection, returns { valid: false, reason: string, recovery_hint: string }.'
• For create_gift, consider moving shared_payment_token into a server-side secret injection pattern or an out-of-band payment authentication step. If tokens must be parameters, explicitly document that they are single-use and never stored.
• Add per-item error details to list_gifts and other batch operations. If filtering or processing fails for one gift, the response should indicate which gift_id failed and why, not reject the entire list.
• Include chaining IDs in all responses. For example, create_gift should return the gift_id immediately, and get_gift should return both gift_id and recipient_id so subsequent tools have all references needed.
• Document the real server's timeout and rate limits (if any) in tool descriptions so agents know when to back off.