Khi Anthropic lần đầu giới thiệu Model Context Protocol (MCP) vào tháng 11 năm 2024, nó giống như một món đồ chơi dành cho các developer chạy Claude Code trên terminal. Nhưng với việc dự án được chuyển giao cho Agentic AI Foundation (thuộc Linux Foundation), MCP đã rũ bỏ mác “vendor-lock-in” để trở thành một chuẩn mở (open standard) thực thụ cho toàn ngành.

Để triển khai MCP lên production, trước hết chúng ta phải hiểu rõ cấu trúc lõi và sự tiến hóa trong tầng Network Transport của nó.

1. Mổ Xẻ 5 Core Primitives

MCP sử dụng JSON-RPC 2.0 để giao tiếp. Nhưng thay vì để các lập trình viên tự do định nghĩa mọi thứ (như gRPC hay REST), MCP chuẩn hóa giao tiếp AI-to-Machine thành 5 “thực thể” cốt lõi (Primitives):

  1. Tools (Công cụ):

    • Bản chất: Là các hàm (functions) có thể thực thi, có mang side-effects (thay đổi trạng thái hệ thống).
    • Ví dụ: create_github_issue(), restart_kubernetes_pod().
    • Use case: Agent sử dụng Tools để “hành động” thay mặt người dùng.

  2. Resources (Tài nguyên):

    • Bản chất: Các data entities read-only (chỉ đọc) và idempotent.
    • Ví dụ: file:///var/log/syslog, postgres://db/schema.
    • Use case: Agent cần đọc tài liệu hoặc context để hiểu rõ vấn đề trước khi ra quyết định. Nó giống như việc “đính kèm file” vào prompt, nhưng được thực hiện tự động qua URI.

  3. Prompts (Mẫu câu lệnh):

    • Bản chất: Các templates được định nghĩa sẵn bởi Server, có chứa tham số (parameters).
    • Use case: Thay vì client phải tự nghĩ ra prompt, Server (được viết bởi domain experts) sẽ cung cấp prompt chuẩn. Ví dụ: một code_review_prompt có thể ép Agent phải kiểm tra memory leak trong C++.

  4. Sampling (Lấy mẫu ngược):

    • Bản chất: Đây là một Reverse Capability. MCP Server có quyền gửi request ngược lại cho LLM của Client để nhờ suy luận (generate completion).
    • Use case: Cực kỳ quan trọng trong các Agentic Workflow phức tạp, nơi Server cần một chút “trí thông minh” từ mô hình để quyết định bước tiếp theo mà không cần phơi bày toàn bộ logic cho Client.

  5. Roots (Gốc tài nguyên):

    • Bản chất: Các Base URIs định nghĩa security boundaries (ranh giới bảo mật).
    • Use case: Server nói cho Client biết “Bạn chỉ được quyền đọc các Resources nằm trong thư mục /app/data/ này thôi”.
graph TD
    A[AI Agent / LLM] <-->|JSON-RPC 2.0| B(MCP Server)
    
    subgraph Primitives
        B -->|Thực thi hành động| C[Tools]
        B -->|Đọc ngữ cảnh| D[Resources]
        B -->|Cung cấp template| E[Prompts]
        B -.->|Nhờ Agent suy luận| F[Sampling]
    end
    
    C --> G[(Database / API)]
    D --> H[Local Files]

2. Transport Evolution: Từ Local Đến Enterprise

Giao thức MCP hoàn toàn tách biệt với tầng Network Transport. Đây là một thiết kế thông minh, nhưng cũng là điểm gây nhầm lẫn nhiều nhất cho các hệ thống Enterprise.

Kỷ nguyên Dev: STDIO

Ban đầu, MCP được thiết kế để chạy dưới dạng Subprocess. Client sẽ khởi chạy Server process và nói chuyện qua Standard Input/Output (stdio).

  • Ưu điểm: Zero network latency, cấu hình đơn giản.
  • Khuyết điểm: Chỉ chạy được trên cùng một máy ảo (localhost). Khả năng mở rộng (Scaling) bằng 0. Hoàn toàn vô dụng trong mô hình Microservices phân chuyên.

Trạm trung chuyển: HTTP + SSE (Legacy Remote)

Để giải quyết bài toán mạng, cộng đồng đưa ra transport qua Server-Sent Events (SSE). Client gửi POST request, và nhận kết nối stream qua GET SSE.

  • Vấn đề: Rất nhiều proxy, API Gateways, và Load Balancers trong môi trường Enterprise cấu hình sai hoặc tự động drop các kết nối SSE sống lâu (long-lived connections). Việc duy trì trạng thái (stateful) qua SSE cực kỳ khó khăn khi scale ngang (Horizontal Pod Autoscaling).

2026 Standard: Streamable HTTP

Đến năm 2026, Streamable HTTP đã trở thành production standard. Nó giải quyết triệt để bài toán kiến trúc phân tán:

  • Stateless: Mỗi request đều chứa đủ context. Server không cần duy trì persistent TCP connection.
  • Load Balancer Native: Hoạt động hoàn hảo với Nginx, Envoy, ALB, hay bất kỳ ingress controller nào.
  • Horizontal Scaling: Bạn có thể có 100 instance của một MCP Server đằng sau Load Balancer, request từ Agent sẽ được route đến bất kỳ instance nào mà không bị lỗi mất kết nối.

3. MCP Server Cards: Khám Phá (Discovery) Không Cần Kết Nối

Một bài toán lớn trong Enterprise là: “Làm sao một Agent biết trong tổ chức có những tool gì đang tồn tại mà không cần thiết lập kết nối đến từng server một?”

Giải pháp chính là MCP Server Cards. Tương tự như .well-known/openid-configuration của OAuth, các MCP Server expose một file metadata tại /.well-known/mcp-server. File này chứa thông tin có cấu trúc về:

  • Các tools và resources hiện có.
  • Phiên bản của schema (Semantic Versioning).
  • Các yêu cầu về xác thực (OAuth 2.1 scopes).

Nhờ Server Cards, hệ thống Gateway có thể crawl và lập chỉ mục (index) toàn bộ capabilities của tổ chức vào một Internal Registry. Khi Agent cần tìm một tool để “deploy lên staging”, nó chỉ cần hỏi Registry thay vì phải mở kết nối mù mờ.

Bây giờ bạn đã nắm được lý thuyết, trong bài tiếp theo, chúng ta sẽ bắt tay vào code thực tế: Sử dụng Official Go SDK để build một MCP Server tuân thủ các nguyên tắc Production-grade.

Next up: Phần 2: Build Production Server (Go)