Zenii MCP server has three tools with partial schemas and moderate descriptions. All three tools are explicitly registered with JSON Schema input definitions visible in source (agent_self_tool.rs, channel_tool.rs, config_tool.rs). However, critical gaps exist: parameter descriptions are sparse or missing, output schemas are undocumented, error handling lacks recovery guidance, and tool naming could be clearer. The server exposes sensitive operations (send messages, update config, modify agent rules) without documented permission models or confirmation patterns. Descriptions average ~150 chars (within baseline 194), but parameter annotations are minimal, most params lack descriptions or have trivial text ('The operation to perform'). No evidence of idempotent operation markers, pagination support, or structured error responses with actionable recovery steps.

• Rename tools to verb-first: 'agent_notes' → 'manage_agent_notes', 'channel_send' → 'send_channel_message', 'config' → split into 'get_config' and 'update_config'.
• Add complete output schemas for each tool. Document response fields and types. E.g. 'agent_notes learn' returns {success: bool, rule_id: int, category: string}; 'channel_send list' returns {channels: [{name: string, status: string, last_message_at: string}], total: int}.
• Add parameter descriptions for every parameter. Specify format, constraints, and examples. E.g. 'message (string, 1-4000 chars): Content to send. Supports markdown.', 'recipient (string, Telegram chat_id or Slack user_id): Target recipient. If omitted for send action, resolves to the single known contact.',
• Add output schema as a field in tool definition. Use JSON Schema to document response structure. Include pagination (total, next_cursor) for list operations.
• Implement error handling with actionable recovery guidance. E.g. 'channel_send send: {error: "User 'alice' not found in known contacts. Available: bob, charlie. Did you mean bob?", recovery: "Call contacts action to list all, or provide exact recipient ID."}'.
• Add confirmation pattern for destructive actions. 'agent_notes forget' and 'channel_send send' should return a confirmation token on dry-run, and require that token on actual execution. E.g. 'POST channel_send {action: "send", ..., confirm: "<token>"}' or use Multi-Round-Trip Request (input_required).
• Document 'config' whitelisted keys as an enum constraint, or add a 'describe_config' discovery tool that lists valid keys, types, and constraints. E.g. 'describe_config returns {keys: [{name: "api_timeout", type: "int", min: 1, max: 300}, ...]}.'.