The Nobulex MCP server has three tools with minimal schema and description quality. All three tools have descriptions present but critically lack parameter-level detail and output schema documentation. Tool names follow basic verb_noun conventions (readFile, writeFile, sendEmail) but descriptions are vague. Input schemas show only parameter names and types without proper constraints, enums, or validation guidance. No output schemas are documented. The server appears to be a proof-of-concept rather than production-ready. Parameter descriptions are superficial: 'The file path to read from /data' lacks guidance on format, length, allowed characters, or error cases. The sendEmail tool is particularly problematic, it only documents a 'to' parameter but provides no guidance on email body, subject, headers, MIME types, or failure modes. No tool shows evidence of error handling strategy, recovery guidance, or retryability classification.

• Document the full output schema for each tool. E.g., readFile: {content: string, encoding: string, size_bytes: number, last_modified: string (ISO 8601)}
• Expand readFile description to: 'Reads the complete contents of a text file from the /data directory. Returns file content as UTF-8 string. Max file size: 10MB. Paths are relative to /data and cannot contain '..' or symlinks for security. Returns error if file not found or permission denied.'
• Expand writeFile description to: 'Writes or overwrites a file in the /output directory. Paths are relative to /output. If the file exists, it will be overwritten, use carefully. Max file size: 100MB. Returns error if disk full or permission denied. Use an idempotent_key if this call might be retried.'
• Completely rewrite sendEmail with required parameters: {to: string (email, required), subject: string (required, max 255 chars), body: string (required, supports HTML and plaintext), cc?: string[] (optional), bcc?: string[] (optional), reply_to?: string (optional), idempotent_key?: string (UUID for deduplication if retried)} and document the response: {message_id: string, sent_at: ISO 8601 timestamp, status: 'queued|sent|failed'}
• Add explicit error guidance: readFile should document 'file_not_found' (retryable after creation), 'permission_denied' (non-retryable, check permissions), 'file_too_large' (non-retryable, file exceeds 10MB limit). Same pattern for writeFile and sendEmail.
• Define permission requirements and scope. E.g., 'readFile requires read:data permission. writeFile requires write:output permission. sendEmail requires send:email permission.'