Gandi MCP demonstrates solid fundamentals: all 8 tools have clear verb-noun naming (list_*, get_*, add_*, update_*, delete_*, create_*), comprehensive descriptions (100-200 chars typical), and complete JSON Schema with type definitions and parameter descriptions. Input schemas are strict (additionalProperties: false). Error handling includes GandiError with user-facing messages and scrubbing. However, output schemas are not documented, LLMs cannot predict response structure. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Destructive operations (delete_record) lack confirmation/dry-run patterns. Parameter descriptions are good but could be more prescriptive about constraints (e.g., TTL range, glob pattern syntax). No pagination support despite list_domains and list_records potentially returning large result sets.

• Document output schemas for all tools. Add a comment or JSDoc block showing the response structure, e.g., 'Returns: { fqdn: string, status: string, registrar: string }[]' for list_domains.
• Add tool annotations to the MCP tool definitions. In server.ts, extend the Tool object with readOnlyHint (true for list_* and get_*), destructiveHint (true for delete_*), and idempotentHint (true for get_* and list_*).
• Implement a confirm_delete_record tool or add a dry_run parameter to delete_record. Require explicit confirmation before irreversible deletion to prevent agent mistakes.
• Add pagination to list_domains and list_records: introduce limit (default 20, max 100) and offset parameters; return total_count in response. Cap results to prevent context window exhaustion.
• Tighten parameter constraints: specify TTL range (e.g., 60 - 86400 seconds), document nameFilter glob syntax formally (e.g., 'POSIX glob: * matches any chars, ? matches one char'), and add minItems: 1 to values array in add_record and update_record.