Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and error guidance. All tools have descriptions (10-100 chars baseline met), but descriptions lack actionable context for LLM selection. Input schemas present but minimal, only restaurant_name and vibe parameters, no enums, ranges, or format constraints. No output schemas documented. Error responses return JSON status objects but lack recovery guidance ('Try a partial name' is a start, but incomplete). No tool annotations (readOnlyHint, idempotentHint). Tools are read-only and well-scoped (single responsibility), but descriptions don't explain WHEN to use each tool vs. alternatives or what downstream data is available.

• Add output schema documentation for each tool. Example for get_restaurant_info: 'Returns {status: "found"|"not_found", count: number, results: [{name, cuisine, rating, price_range, vibes, neighborhood}]}'. This lets LLMs plan downstream calls.
• Add format constraints to parameters. E.g., 'restaurant_name: string, case-insensitive, partial match supported (e.g., "Iron" matches "Iron Chef")'. Replace vague 'vibe' description with enum or examples: 'vibe: string, e.g., moody, romantic, sun-drenched, casual, upscale'.
• Expand tool descriptions to include selection context. E.g., 'Use get_restaurant_info to find details about a specific restaurant by name. Use recommend_by_vibe to discover restaurants matching an atmosphere keyword.'
• Standardize error responses with recovery guidance. Return: {status: "not_found", message: "...", recovery: "Try search_by_vibe() or provide a partial name"}. Categorize errors as retryable, user-fixable, or fatal.
• Add tool annotations in schema. Mark all three tools with readOnlyHint: true and idempotentHint: true so LLMs know they are safe to retry and do not modify state.

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

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API