Three tools with complete schemas and descriptions. Naming follows verb_noun convention (search_, dataset_, query). Descriptions are clear and contextual (avg 150 chars, within 10-1024 baseline). All parameters have type definitions and descriptions. However, output schemas are undocumented, LLMs cannot predict response structure for chaining. Error handling is minimal (generic HTTP errors). No input validation guidance (e.g., ODSQL injection risk). Missing idempotency hints and permission declarations. Composition is sound: search → info → query workflow is logical.

• Document output schemas for all three tools. Example for search_datasets: 'Returns {datasets: [{id, title, theme, record_count}], total_count, limit, offset}'.
• Add error recovery guidance in the get() function. Map HTTP status codes to actionable messages: 404 → 'Dataset not found. Try search_datasets() to find available datasets.'; 400 → 'Invalid ODSQL syntax. Check where/select/group_by parameters.'
• Validate and escape ODSQL parameters. Sanitize 'where', 'select', 'group_by', 'order_by' to prevent injection. Document constraints in parameter descriptions (e.g., 'where: ODSQL filter; avoid raw user input').
• Add tool annotations to inputSchema: mark all three tools with readOnlyHint: true (they only read data, never modify).
• Include pagination metadata in responses. Ensure search_datasets and query return total_count and has_more so LLMs can plan multi-page fetches.