Strong foundation with clear naming, comprehensive schemas, and good descriptions. All 10 tools have explicit registrations with Zod schemas and descriptions. Tool names follow verb_noun pattern (search_huts, prepare_booking, confirm_cancellation). Descriptions average ~150 chars, within the 10-1024 baseline. Schemas include proper constraints (min/max, enums, regex patterns). Tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Key gaps: parameter descriptions are missing entirely (Zod schemas lack descriptions for individual params), output schemas are not documented, and error handling lacks recovery guidance. The server instructions provide context but do not substitute for per-parameter documentation.

• Add descriptions to every Zod schema parameter. Use .describe() on z.string(), z.number(), etc. Example: z.string().min(2).max(3).describe('ISO 3166-1 alpha-2 or alpha-3 country code'). This makes constraints machine-readable and visible to LLMs.
• Document output schemas in tool definitions. Add a 'outputSchema' field or extend descriptions with 'Returns: {field1: type, field2: type, ...}'. Example: 'Returns: {hutId: integer, name: string, availability: [{date: string, freeSpaces: integer}]}'.
• Enhance error responses with recovery guidance. Modify errorResult() to return {error: message, suggestion: 'Try X', retryable: boolean}. Example: 'Invalid country code. Try search_huts() with country="CH" or omit country to search all.'
• Add dry-run support to destructive tools. prepare_booking and prepare_cancellation should return a preview (dates, costs, cancellation fees) with a draftId. confirm_* tools then execute the draft. This prevents accidental mutations.
• Document parameter relationships explicitly. For prepare_booking, clarify: 'guestData is optional; if omitted, the draft returns a browser handoff URL. rawReservationPayload is for experimental headless writes only.' Similar clarity for prepare_cancellation's optional date/people changes.