Server provides 8 tools with basic schemas and descriptions, but quality is inconsistent. All tools have descriptions (10-80 chars, mostly short), and input schemas are present with parameter types. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool or HOW to chain them. No output schemas documented. Error handling is absent, no guidance on retries, user-fixable errors, or recovery paths. Tool naming follows verb_noun convention (search_, get_, query) but lacks clarity on distinctions (search_catalog vs search_tables). Parameters lack enums, ranges, and format constraints. No tool annotations (readOnlyHint, idempotentHint). Composition is weak, tools operate on opaque IDs (dataset_id, table_id, job_id) without natural identifiers or lookup helpers.

• Document output schemas for all tools. For search_catalog, specify: {results: [{id, name, category, description}], total_count, next_cursor}. For query, specify: {job_id, status, estimated_rows}. For get_results, specify: {rows: [...], total_rows, has_more}.
• Expand descriptions to 80-150 chars with WHEN/WHY guidance. E.g., 'Search the Baselight catalog (datasets, tables, columns) by name or keyword. Use this to discover available data before querying. Returns up to 20 results; use limit to adjust.'
• Add parameter constraints: category as enum (if known values exist), limit as integer with min=1, max=1000, default=20. page as integer with min=1, default=1. query as string with minLength=1, maxLength=500.
• Add error handling examples in descriptions. E.g., 'If query fails with syntax error, check SQL. If job_id not found, the job may have expired, re-run query. If rate-limited, retry after 60 seconds.'
• Consider adding a resolve_dataset_name(name) or resolve_table_name(name) tool to accept human-friendly names and return IDs, enabling natural-language composition.

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained