Single tool 'query' has a clear, action-verb name and basic schema with type and description. However, the parameter description lacks format guidance (e.g., 'DuckDB SQL dialect' is vague, no mention of allowed operations, query size limits, or timeout behavior). No output schema is documented, LLMs cannot predict the structure of query results. Error handling is minimal: the code catches exceptions but returns generic 'Error executing tool' messages without recovery guidance. The tool lacks idempotency hints and does not document whether it supports read-only mode or has side effects. Descriptions are adequate (10 - 100 chars) but fall short of LLM-optimized guidance (50 - 200 chars baseline for A-grade tools). No tool annotations (readOnlyHint, destructiveHint) despite the server supporting read-only mode.

• Add output schema to tool definition: document that results are returned as formatted text/table. If structured output is possible, return JSON with 'columns', 'rows', 'row_count' fields.
• Enhance parameter description: 'SQL query (DuckDB dialect). SELECT queries only. Max 10,000 rows returned. Timeout: 30s. In read-only mode, mutations are blocked.'
• Implement structured error messages: catch specific exceptions (syntax errors, timeout, permission denied) and return actionable guidance: 'Query syntax error: {error_detail}. See DuckDB docs: https://duckdb.org/docs/sql/introduction'.
• Add tool annotation: set readOnlyHint=true in tool definition when server is started with --read-only flag, or document that the tool respects the read-only mode.
• Document result limits and pagination: if results exceed 10,000 rows, return first 10,000 and a note: 'Result truncated. Use LIMIT clause to fetch specific rows.' Add a 'limit' parameter to the query tool if feasible.

Inferred effective spec: 2026-07-28+.

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