sql-mcp-server provides 10 tools with complete JSON Schema definitions and descriptions. Naming follows verb_noun convention (read_records, create_record, delete_record). However, descriptions are minimal (10-50 chars), parameter descriptions lack actionable constraints (no enums, ranges, or format guidance), and output schemas are not documented. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound, tools are single-responsibility and chainable via transaction IDs. Security: transaction IDs are passed as parameters (acceptable for stateless operations), but no audit logging or permission gates visible.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what it returns. E.g., 'Read records from an entity with optional filtering, field projection, and cursor-based pagination. Use this to fetch data; for aggregations, use aggregate_records. Returns an array of records and a next_cursor for pagination.'
• Add enum constraints to filter 'op' parameter. Document valid operators: 'eq', 'ne', 'gt', 'lt', 'gte', 'lte', 'in', 'like'. Include an example: 'op: "eq" for equality, "like" for pattern matching.'
• Document output schemas for all tools. E.g., read_records returns {records: [{id, ...fields}], next_cursor: string|null, total_count: int}. This enables LLMs to chain tools correctly.
• Add tool annotations to all tools. Mark read_records and describe_entities with readOnlyHint=true; mark delete_record with destructiveHint=true; mark create_record and update_record with idempotentHint=true (if transaction-scoped).
• Clarify execute_entity: document available procedures, their signatures, and return types. Or split into separate tools (execute_read_procedure, execute_write_procedure) with explicit risk levels.