Three read-only tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are minimal (10-20 chars baseline), parameter descriptions lack actionable detail, and output schemas are undocumented. No error recovery guidance. Tool naming follows verb_noun pattern (list_, describe_, read_) which is good, but descriptions do not explain WHEN to use each tool or dependencies between them. Security is sound (read-only enforcement, parameterized queries), but composition lacks pagination and result limits are hardcoded without documentation.

• Document output schemas for all three tools. Example for list_table: 'Returns {success: boolean, message: string, tables: string[]}'. Example for read_data: 'Returns {success: boolean, message: string, data: object[], recordCount: number}'.
• Add result limit and pagination guidance to read_data description: 'Executes a SELECT query (max 10,000 rows). For larger datasets, use WHERE or LIMIT clauses to paginate.'
• Replace example values in parameter descriptions with formal constraints. For list_table.schemas, use an enum of actual schema names or a pattern constraint (e.g., 'alphanumeric, 1-128 chars').
• Enhance error messages with recovery hints. E.g., 'Query must start with SELECT. Did you mean to use describe_table() to explore the schema first?' or 'Query contains forbidden keyword: INSERT. Only SELECT queries are allowed.'
• Add tool composition hints to descriptions. E.g., list_table: 'Call this first to discover available tables. Then use describe_table() to inspect structure before querying with read_data().'
• Document the tableName parameter format more clearly in describe_table: 'Table name with optional schema prefix (e.g., "Owner" or "dbo.Owner"). If schema is omitted, searches all schemas.'