Local vs Remote MCP server: hiểu stdio, SSE và Streamable HTTP qua ví dụ thực tế và chọn transport phù hợp

Bạn viết một MCP server chạy ngon trên máy mình qua stdio, deploy lên server thì client không kết nối được. Hoặc ngược lại: copy config SSE từ tutorial cũ, server mới reject vì đã chuyển sang Streamable HTTP. Đây là vấn đề chọn sai transport. MCP có 3 lựa chọn (stdio, HTTP+SSE đã deprecated, Streamable HTTP) và mỗi cái phục vụ ngữ cảnh khác nhau. Bài này giải thích cơ chế từng transport, lý do Anthropic deprecated SSE từ tháng 3/2025, và cách bridge local client với remote server bằng mcp-remote.

MCP transport là gì và vì sao bạn cần phân biệt

Model Context Protocol (MCP) là một tiêu chuẩn mở được Anthropic giới thiệu vào ngày 25 tháng 11 năm 2024, cho phép các tác nhân AI kết nối với công cụ và tài nguyên bên ngoài [F1]. Sau đó, tiêu chuẩn này được chuyển giao cho Linux Foundation quản lý [F1]. Hiểu đơn giản, MCP là cầu nối giúp các AI như Claude tương tác với thế giới bên ngoài.

Transport (giao thức truyền tải) là lớp chịu trách nhiệm vận chuyển các thông điệp giữa client (như Claude Desktop, Cursor, Windsurf) và MCP server. Việc chọn đúng transport rất quan trọng vì nó ảnh hưởng trực tiếp đến cách bạn triển khai, xác thực và mở rộng hệ thống của mình.

Hiện tại, có ba loại transport chính trong MCP. Đầu tiên là stdio, dành cho các kết nối cục bộ [F2]. Tiếp theo là HTTP + SSE, từng được sử dụng nhưng giờ đã lỗi thời [F2]. Cuối cùng là Streamable HTTP, được thiết kế cho các máy chủ đám mây hiện đại [F2]. Việc phân biệt rõ các loại transport này giúp bạn tránh những sai lầm khi triển khai và bảo mật. Ví dụ, stdio có thể dẫn đến thực thi mã từ xa (RCE) nếu không được quản lý cẩn thận [F3].

Các máy chủ MCP từ xa cho phép tác nhân AI truy cập kiến thức được chia sẻ và tài nguyên trên đám mây, tổng hợp thông tin từ nhiều nguồn [F4]. Điều này giúp cung cấp quyền truy cập vào dữ liệu và dịch vụ giống như trong môi trường sản xuất [F4].

stdio: transport mặc định cho local MCP server

stdio (standard input/output) là transport mặc định khi MCP server chạy cùng máy với client [F2]. Cơ chế đơn giản: client như Claude Desktop, Cursor, hay Cline spawn server thành một process con. Sau đó client đẩy message JSON-RPC 2.0 qua stdin của process và đọc response từ stdout. Stderr dành cho log debug. Không có socket, không có port, không có HTTP layer ở giữa — chỉ là 2 file descriptor mà OS cấp khi fork process.

Vì giao tiếp qua pipe của OS nên latency rất thấp và không cần auth token hay TLS. Server chạy local nên truy cập filesystem, git repo, hay SQLite database trên máy bạn không tốn round-trip network. Đây là lý do các server starter pack như filesystem, git, sqlite, time đều ship dạng stdio. Bạn cần đọc file local, query DB local, hoặc gọi git command — không cần expose ra ngoài máy.

Config trong claude_desktop_config.json chỉ cần khai báo command và args. Claude Desktop spawn process khi khởi động app, kill khi đóng app. Ví dụ cài server filesystem cho thư mục code:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/me/code"
      ]
    }
  }
}

Hạn chế lớn nhất của stdio: chỉ phục vụ 1 client trên 1 máy. Không share state giữa nhiều dev trong team, không scale horizontal, không dùng được trong web app. Mỗi máy phải tự cài, tự update version, tự config path. Nếu cả team cần xài cùng một MCP server, hoặc bạn muốn deploy server lên Cloud Run / Railway cho người ngoài gọi vào, stdio không đáp ứng được. Lúc đó phải đổi sang Streamable HTTP — phần kế tiếp sẽ nói rõ.

Một điểm về bảo mật ít người để ý: stdio thực thi bất kỳ lệnh OS nào nó nhận được mà không có cơ chế sanitization hay giới hạn execution, và điều này có thể dẫn tới remote code execution [F3]. Audit từ Ox Security cảnh báo rủi ro này tồn tại trên nhiều MCP server stdio đang được public [F3]. Khi cài server lạ qua npx hay pip, đọc source code trước. Default trust model của stdio là tin tuyệt đối vào binary mà bạn config — chấp nhận rủi ro thì OK, nhưng đừng install bừa từ blog không rõ nguồn.

HTTP+SSE: transport remote thế hệ đầu (đã deprecated)

Trước khi Streamable HTTP ra đời, HTTP+SSE là phương thức truyền tải remote được sử dụng cho MCP. Giao thức này đã được Anthropic giới thiệu vào ngày 25 tháng 11 năm 2024, sau đó được Linux Foundation quản lý [F1]. Tuy nhiên, HTTP+SSE hiện đã lỗi thời và không còn được khuyến nghị sử dụng [F2].

Cơ chế hoạt động của HTTP+SSE yêu cầu hai endpoint riêng biệt: một endpoint POST /messages để gửi request từ agent đến server, và một endpoint GET /sse để server push dữ liệu về cho agent. Điều này tạo ra một số vấn đề đáng kể. Đầu tiên, việc phải duy trì hai kết nối song song khiến việc quản lý và cân bằng tải trở nên phức tạp.

Thứ hai, SSE (Server-Sent Events) là giao thức một chiều, nghĩa là server chỉ có thể gửi dữ liệu đến client mà không thể nhận phản hồi trực tiếp trên cùng một kết nối. Điều này hạn chế khả năng tương tác hai chiều hiệu quả. Cuối cùng, logic xử lý tái kết nối (reconnection) khi mạng bị gián đoạn cũng rất phức tạp, ảnh hưởng đến độ tin cậy của hệ thống.

Mặc dù đã bị đánh dấu là deprecated trong các bản cập nhật sau này của MCP spec, bạn vẫn có thể gặp các server cũ còn sử dụng HTTP+SSE. Việc hiểu rõ cơ chế và hạn chế của nó sẽ giúp mình dễ dàng hơn trong việc debug và xử lý các vấn đề phát sinh.

Streamable HTTP: transport remote chuẩn hiện tại

Streamable HTTP là giao thức truyền tải được khuyến nghị cho các máy chủ MCP từ xa, thay thế cho HTTP+SSE đã lỗi thời [F2]. Giao thức này được thiết kế để phù hợp với môi trường đám mây hiện đại, đặc biệt là các nền tảng serverless như Cloudflare Workers hay Vercel.

Điểm đặc biệt của Streamable HTTP là nó chỉ sử dụng một endpoint duy nhất là `/mcp`. Client sẽ gửi yêu cầu POST đến endpoint này. Server có thể phản hồi bằng JSON thông thường hoặc dưới dạng stream SSE, tùy thuộc vào nhu cầu của tác nhân AI.

Ưu điểm của phương pháp này là khả năng hoạt động ở chế độ stateless, giúp việc triển khai và mở rộng quy mô dễ dàng hơn. Để duy trì ngữ cảnh giữa các yêu cầu, MCP sử dụng header `Mcp-Session-Id`. Điều này cho phép server nhận biết các tương tác liên quan đến cùng một phiên làm việc, ngay cả khi không lưu trữ trạng thái trên server.

Về bảo mật, Streamable HTTP hỗ trợ xác thực chuẩn thông qua OAuth 2.1 và bearer token trong header `Authorization`. Điều này đảm bảo rằng chỉ các tác nhân AI được ủy quyền mới có thể truy cập vào tài nguyên của server. Các máy chủ MCP từ xa giúp tác nhân AI truy cập kiến thức chia sẻ và tài nguyên đám mây, tổng hợp thông tin từ nhiều nguồn [F4].

Dưới đây là ví dụ về một yêu cầu POST đến `/mcp` với payload JSON-RPC và header session:

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_AUTH_TOKEN" \
  -H "Mcp-Session-Id: some-unique-session-id" \
  -d '{"jsonrpc": "2.0", "method": "tool_name", "params": {"arg1": "value1"}, "id": 1}' \
  https://your-mcp-server.com/mcp

Streamable HTTP rất phù hợp cho các trường hợp sử dụng như server chung cho cả team, môi trường multi-tenant (nhiều người dùng), hoặc khi cần tập trung log để audit. Nó cung cấp một giải pháp mạnh mẽ và an toàn để kết nối các tác nhân AI với các công cụ và dịch vụ bên ngoài.

Bridge local client với remote server bằng mcp-remote

Các công cụ AI như Claude Desktop, Cursor hay Windsurf hiện chỉ hỗ trợ giao thức stdio native để kết nối với MCP server. Điều này gây khó khăn khi bạn muốn kết nối chúng với một MCP server từ xa đã deploy trên cloud, vốn thường dùng Streamable HTTP [F2].

Để giải quyết vấn đề này, package `mcp-remote` đóng vai trò như một proxy Node.js. Nó giúp chuyển đổi giao tiếp giữa stdio (từ client cục bộ) và Streamable HTTP (với server từ xa) [F2].

Việc cài đặt `mcp-remote` rất đơn giản qua npx, không cần cài đặt global. Sau đó, bạn chỉ cần cấu hình client AI của mình để gọi `npx mcp-remote` với URL của remote server. Ví dụ, trong file `claude_desktop_config.json`, bạn có thể thêm cấu hình như sau:

{
  "mcp_server_command": "npx mcp-remote https://your-remote-server.com/mcp"
}

`mcp-remote` cũng tự động xử lý quy trình OAuth flow và lưu trữ token vào thư mục `~/.mcp-auth` của bạn. Điều này giúp bạn dễ dàng kết nối Claude Desktop tới các server mà team bạn đã triển khai trên cloud, cho phép các tác nhân AI truy cập kiến thức và tài nguyên đám mây được chia sẻ [F4].

Chọn transport nào: bảng so sánh và quyết định

Việc lựa chọn giao thức truyền tải phù hợp cho MCP server phụ thuộc vào nhu cầu cụ thể của bạn. MCP định nghĩa hai loại giao thức chính: stdio và Streamable HTTP [F2]. Trước đây, HTTP + SSE cũng được sử dụng nhưng đã lỗi thời [F2].

Đặc biệt lưu ý về bảo mật: giao thức stdio của MCP thực thi bất kỳ lệnh hệ điều hành nào nó nhận được mà không có cơ chế làm sạch, có thể dẫn đến thực thi mã từ xa (RCE) [F3]. Một cuộc kiểm toán của Ox Security đã phát hiện hơn 200.000 server AI agent bị ảnh hưởng bởi lỗ hổng này [F3]. Ngoài ra, các lỗ hổng prompt injection trong mcp-server-git trước ngày 8 tháng 12 năm 2025 cũng có thể cho phép kẻ tấn công thao túng trợ lý AI [F5].

Để đảm bảo an toàn, best practice là pin version của MCP server, validate chặt chẽ mọi input, và không bao giờ expose stdio server trực tiếp ra mạng.

Tóm lại: stdio cho local single-user, Streamable HTTP cho remote multi-tenant, còn HTTP+SSE chỉ giữ lại vì backward compat. Nếu bạn đang build MCP server mới, đi thẳng Streamable HTTP. Bài tiếp theo mình sẽ deep dive vào cách viết một remote MCP server có OAuth bằng TypeScript, nếu bạn cần expose tool nội bộ ra ngoài an toàn.