Tôi đã thử tái triển khai kali-mcp hiện có bằng Go.

Xin chào. Mình là sinh viên đại học đang theo học ngành an toàn thông tin.

Mình thường xuyên sử dụng kali-mcp cho các công việc tự động hóa pentest / kiểm thử lưu lượng / CTF, nhưng khi vận hành trong môi trường gắn đồng thời nhiều agent thì gặp hiện tượng nghẽn cổ chai, nên đã tự tái triển khai lại bằng Go.

GitHub: https://github.com/found-cake/kali-mcp-go

---

Cấu trúc và giới hạn của kali-mcp hiện có

Bản gốc được triển khai bằng Flask + Python, và lớp CommandExecutor có cấu trúc tạo subprocess.Popen cho mỗi request rồi khởi chạy thêm 2 daemon thread để đọc riêng stdout/stderr.

Với một agent đơn lẻ thì như vậy là đủ, nhưng khi nhiều request đồng thời dồn tới trong môi trường multi-agent, các vấn đề sau sẽ xuất hiện.

• Flask mặc định chỉ có một worker — các agent chặn lẫn nhau
• Overhead tạo process + thread cho mỗi request
• Agent hiểu nhầm độ trễ phản hồi là timeout nên retry cùng một tác vụ

---

Các thay đổi chính

Server

• Trước đây: Flask (mặc định một worker)
• Thay đổi: Fiber v3 / fasthttp — đồng thời hóa hoàn toàn

Thu thập output

• Trước đây: vòng lặp readline bằng 2 daemon thread
• Thay đổi: 2 goroutine + WaitGroup để đồng bộ, căn chính xác thời điểm thu thập stdout/stderr và xử lý không bị sót output

timeout/cancel

• Trước đây: process.wait(timeout=...) + kill cưỡng bức
• Thay đổi: dựa trên context — đóng chính xác cả pipe

File tạm Metasploit

• Trước đây: hardcode /tmp/mks_msf_resource.rc — có thể phát sinh race condition khi có request đồng thời
• Thay đổi: os.CreateTemp — xử lý an toàn với tên file duy nhất cho từng request

Hỗ trợ tshark

• Trước đây: không có
• Thay đổi: thêm endpoint chuyên dụng

---

Kiến trúc

Mình thay phần bên trong nhưng vẫn giữ nguyên cấu trúc 2 tầng như trước.

[AI Client]  →(MCP stdio)→  [mcp-client]  →(HTTP + Bearer token)→  [kali-server]  →(exec)→  [nmap, tshark, ...]