Phân biệt MCP và Function Calling

Đây là hai khái niệm hay bị nhầm lẫn nhưng thực ra ở hai tầng khác nhau, và bổ sung cho nhau chứ không thay thế.

Cấu trúc repo

day26-mcp/
├── README.md                ← Bạn đang đọc file này
├── requirements.txt         ← pip install -r requirements.txt
│
├── 01-function-calling/     ← Bước 1: Function Calling thuần (Gemini SDK)
│   ├── README.md
│   └── weather_function_calling.py
│
├── 02-mcp-basics/           ← Bước 2: MCP server + client (không cần API key)
│   ├── README.md
│   ├── weather_server.py
│   └── weather_client.py
│
└── 03-production/           ← Bước 3: Auth, Tool Registry, Versioning
    ├── README.md
    ├── auth_server.py
    ├── auth_client.py
    ├── registry.json
    ├── registry_client.py
    └── versioned_server.py

Quick start

python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

# MCP demo (không cần API key)
cd 02-mcp-basics && python weather_client.py

# Function Calling (cần Gemini API key)
export GEMINI_API_KEY=...
cd 01-function-calling && python weather_function_calling.py

# Production — Auth (2 terminal)
cd 03-production
python auth_server.py              # terminal 1
python auth_client.py              # terminal 2

# Production — Tool Registry
cd 03-production && python registry_client.py

---

Định nghĩa ngắn gọn

Function Calling là một khả năng của model (capability). Model được huấn luyện để khi bạn đưa cho nó danh sách các “công cụ” (kèm schema mô tả tham số), nó có thể tự quyết định gọi công cụ nào và sinh ra JSON tham số phù hợp. Bản thân model không chạy function — nó chỉ nói “hãy gọi get_weather(city='Hanoi')”. App mới là nơi chạy tool.

MCP (Model Context Protocol) là một giao thức chuẩn (protocol) — giống như USB-C hay HTTP cho thế giới AI. Nó định nghĩa cách một MCP Client (như Claude Code, Claude Desktop) kết nối tới các MCP Server để khám phá và sử dụng tools, resources, prompts một cách thống nhất.

---

So sánh trực tiếp

Quan hệ giữa chúng

Điểm quan trọng nhất: MCP dùng Function Calling bên dưới. Chúng không loại trừ nhau.

User hỏi
   │
   ▼
LLM (dùng Function Calling để quyết định gọi tool nào)
   │
   ▼
MCP Client  ──[giao thức MCP]──►  MCP Server (thực thi tool thật)
   │                                   │
   ◄───────────── kết quả ─────────────┘
   ▼
LLM tổng hợp câu trả lời

Khi nào dùng cái nào?

• Function Calling thuần: app đơn giản, tool gắn chặt với 1 ứng dụng, không cần chia sẻ.
• MCP: muốn tool/tích hợp dùng lại được trên nhiều AI client, muốn tách biệt logic tool khỏi app, hoặc xây hệ sinh thái tích hợp (DB, file, API nội bộ…).

---

Minh hoạ bằng mã nguồn

Cùng một tool get_weather, dưới đây là hai cách triển khai để thấy rõ sự khác biệt.

Cách 1 — Function Calling thuần (Google Gemini SDK)

Tool được định nghĩa và thực thi ngay trong app. Model chỉ quyết định gọi tool nào, app tự chạy và đưa kết quả trở lại.

User hỏi → Model quyết định gọi get_weather("Hà Nội")
                    │
                    ▼
             App TỰ THỰC THI hàm get_weather
                    │
                    ▼
             Model tổng hợp câu trả lời

Nhược điểm: schema viết tay, tool gắn chặt trong app — muốn dùng lại ở app khác phải copy cả schema lẫn hàm.

Chi tiết + code: xem 01-function-calling/README.md

Cách 2 — MCP (server tự công bố tool, mọi client dùng chung)

Tool được tách ra một MCP server độc lập. Server tự “khai báo” nó có tool gì; bất kỳ MCP client nào (Claude Code, Claude Desktop, Cursor…) cũng cắm vào dùng được mà không cần biết code bên trong.

weather_client.py                       weather_server.py
┌─────────────┐    giao thức MCP    ┌─────────────────┐
│  list_tools │ ──────────────────▶ │ @mcp.tool()     │
│  call_tool  │ ◀────────────────── │ get_weather()   │
└─────────────┘     stdio           └─────────────────┘

Chi tiết + code: xem 02-mcp-basics/README.md

Điểm khác biệt rút ra từ code

---

MCP trong Production

Các ví dụ trên chạy tốt trên máy cá nhân, nhưng đưa vào hệ thống production cần giải quyết thêm ba vấn đề:

┌─────────────────────────────────────────────────────┐
│                  Production MCP                     │
│                                                     │
│  ┌──────────┐   ┌───────────┐   ┌───────────────┐   │
│  │ Security │   │ Registry  │   │  Versioning   │   │
│  │          │   │           │   │               │   │
│  │ • Auth   │   │ • Discover│   │ • v1 compat   │   │
│  │ • Token  │   │ • Connect │   │ • v2 features │   │
│  │ • Scopes │   │ • Health  │   │ • Deprecation │   │
│  └──────────┘   └───────────┘   └───────────────┘   │
└─────────────────────────────────────────────────────┘

1. Security — Authentication & Authorization

MCP server phục vụ qua HTTP cho nhiều client → cần xác thực. MCP SDK hỗ trợ sẵn Bearer Token verification:

• Server: cấu hình AuthSettings + implement TokenVerifier protocol
• Client: gửi header Authorization: Bearer qua httpx.AsyncClient
• Không có token → 401, token sai → 403, logic tool không biết gì về auth

2. Tool Registry & Discovery

Agent không hard-code tool nào. Nó hỏi Tool Registry — danh mục trung tâm liệt kê tất cả tool từ mọi server — theo yêu cầu task:

Agent nhận task "lấy thời tiết Hà Nội"
   │
   ▼
Tool Registry: "tool nào có tag 'weather'?"
   │
   ├── get_weather v1.0 → server: weather (stdio)
   └── get_weather_v2 v2.0 → server: weather-v2 (stdio)
   │
   ▼
Agent chọn best match (v2.0, không deprecated)
   │
   ▼
Kết nối tới server weather-v2, gọi get_weather_v2(city="Hanoi")

Registry là tool-centric — đơn vị khám phá là tool (tag, description, parameters), không phải server.

3. Versioning & Backward Compatibility

Server v1 có get_weather(city) trả chuỗi đơn giản. V2 muốn trả JSON chi tiết, thêm include_forecast. Nếu đổi trực tiếp → mọi client cũ break. Giải pháp — 3 kỹ thuật kết hợp:

Chi tiết + code cho cả 3 phần: xem 03-production/README.md

Tổng kết Production Checklist

---

Tóm lại: Function Calling là cơ chế model gọi công cụ; MCP là chuẩn để kết nối model với các công cụ đó — và MCP thực chất dùng Function Calling làm nền tảng để hoạt động.