Server has 6 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-100 chars, mostly adequate) and input schemas with type definitions. However, output schemas are undocumented, LLMs cannot predict return structures. Parameter descriptions are minimal (1-2 words). No error handling guidance, no recovery paths, no pagination for list results. Tool naming is clear (verb_noun pattern), but composition issues exist: run_sql_plus_plus_query is overly generic and accepts arbitrary SQL, creating security and validation risks. Missing idempotency guarantees, rate limiting, and permission gates for destructive operations (delete_document_by_id, upsert_document_by_id).

• Document output schemas for all tools. Add a 'returns' field to each tool definition specifying field names, types, and descriptions. E.g., get_document_by_id returns {id: string, content: object, metadata: {created_at: ISO8601, updated_at: ISO8601}}.
• Restrict run_sql_plus_plus_query: add a 'query_type' enum parameter (READ_ONLY, WRITE, SCHEMA) and validate against read_only_query_mode setting. Cap result sets at 100 rows and document this limit in the description.
• Add dry_run parameter to upsert_document_by_id and delete_document_by_id. Return a preview of changes without committing. Document idempotency: 'Calling this twice with the same document_id and content is safe, the second call succeeds with no change.'
• Expand parameter descriptions to 50-100 chars each. Include format hints: 'scope_name: Name of the scope (alphanumeric, 1-255 chars). If unsure, call get_scopes_and_collections_in_bucket first.'
• Wrap exceptions in structured error responses: {error: string, code: string, recovery: string}. E.g., 'error: "Scope not found", code: "SCOPE_NOT_FOUND", recovery: "Call get_scopes_and_collections_in_bucket to list available scopes."'

Inferred effective spec: <=2025-11-25.

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