Three read-only tools with basic schemas and descriptions. All tools have input schemas with typed parameters and descriptions, meeting minimum requirements. However, descriptions are terse (10-80 chars), lacking context on WHEN to use each tool or dependencies between them. Output schemas are undocumented, LLMs cannot plan downstream calls. No error handling guidance. Tool naming is clear (verb_noun pattern) but lacks composition hints for multi-step workflows.

• Document output schemas for all three tools. Example: list_classes returns {classes: [{name: string, binding: string}]}. describe_schema returns {tables: [{name: string, columns: [{name: string, type: string}]}]}.
• Expand tool descriptions to 100-200 chars explaining WHEN to use each tool and dependencies. E.g., 'Call list_classes first to discover available Durable Object bindings. Then use describe_schema to inspect a specific instance's SQLite schema before querying.'
• Add error recovery hints to describe_schema and execute_read_query. E.g., 'If class_name is invalid, call list_classes to see available bindings. If instance name is not found, verify the name or hex ID format.'
• Replace example values in parameter descriptions with formal constraints. Change 'e.g. userId' to 'alphanumeric string, 1-255 chars' and '64-char hex from dashboard' to 'exactly 64 hexadecimal characters'.
• Implement server-side SQL validation in execute_read_query to reject non-SELECT queries (UPDATE, DELETE, INSERT, DROP, etc.). Return clear error: 'Only SELECT, EXPLAIN, and WITH queries are allowed. Attempted: <detected_statement_type>'.