Critical failure: The single tool 'dynamic_tools_from_connectors' is inferred from runtime behavior, not explicitly registered with schemas in source. No input schema visible. Description is generic (67 chars) and does not explain what parameters the tool accepts, what it returns, or when to call it. Tool names and schemas are generated dynamically at runtime by connector introspection, this means tool definitions are NOT statically verifiable. The server exposes database schema as tools, but without explicit parameter documentation, type constraints, or output schemas visible in code, LLMs cannot reliably invoke these tools. This violates the core principle that tool definitions must be self-documenting and statically analyzable.

• Explicitly register each connector's tools with full JSON Schema input definitions. For SQL connectors, register tools like 'query_table', 'list_tables', 'describe_table' with documented parameters (table_name, columns, limit, offset, where_clause) and output schemas.
• For MongoDB connector, register tools like 'find_documents', 'aggregate_collection', 'list_collections' with explicit parameter schemas (collection, filter, projection, limit) and return type documentation.
• Add per-parameter descriptions explaining format, constraints, and examples. E.g., 'table_name (string, required): Name of the SQL table to query. Must match schema introspection results.' Avoid example values; use enums or patterns instead.
• Document output schemas for each tool. E.g., 'Returns array of objects with fields matching the table schema, plus _id and _timestamp metadata. Capped at 100 rows; use offset/limit for pagination.'
• Implement error recovery guidance. E.g., 'If table not found, call list_tables() first to discover available tables.' This follows the recovery-guide pattern and prevents dead-end agent states.

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

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