Server has 5 tools with basic descriptions and minimal parameter documentation. Tool names follow verb_noun convention (read_query, write_query, list_views, describe_view, export_views_statements), which is good. However, descriptions lack depth and actionability. Most critically, input schemas are either empty objects {} or minimally documented. The read_query and write_query tools accept SQL strings with no validation guidance, format constraints, or error recovery hints. No output schemas are documented. Error handling is present but generic ('Error executing query'). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Composition is reasonable, tools are single-purpose, but parameter descriptions are sparse or absent.

• Add explicit input schemas with type definitions and descriptions for all tools. For read_query and write_query, document SQL constraints: 'SQL read query (SELECT only, max 10000 chars, 30s timeout). Supports Dolt SQL dialect.'
• Document output schemas for all tools. E.g., read_query returns {type: 'object', properties: {columns: [string], rows: [object], error?: string}}. This enables LLMs to extract and chain results.
• Add tool annotations: mark read_query with readOnlyHint=true, write_query with destructiveHint=true. This signals safety properties without requiring LLM inference.
• Enhance error messages with recovery guidance. E.g., 'API token required for write operations. Set via --api-token flag. Retry after configuration.' instead of generic 'Error: API token is required...'
• Add parameter descriptions for view_name in describe_view: 'Name of the view to describe (case-sensitive, must exist in database). Use list_views() first to discover available views.'