Server has 5 tools with basic schemas and descriptions, but significant gaps prevent production use. Tool names are clear (getCollections, getCollection, insertOne, deleteOne, aggregate), but descriptions lack depth on WHEN to use each tool and what distinguishes them. Parameter descriptions exist but are minimal (10-30 chars). Critical issue: no output schemas documented, LLMs cannot plan downstream calls. Error handling returns raw error strings with no recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Schemas use Zod but lack proper JSON Schema export with constraints. The aggregate tool's pipeline schema is overly permissive (z.any() for most fields) and does not enforce MongoDB operator semantics.

• Add explicit output schemas to all tools. E.g., getCollection should return {type: 'object', properties: {documents: {type: 'array', items: {type: 'object'}}, count: {type: 'number'}}}. Document what fields LLMs can expect.
• Replace raw error strings with structured error responses: {error: 'collection_not_found', message: 'Collection "users" does not exist.', suggestion: 'Call getCollections() to list available collections.'}
• Add tool annotations via mcpServer.tool() options: {readOnlyHint: true} for getCollections/getCollection/aggregate, {destructiveHint: true} for deleteOne, {idempotentHint: true} for insertOne.
• Expand parameter descriptions to 50-100 chars with format guidance. E.g., 'MongoDB query filter as JSON object (e.g., {status: "active", age: {$gt: 18}}). Omit for no filter.'
• Validate aggregate pipeline at runtime: reject stages with multiple operators, validate operator syntax, and return actionable errors like 'Invalid stage: {$match: ..., $group: ...} contains 2 operators; each stage must have exactly 1.'