atlas-mcp-server

Failure modes

• • Neo4j connection failures: Code shows basic Neo4j driver usage but initialization happens at server startup. If Neo4j is unavailable, all database operations will fail with generic errors. No retry logic or circuit breakers visible.
• • Empty/null input handling: Many tools accept optional parameters with .optional() in Zod schemas but don't always validate business logic constraints (e.g., empty arrays after filtering). Could lead to confusing empty results.
• • Unicode/special characters: No explicit sanitization of user inputs before Neo4j queries. Cypher queries appear to use parameter binding (good) but string concatenation might exist in complex query builders.
• • Concurrent request handling: Server uses McpServer SDK which should handle concurrency, but Neo4j session management isn't visible in excerpts. Potential for connection pool exhaustion under load.
• • Error response inconsistency: McpError.toResponse() returns structured errors, but many catch blocks return plain strings via createToolResponse(). Some errors will be parseable JSON, others plain text.
• • Resource cleanup on timeout: No explicit timeout handling visible. Long-running Neo4j queries could hang indefinitely. HTTP transport has some timeout awareness but stdio does not.
• • Malformed JSON inputs: Zod validation catches type errors but error messages might not always be user-friendly. JsonParser has special handling for <think> blocks but could fail on deeply nested partial JSON.
• • Missing required parameters: Zod handles this well with clear validation errors, but some tools have complex interdependencies (e.g., project ID references) that might fail later in execution.
• • File system operations: Backup operations use fs.promises with basic error catching but no validation of path traversal attacks beyond startsWith() checks. BACKUP_FILE_DIR creation might fail silently.
• • HTTP transport CORS: CORS configuration uses MCP_ALLOWED_ORIGINS but implementation details not shown. Might reject valid requests if not configured properly.
• • Rate limiting: Configured in config (windowMs, maxRequests) but actual middleware implementation (createToolMiddleware) is commented out/missing. Rate limiting appears non-functional.
• • Permission checks: requiredPermission metadata exists but checkPermission function is explicitly commented out with warnings. Authorization appears to be disabled.
• • Graceful degradation: Some operations like database clean require confirmation codes, but if the code generation fails, the operation becomes unusable with no alternative path.