Both tools have minimal descriptions (under 100 chars) and critically, NO input schemas are defined. Tool names follow verb_noun convention (get_*), which is correct, but descriptions lack actionable context (when to use, what it returns, prerequisites). No parameter descriptions exist because no parameters are defined. No output schemas are documented. Error handling is absent, no recovery guidance, no categorization, no actionable error messages. The tools are read-only (good security posture) but lack pagination, result limits, and structured output documentation.

• Add explicit JSON Schema input definitions to both tools. Even if no parameters are required, declare `{"type": "object", "properties": {}, "required": []}` to signal intentional zero-parameter design.
• Expand descriptions to 150-250 chars. Include: what data is returned (field names, structure), when to call this tool vs the other, and any prerequisites (e.g., 'Requires MongoDB running on localhost:27017'). Example: 'Retrieves all employee records from MongoDB. Returns array of {id, name, email, department}. Use this to list staff; use get-students-data for student records.'
• Document output schema in tool description or as a separate schema field. Specify: array of objects, field names, types (string, number, date), and whether fields are always present. Example: 'Returns: [{id: string, name: string, email: string, department: string, hireDate: ISO8601}]'.
• Add pagination support: accept optional `limit` (default 20, max 100) and `offset` (default 0) parameters. Return `{data: [...], total: number, hasMore: boolean}` to enable agents to fetch large datasets incrementally.
• Wrap MongoDB calls in try-catch with actionable error messages. Example: 'MongoDB connection failed: Is the server running on localhost:27017? Check connection string and retry.' Categorize errors as retryable (connection timeout) vs fatal (auth failure).