Two tools with clear, actionable descriptions (194 - 250 chars, within baseline 34 - 392). Both have complete input schemas with proper type constraints (lat/lon bounds, radius limits, string length). Output schemas are partially documented in descriptions but not formally declared. Parameters are well-constrained with enums and ranges. No security issues detected (no secrets in params). Main gaps: output structure not formally specified; no error handling guidance; no pagination support despite list_nearby potentially returning many results.

• Add formal JSON Schema output definitions to both tools. For list_nearby, document: { venues: [{ slug, name, rating, eta_minutes, online, tags, ... }], total_count, next_cursor }. For get_menu, document: { categories: [{ id, name, items: [{ id, name, price, ... }] }] }.
• Implement pagination: add offset/limit or cursor parameters to list_nearby; return total_count and next_cursor in response. Cap default max_results at 20 - 30 and document the limit in the description.
• Add error recovery hints in descriptions. E.g., get_menu: 'If slug is invalid, call list_nearby to find a valid venue slug first.' Include common error scenarios (network timeout, invalid language code).
• Specify valid language codes as an enum or pattern. Replace 'e.g. en, et' with explicit constraint: language in ['en', 'et', 'fi', 'sv'] or similar.
• Add tool annotations to schema: set readOnlyHint=true and idempotentHint=true for both tools to signal safety to agents.

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

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