MCP vs REST: Khi nào nên dùng cái nào cho AI agent?

REST là thứ bạn chọn khi một developer người viết tích hợp. MCP là thứ bạn chọn khi một AI agent thực hiện điều đó tại runtime. WorkOS nói ngắn gọn: “REST API phục vụ developer. MCP phục vụ AI agent.” Sự khác biệt về loại bên gọi dẫn đến mọi sự đánh đổi kiến trúc — stateful vs stateless, discovery, giao tiếp hai chiều, và độ sâu hệ sinh thái.

Bài này dành cho backend và full-stack developer đang quyết định cách expose service cho AI agent, hoặc đang đánh giá xem có nên đặt MCP lên trên REST API hiện có không.

Sự phân kỳ về kiến trúc

REST được định nghĩa trong RFC 9110 (tháng 6 năm 2022) là “giao thức cấp ứng dụng stateless cho hệ thống thông tin phân tán, cộng tác, hypertext.” Mỗi request mang theo mọi thứ server cần để hiểu nó. Không session. Không thương lượng. Client phải biết trước các endpoint — đó là hợp đồng.

MCP (Model Context Protocol, phiên bản spec 2025-11-25) thì ngược lại. Spec mô tả nó là “giao thức phiên stateful tập trung vào trao đổi context và phối hợp sampling.” Nó chạy trên JSON-RPC 2.0, vay mượn nhiều từ thiết kế Language Server Protocol, và định nghĩa ba vai trò: Host (ứng dụng LLM như Claude Desktop hay Cursor), Client (connector duy trì một phiên cho mỗi server), và Server (nhà cung cấp khả năng).

Chiều	REST	MCP (2025-11-25)
Trạng thái	Stateless	Stateful, theo phiên
Discovery	Tài liệu OpenAPI tĩnh (lúc build)	`tools/list` RPC (tại runtime)
Schema	OpenAPI/Swagger	JSON Schema 2020-12, theo tool, sống
Hướng	Request-response một chiều	Hai chiều (server có thể gọi LLM, yêu cầu input từ user)
Xác thực	Linh hoạt (API key, OAuth 2.0, custom)	OAuth 2.1 + PKCE, bắt buộc với HTTP transport
Caching	Native (Cache-Control, ETag)	Không được định nghĩa
Tác vụ chạy lâu	Custom polling/webhook	Native Tasks primitive (thử nghiệm)
Hỗ trợ browser	Native	Cần thư viện MCP client
Horizontal scaling	Bất kỳ node nào, bất kỳ request nào	Cần session affinity
Quản trị	IETF	Linux Foundation / AAIF (tháng 12 năm 2025)

MCP chiếm ưu thế ở đâu

Khám phá công cụ tại runtime

Đây là lợi thế cấu trúc rõ ràng nhất của MCP. AI agent không biết danh mục endpoint của bạn theo cách developer biết. Với REST, ai đó đọc tài liệu và hard-code các lời gọi. Với MCP, agent gửi tools/list khi bắt đầu phiên và nhận về danh mục sống — JSON Schema 2020-12 machine-readable cho từng tool, bao gồm ý nghĩa mỗi tham số và liệu tool có phải read-only hay destructive không.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": { "cursor": "optional-cursor-value" }
}

Khi bộ tool thay đổi, server đẩy notifications/tools/list_changed. Client fetch lại. Không còn tài liệu cũ để agent đọc nhầm.

Điều này cũng giải quyết vấn đề N×M adapter. Không có chuẩn giao thức, M tool kết nối với N AI client cần M×N tích hợp custom. MCP rút gọn thành M server + N client, tất cả dùng chung giao thức — cái ẩn dụ USB mà cộng đồng hay dùng.

Phiên làm việc nhiều lượt và giao tiếp hai chiều

REST luôn do bên gọi khởi tạo. Một LLM có thể gọi API của bạn, nhưng API của bạn không bao giờ có thể hỏi lại LLM bất cứ điều gì.

Phiên MCP đi cả hai chiều. Trong một phiên đang hoạt động, server có thể yêu cầu sampling (nhờ LLM thực hiện một inference call), yêu cầu elicitation (nhờ user cung cấp structured input giữa workflow), và đẩy thông báo tiến độ. Server trở thành người tham gia chủ động trong vòng lặp agent, không phải endpoint dữ liệu bị động.

Tác vụ chạy lâu

MCP 2025-11-25 có một Tasks primitive thử nghiệm với state machine rõ ràng: working → input_required ↔ working → completed / failed / cancelled. Một lời gọi tool trả về taskId ngay lập tức. Agent poll tasks/get hoặc block trên tasks/result. Trạng thái input_required cho phép server tạm dừng và hỏi user thêm thông tin trước khi tiếp tục.

Tự xây cái này trên REST và bạn đang dựng webhook infrastructure, polling loop, và custom state storage. MCP chuẩn hóa pattern đó.

Xác thực được chuẩn hóa

MCP bắt buộc OAuth 2.1 với PKCE (S256 bắt buộc) cho HTTP transport. Access token đi trong header Authorization: Bearer, không bao giờ trong URI query string. Resource Indicators (RFC 8707) là bắt buộc. Với các workflow agentic cần ủy quyền credential qua ranh giới tool, sự đồng nhất này tiết kiệm thời gian engineering thực sự.

REST chiếm ưu thế ở đâu

Caching

HTTP caching đã 30 năm tuổi. Cache-Control, ETag, Last-Modified, Vary — mọi CDN, proxy, và browser đều hiểu những thứ này natively. Các read API lưu lượng lớn (danh mục sản phẩm, dashboard, bất cứ thứ gì phục vụ traffic ở scale) có thể giảm tải backend đáng kể qua cache header chuẩn. MCP không định nghĩa ngữ nghĩa caching ở tầng giao thức.

Browser client

Mọi browser đều hỗ trợ HTTP. Gọi REST endpoint từ JavaScript không cần dependency nào. MCP cần TypeScript SDK (v1.29.0, tháng 3 năm 2026) hoặc Python SDK. Đó không phải lựa chọn trong môi trường browser nơi bạn không thể cài thư viện.

Horizontal scaling stateless

Tính stateless của REST nghĩa là bất kỳ node nào được load-balanced đều xử lý được bất kỳ request nào. Phiên MCP cần session affinity — sticky routing hoặc shared session store qua các node. Ở throughput cao, cả hai phương án đều không miễn phí.

Tích hợp có thể đoán trước cho developer

Khi một người viết tích hợp — không phải LLM — REST là công cụ phù hợp. Bạn biết endpoint, method, tham số. Không cần suy luận trong call path. REST là cách bạn xây dựng tích hợp đáng tin cậy, có thể test, được kiểm soát phiên bản.

Độ sâu hệ sinh thái

API gateway (Zuplo, Kong), test client (Postman, HTTPie), monitoring stack, công cụ tài liệu — tất cả đều coi REST là mặc định. Hệ sinh thái của MCP đang phát triển nhanh (97 triệu lượt tải SDK hàng tháng, 10.000+ server tính đến tháng 11 năm 2025, Linux Foundation quản trị từ tháng 12 năm 2025), nhưng không thể sánh với ba thập kỷ đi trước của REST.

Retry idempotent

RFC 9110 §9.2.2 định nghĩa GET, PUT, và DELETE là safe hoặc idempotent — một request thất bại có thể retry an toàn. MCP không có hợp đồng retry tương đương, nên bên gọi phải tự quyết định liệu một tool execution thực hiện một phần có an toàn để chạy lại không.

Góc nhìn hybrid: không phải buộc phải chọn một ở tầng network

Streamable HTTP transport của MCP (chuẩn hiện tại từ tháng 3 năm 2025, thay thế thiết kế HTTP+SSE dual-connection bị deprecated từ năm 2024) là HTTP ở tầng wire — JSON-RPC 2.0 payload qua HTTP POST và GET chuẩn. Một endpoint xử lý cả hai kiểu request. Server trả về application/json cho response đơn và text/event-stream cho streaming. MCP-Session-Id trong header quản lý trạng thái phiên. Last-Event-ID cho phép resume stream sau khi mất kết nối.

Hệ quả thực tế: traffic MCP và REST có thể dùng chung API gateway, TLS termination, và WAF. Cloudflare Workers hỗ trợ createMcpHandler từ Agents SDK natively; infrastructure hiện tại có thể phục vụ cả hai loại client mà không cần đường mạng riêng. “MCP vs REST” phần nào là một sự đối lập giả ở tầng transport — chính xác hơn thì đó là câu hỏi nên trình bày hợp đồng giao thức nào trên HTTP.

Migrate từ REST sang MCP

Nếu bạn có REST API hôm nay và muốn expose nó cho AI agent, sai lầm phổ biến là ánh xạ 1:1. Vấn đề GitHub API minh họa tại sao: 600+ REST endpoint, ánh xạ trực tiếp sang MCP tool, tạo ra không gian quyết định khổng lồ cho LLM. Báo cáo production của StackOne đo được: 50 tool tiêu tốn 100.000+ token chỉ cho định nghĩa tool, trước khi bất kỳ cuộc trò chuyện có nghĩa nào bắt đầu.

Cách tiếp cận đúng:

Sinh stub từ OpenAPI — dùng codegen làm điểm khởi đầu, không phải điểm kết thúc
Cắt giảm quyết liệt — giữ lại những tool riêng biệt và có liên quan đến quyết định trong workflow agent; gộp các endpoint low-level tương tự
Viết lại mô tả cho suy luận LLM — tài liệu REST giải thích tham số làm gì; mô tả MCP nên nói với model khi nào và tại sao gọi tool
Xây abstraction cấp cao hơn — thay ba lời gọi REST tuần tự bằng một MCP tool xử lý workflow nội bộ

langchain-mcp-tools v0.3.3 của LangChain (tháng 3 năm 2026, Python 3.11+) và OpenAI Agents SDK đều hỗ trợ MCP natively cho agent framework. Hạn chế đã biết của cả hai: chỉ kết quả dạng text. Resources, Prompts, và Sampling cần tích hợp SDK trực tiếp.

Hiệu năng: những con số thực tế cho thấy gì

Không có benchmark latency MCP-vs-REST trực tiếp từ nguồn chính. Những gì có:

Benchmark MCP implementation (tmdevlab, 3.9 triệu request, 50 concurrent user, k6 load testing): Java và Go đạt ~1.624 RPS ở latency trung bình 0.85ms; Node.js là 559 RPS ở 10.66ms; Python (FastMCP 2.12.0) là 292 RPS ở 26.45ms.
Ước tính production của WorkOS: MCP thêm khoảng 100–300ms overhead mỗi lần gọi so với tích hợp REST custom trực tiếp — chi phí của JSON-RPC hop trên lời gọi API nền.

Ngôn ngữ bạn chọn cho MCP server quan trọng hơn hầu hết mọi người nghĩ. Implementation Go và Java nhanh hơn ~5× so với Node và ~30× so với Python ở tầng MCP. Để hiểu toàn bộ bức tranh kinh tế khi vận hành AI agent trong production — không chỉ latency mà cả chi phí API, hạ tầng, và con người — xem phân tích chi phí vận hành đội AI agent năm 2026.

Bảo mật: những gì bạn thực sự phải đối mặt

Thiết kế stateful, tin cậy cao của MCP mở ra các bề mặt tấn công mà mô hình stateless của REST không có. Các sự cố đã được ghi nhận:

Tháng 4 năm 2025: Nhà nghiên cứu công bố phân tích về prompt injection qua mô tả tool, lạm dụng quyền tool, và tấn công tool giả mạo
Tháng 6 năm 2025: CVE-2025-49596 — RCE nghiêm trọng qua tấn công chuỗi cung ứng, đã vá
Sự cố Asana MCP: Tấn công “Confused Deputy” — server cache context mà không xác minh lại identity tenant qua ranh giới phiên

Spec 2025-11-25 bắt buộc các biện pháp giảm thiểu: server phải validate header Origin và trả về 403 khi origin không hợp lệ; phải bind vào localhost theo mặc định; access token không được xuất hiện trong URI query string. Tuy nhiên, một thread Hacker News năm 2025 mô tả 95% server MCP cộng đồng là chất lượng thấp, với mô tả tool gây hiểu nhầm hoặc nguy hiểm.

Nếu bạn triển khai MCP trong production, hãy coi chất lượng mô tả tool là bề mặt bảo mật, không chỉ là chi tiết UX.

Ma trận khuyến nghị

Tình huống	Dùng	Lý do
AI agent khám phá tool tại runtime	MCP	`tools/list` + push notification khi thay đổi
Phiên nhiều lượt với input user giữa workflow	MCP	Tasks primitive, trạng thái `input_required`, elicitation
Tác vụ async chạy lâu cần theo dõi trạng thái	MCP	State machine Tasks native
3+ AI client gọi cùng một bộ tool	MCP	Loại bỏ vấn đề N×M adapter
Developer người viết code xác định	REST	Endpoint đã biết, không cần suy luận LLM trong call path
Đọc lưu lượng lớn có caching	REST	Cache header HTTP native, thân thiện CDN
UI trên browser gọi backend	REST	Không cần thư viện client
REST API hiện có với AI dùng thỉnh thoảng	REST + MCP wrapper	Thêm MCP server lên trên; không cần viết lại
Audit trail doanh nghiệp, gateway hiện có	REST	Hệ sinh thái 30 năm, tooling compliance sẵn có
Horizontal scaling throughput cao	REST	Stateless = bất kỳ node nào xử lý bất kỳ request nào

Verdict

Dùng MCP khi bên gọi là LLM cần suy luận về việc gọi gì. Dùng REST khi bên gọi là developer đã biết.

Với hầu hết team hiện nay: giữ REST API. Xây một MCP server mỏng lên trên, được thiết kế xung quanh tool cấp tác vụ thay vì cấp resource. Bạn có được khả năng tương thích AI agent mà không cần viết lại hệ thống đang chạy tốt. Railway, Cloudflare Workers, và các platform tương tự đều xử lý Streamable HTTP deployment mà không cần infrastructure đặc biệt.

Nếu bạn đang xây AI tooling từ đầu và người dùng chính sẽ là LLM, hãy bắt đầu với MCP. Runtime discovery, giao tiếp hai chiều, và xác thực được chuẩn hóa mang lại lợi ích ngay lập tức. Claude Code và Cursor đều hỗ trợ MCP natively nếu bạn muốn một môi trường thử nghiệm mà không cần dựng đầy đủ agent framework. Xem hướng dẫn xây dựng MCP server cho Claude Code để bắt đầu trong 30 phút.

Lưu ý

Tasks primitive của MCP vẫn là thử nghiệm trong 2025-11-25 — kiểm tra trạng thái spec hiện tại trước khi xây workflow production trên đó.
Các benchmark tmdevlab so sánh các MCP implementation với nhau, không phải với REST. Con số 100–300ms overhead của WorkOS là ước tính production, không phải thử nghiệm có kiểm soát.
Các liên kết Zuplo, Cloudflare Workers, LangChain, Claude Code, Cursor, và Railway là liên kết affiliate — xem disclosure ở trên.
Chất lượng MCP server biến thiên rất lớn. Đánh giá kỹ mô tả tool trước khi tin tưởng server của bên thứ ba trong workflow agent production.