The server defines 7 tools with explicit schema registration via the mcp-sdk. Tool names follow verb_noun conventions (start_benchmark, choose_food_category, select_menu, submit_reservation_details, get_confirmation_email, verify_confirmation_code, try_again). However, there are significant gaps: (1) descriptions are minimal to generic (most under 100 chars), lacking WHEN/WHY context for LLM selection; (2) parameter descriptions are sparse, many parameters lack domain guidance (e.g., 'confirmationCode' has only 'The confirmation code sent in your email', not explaining why 6 chars, alphanumeric vs mixed, what happens on mismatch); (3) no documented output schemas, LLMs cannot predict response structure for chaining; (4) no error handling guidance, no recovery hints if verification fails or category is invalid; (5) no resource context, the benchmark flow is opaque without understanding state transitions. The codebase shows sophisticated state management (AbstractBenchmarkState, StateMachine) and input validation (Zod schemas), but these are buried in implementation; tool descriptions do not surface this for the LLM. Average tool description length ~65 chars (well below the 194-char production baseline). Naming is acceptable but generic ('try_again' could be 'reset_benchmark_session'). Schema presence is good (all tools have Zod-defined input), but descriptions for parameters are inconsistent, some tools (submit_reservation_details) have detailed parameter constraints; others (start_benchmark, get_confirmation_email) have empty/trivial descriptions.

• Expand tool descriptions to 150-250 chars. For start_benchmark: 'Initiates a new benchmark run and enables the food category selection tool. Call this first to begin the reservation workflow.'
• Document all output schemas explicitly in the tool description or as part of the response. Example: 'Returns {status: string, available_categories: string[], message: string}'. This enables LLMs to chain tools correctly.
• Add parameter constraints to descriptions. For confirmationCode: 'A 6-character alphanumeric code (case-insensitive) sent via email. Invalid codes return a descriptive error; you may request a new email via get_confirmation_email.'
• Add error guidance to descriptions. For verify_confirmation_code: 'If the code is invalid, the session remains active and you can retry. To start over, call try_again.'
• Rename 'try_again' to 'reset_benchmark_session' to follow verb_noun convention and make intent unambiguous.
• Document state transitions. Modify tool descriptions to indicate what tools can be called next. E.g., choose_food_category: 'After calling this, call select_menu to pick a specific restaurant.'
• For get_confirmation_email, specify: Does this retry sending, or return a cached email? Can it be called before submit_reservation_details? Clarify dependencies.
• Add a discovery tool or description listing all valid food categories. LLMs should not have to infer enum values from failed attempts.
• Document validation constraints in parameter descriptions. For guests: 'Integer between 1 and 20. Values outside this range will be rejected.' For time: 'HH:MM format in 24-hour notation. E.g., 09:30 or 19:45. Invalid formats are rejected with guidance.'