Server has 4 tools with explicit schemas and descriptions. Naming follows verb_noun convention (query_data, get_schema, omim_execute, omim_search). Descriptions are present (avg ~150 chars) but lack actionable context for LLM selection. Input schemas are well-typed with Zod validation. Critical gaps: no output schemas documented, no error handling guidance, no parameter constraints (enums, ranges), and omim_execute accepts arbitrary code, a severe security risk without sandboxing validation details visible in source.

• Document output schemas for all tools. Specify: query_data returns {rows: [{...}], total_count: number}, get_schema returns {tables: [{name, columns: [{name, type}]}]}, omim_execute returns {result: unknown, logs: string[], stagedResults?: any[]}.
• Add parameter constraints: query_data.sql must be SELECT-only (validate with regex), max 1000 chars; omim_search.query max 500 chars; omim_execute.code max 5000 chars with timeout 30s documented.
• Rewrite omim_execute description: 'Execute JavaScript in a sandboxed V8 isolate (30s timeout, no network access, no file I/O). Returns {result, logs, stagedResults}. Use for complex data transformations; for simple queries use query_data.'
• Split omim_search into two tools: omim_search_catalog (keyword search, returns endpoint names/descriptions) and omim_search_openapi (JavaScript evaluation, returns matching operations). Clarify which is default.
• Add error guidance: 'If data_access_id is invalid, call omim_execute again to re-stage data. If query times out, reduce result limit or add WHERE clauses. If code fails, check logs field for error details.'