19 tools with complete schemas and descriptions, but significant gaps in error handling, parameter constraints, and output documentation. Tool names follow verb_noun convention well (sql_run_query, pbi_get_schema, fabric_create_measure). Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Parameters lack enums for constrained values (e.g., database_id, action fields). No documented output schemas, pagination guidance, or recovery paths. Security annotations present (readOnlyHint/destructiveHint) but no permission gates or audit trail guidance in tool descriptions. Composition is sound, tools are single-responsibility, but chaining IDs and error recovery are underdocumented.

• Document output schemas for all tools. E.g., sql_run_query returns {rows: [{col1: string, col2: number}], rowCount: number}. Include field types and whether results are paginated.
• Add enums to constrained parameters. database_id should enumerate ['mssql', 'postgresql']. table_name, procedure_name, measure_name should accept human-readable names with validation inside the tool.
• Expand descriptions to 100-200 chars with WHEN/WHY context. E.g., 'List all stored procedures in a database. Call this first to discover available procedures before invoking sql_call_procedure with a specific name.'
• Add error recovery guidance to write tools (sql_execute, fabric_create_measure, etc.). E.g., 'If the query fails with a syntax error, call sql_search_schema to validate table/column names. If permission denied, contact the database admin.'
• Add pagination support (limit, offset, cursor) to discovery tools (sql_search_schema, sql_list_procedures, pbi_get_schema, fabric_get_schema) and document max result limits in descriptions.

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

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