Mục lục bài viết
Hãy tưởng tượng bạn đang xây một AI assistant cho đội engineering.
Ban đầu yêu cầu khá đơn giản:
“Cho AI đọc tài liệu nội bộ để trả lời câu hỏi.”
Bạn kết nối Google Drive hoặc một vector database. Xong.
Sau đó team muốn AI có thể đọc GitHub issue. Bạn viết thêm một integration.
Rồi họ muốn nó kiểm tra PostgreSQL.
Bạn viết thêm một integration nữa.
Sau đó là Slack, Jira, Sentry, filesystem, internal APIs, cloud infrastructure...
Đến một thời điểm, vấn đề không còn nằm ở khả năng của LLM nữa. Model đủ thông minh để hiểu câu hỏi và quyết định nó cần thông tin gì, nhưng application lại bị mắc kẹt trong một mạng lưới integration riêng biệt.
AI Application
├── Google Drive connector
├── GitHub connector
├── PostgreSQL connector
├── Slack connector
├── Jira connector
├── Sentry connector
├── Internal CRM connector
└── ...
Tệ hơn, nếu công ty có nhiều AI applications — chẳng hạn một coding assistant, một support agent và một internal knowledge assistant — phần lớn integration có thể phải được xây lại cho từng application.
Đây chính là một trong những vấn đề nền tảng dẫn tới sự xuất hiện của Model Context Protocol (MCP): làm thế nào để AI applications có một cách chuẩn hóa để khám phá dữ liệu, gọi công cụ và tương tác với các hệ thống bên ngoài mà không phải phát minh lại integration protocol cho từng cặp application–service. Research ban đầu cũng đặt trọng tâm vào sự cô lập dữ liệu của LLM và chi phí ngày càng lớn của các custom connector.
Anthropic giới thiệu MCP vào ngày 25/11/2024 như một open standard để kết nối AI assistants với những hệ thống nơi dữ liệu thực sự tồn tại. Ý tưởng của MCP chịu ảnh hưởng từ Language Server Protocol: thay vì mỗi editor phải tự hiểu từng programming language, editor và language server thống nhất nói chung một protocol.
Nhưng để hiểu MCP đúng, có một điều cần làm rõ ngay từ đầu:
MCP không làm model thông minh hơn. MCP chuẩn hóa cách AI application kết nối với thế giới bên ngoài.
Đó là distinction quan trọng nhất của toàn bộ bài viết này.
MCP thực chất là gì?
Model Context Protocol — MCP — là một protocol chuẩn hóa cách AI applications trao đổi context và capabilities với các hệ thống bên ngoài.
Một MCP server có thể cho AI application biết:
- tôi có những dữ liệu nào;
- tôi cung cấp những công cụ nào;
- input của công cụ có cấu trúc ra sao;
- cách gọi công cụ;
- kết quả trả về theo format nào;
- tôi cung cấp những workflow prompt nào.
AI application phía bên kia không cần biết GitHub API hoạt động khác PostgreSQL như thế nào hay filesystem khác Slack ở đâu. Nó tương tác thông qua một interface chung.
Mental model đơn giản nhất có thể hình dung MCP như một USB-C cho AI integrations.
Trước MCP
AI App A ───── GitHub
AI App A ───── Slack
AI App A ───── PostgreSQL
AI App B ───── GitHub
AI App B ───── Slack
AI App B ───── PostgreSQL
Với một protocol chung
┌── GitHub MCP Server ───── GitHub
AI App ─ MCP ─┼── Slack MCP Server ────── Slack
└── DB MCP Server ───────── PostgreSQL
So sánh này hữu ích để hiểu intuition, nhưng MCP không đơn giản chỉ là một adapter format. Nó còn định nghĩa message structure, capabilities, primitives, transports và nhiều lifecycle behavior cần thiết để client và server có thể interoperable.
Một cách mô hình hóa thường gặp là nói MCP biến bài toán integration từ M × N thành 1 × N. Ý này đúng về trực giác nhưng chưa hoàn toàn chính xác về engineering.
Giả sử có:
M = số AI applications
N = số external systems
Nếu mọi cặp integration phải xây riêng:
M × N integrations
Với một protocol chung, mỗi AI application cần hỗ trợ MCP và mỗi external system cần có MCP server:
M client implementations
+
N server implementations
Vì vậy cách nhìn chính xác hơn là:
M × N
↓
M + N
Protocol không làm integration biến mất. Nó thay đổi nơi integration complexity được đặt và làm cho các implementation có thể tái sử dụng qua nhiều host khác nhau.
Đây cũng là lý do MCP không phải là một “API mới thay thế tất cả API cũ”. Một GitHub MCP server cuối cùng vẫn có thể gọi GitHub REST hoặc GraphQL API. MCP nằm ở layer phía trên để chuẩn hóa cách AI application khám phá và sử dụng capability đó.
MCP không phải là Tool Calling, Agent Framework hay RAG
Trước khi đi sâu hơn, cần loại bỏ một vài khái niệm rất dễ bị trộn lẫn.
| Khái niệm | Nó giải quyết vấn đề gì? |
|---|---|
| Tool Calling | Cho model biểu diễn ý định gọi function/tool |
| MCP | Chuẩn hóa cách application khám phá và giao tiếp với external capabilities |
| RAG | Retrieve dữ liệu liên quan rồi đưa vào context của model |
| Agent Framework | Điều phối reasoning loop, state, tools, workflow |
| API | Interface của một service cụ thể |
| MCP Server | Adapter chuẩn hóa capability của một hoặc nhiều hệ thống theo MCP |
MCP và Tool Calling
Giả sử model nhìn thấy:
{
"name": "get_weather",
"arguments": {
"city": "Da Nang"
}
}
Đây là tool calling: model quyết định một function nên được gọi.
Nhưng model vẫn cần một application thực sự thực thi function đó.
MCP giải quyết lớp integration xung quanh nó:
LLM
│
│ quyết định cần tool
▼
Host Application
│
│ MCP tools/call
▼
MCP Server
│
│ API / database / filesystem
▼
External System
Model không trực tiếp mở TCP connection đến MCP server. Host application vẫn là thành phần điều phối thực tế.
MCP và RAG
RAG thường giải quyết câu hỏi:
“Tài liệu nào nên được đưa vào context?”
MCP giải quyết câu hỏi rộng hơn:
“AI application có thể khám phá và tương tác với capability bên ngoài theo một protocol chung như thế nào?”
Một MCP server hoàn toàn có thể expose một vector search tool:
search_documents(query)
Nhưng MCP không quyết định embedding model nào được dùng, chunking ra sao, retrieval dùng HNSW hay BM25, hoặc reranking hoạt động thế nào.
Đó vẫn là responsibility của hệ thống retrieval bên dưới.
MCP và Agent Framework
LangGraph, AutoGen hay các orchestration layer tương tự có thể quản lý:
plan
→ reason
→ call tool
→ inspect result
→ update state
→ call another tool
MCP không định nghĩa agent reasoning loop đó.
MCP chỉ giúp một agent framework có thể nói:
“Tôi cần danh sách tools.”
hoặc:
“Hãy gọi tool này với arguments này.”
mà không cần biết implementation cụ thể phía server.
💡 Mental model
Agent Framework = ai sẽ làm gì tiếp theo?
Tool Calling = model muốn gọi capability nào?
MCP = application tìm và gọi capability đó bằng protocol nào?
API = capability cuối cùng được hệ thống thật thực thi như thế nào?
Kiến trúc MCP: Host, Client và Server
MCP được xây quanh mô hình Host–Client–Server. Tài liệu kiến trúc của MCP mô tả Host là coordinator, Client chịu trách nhiệm kết nối tới Server, còn Server expose resources, tools và prompts.
Một architecture điển hình có thể hình dung như sau:
┌───────────────────────────────────────┐
│ MCP Host │
│ │
│ User │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ LLM │ │
│ └────┬────┘ │
│ │ │
│ ┌────▼─────┐ ┌──────────┐ │
│ │ Client A │ │ Client B │ │
│ └────┬─────┘ └────┬─────┘ │
└───────┼──────────────┼────────────────┘
│ MCP │ MCP
▼ ▼
┌──────────────┐ ┌──────────────┐
│ GitHub MCP │ │ Database MCP │
│ Server │ │ Server │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
GitHub PostgreSQL
Host
Host là application mà người dùng thực sự sử dụng.
Đó có thể là:
- coding assistant;
- desktop AI application;
- internal enterprise agent;
- IDE;
- autonomous workflow system.
Host chịu phần orchestration quan trọng nhất:
user interaction
LLM integration
permissions
context management
MCP client lifecycle
security policy
tool approval
Nói cách khác, MCP server không phải trung tâm của agent.
Host mới là nơi có bức tranh tổng thể.
Đây là một design decision quan trọng. Một server cung cấp GitHub capability không nhất thiết phải biết toàn bộ conversation của user, cũng không cần biết host đang kết nối thêm PostgreSQL hay Slack server nào khác. Documentation của MCP nhấn mạnh việc server được tách biệt và host kiểm soát security boundary giữa các server.
Client
MCP Client nằm trong Host.
Trong kiến trúc MCP truyền thống, một client tương ứng với một connection tới một server cụ thể.
Host
├── MCP Client ─── GitHub MCP Server
├── MCP Client ─── Slack MCP Server
└── MCP Client ─── PostgreSQL MCP Server
Client chịu trách nhiệm cho protocol communication:
discover capabilities
list tools
call tools
read resources
retrieve prompts
handle protocol messages
Đừng nhầm “MCP Client” với toàn bộ AI application. Client thường chỉ là protocol component bên trong application lớn hơn.
Server
MCP Server expose capabilities cho client.
Server có thể wrap:
PostgreSQL
GitHub
Slack
filesystem
internal REST API
SaaS platform
data warehouse
browser automation
CI/CD system
Ví dụ, một database MCP server có thể expose:
Resources:
db://schema/users
db://schema/orders
Tools:
execute_read_query(sql)
explain_query(sql)
Server không cần chứa LLM.
Nó cũng không nhất thiết phải “agentic”.
Một MCP server tốt thường làm ngược lại: giữ responsibility càng hẹp và deterministic càng tốt.
Resources, Tools và Prompts: ba primitive quan trọng nhất
Phần lớn developer lần đầu tiếp xúc MCP đều tập trung ngay vào Tools. Nhưng MCP server historically được xây quanh ba server primitives quan trọng:
Resources
Tools
Prompts
Documentation mô tả ba primitive này với ba control model khác nhau: Resources thiên về application-controlled, Tools model-controlled và Prompts user-controlled.
| Primitive | Mục tiêu | Thường do ai quyết định sử dụng? |
|---|---|---|
| Resources | Cung cấp context/data | Application |
| Tools | Thực thi operation | Model |
| Prompts | Cung cấp reusable interaction template | User |
Sự khác biệt này không chỉ mang tính naming. Nó thể hiện ba kiểu interaction rất khác nhau.
Resources: “Đây là dữ liệu mà application có thể đưa vào context”
Resource là dữ liệu server expose cho client.
Ví dụ:
file://project/README.md
git://repository/main/src/app.py
db://schema/orders
docs://api/payment
Resource thường phù hợp với thông tin mà application cần đọc.
Ví dụ một IDE muốn đưa file hiện tại vào context:
Host
│
├── resources/list
│
▼
MCP Server
│
├── file://src/main.py
├── file://src/database.py
└── file://README.md
Application có thể chọn:
file://src/database.py
sau đó gọi:
resources/read
và đưa content vào model context.
Điểm quan trọng ở đây là Resource không đồng nghĩa với RAG document.
MCP chỉ định nghĩa một interface để expose và retrieve resource. Application vẫn có thể:
- tự chọn resource;
- cho user chọn;
- search trước;
- rank resources;
- chỉ inject một phần content.
MCP không quyết định chiến lược context management.
Tools: “Đây là những hành động AI có thể yêu cầu thực hiện”
Tools thường là primitive quan trọng nhất với AI Agent.
Một server có thể expose:
search_issues(query)
get_customer(customer_id)
create_ticket(title, description)
run_query(sql)
send_message(channel, text)
Mỗi tool có:
name
description
input schema
optional output schema
Ví dụ:
{
"name": "get_order",
"description": "Get an order by its ID",
"inputSchema": {
"type": "object",
"properties": {
"order_id": {
"type": "string"
}
},
"required": ["order_id"]
}
}
LLM nhìn thấy description và schema rồi có thể suy luận rằng:
User:
"Kiểm tra đơn hàng ORD-1024 cho tôi."
↓
LLM:
I need get_order(order_id="ORD-1024")
Sau đó Host/Client mới thực hiện MCP request.
User
│
▼
LLM
│
│ decides to use get_order
▼
Host
│
│ tools/call
▼
MCP Server
│
│ calls internal Order API
▼
Order Service
│
▼
MCP Server
│ result
▼
Host
│
▼
LLM
│
▼
Natural-language answer
Đây là nơi MCP trở thành một component quan trọng của agent architecture: model có thể khám phá tool interface mà không cần application hard-code riêng communication mechanism cho từng service.
Prompts: “Đây là những workflow template server cung cấp”
Prompts dễ bị hiểu nhầm nhất.
MCP Prompt không giống system prompt bí mật của application.
Server có thể expose một reusable template như:
/review-pull-request
/summarize-incident
/analyze-query-plan
Client lấy template, điền arguments và đưa resulting messages vào model.
Ví dụ:
Prompt:
review-pr
Arguments:
pull_request = 182
focus = "database performance"
Server có thể trả lại structured messages để Host đưa vào conversation.
Prompts vì vậy phù hợp với reusable workflow mà server/domain expert muốn cung cấp cho user.
Trong nhiều agent architectures thực tế, Tools được dùng nhiều hơn. Nhưng hiểu Prompts giúp ta thấy MCP không chỉ là “remote function calling protocol”.
Một MCP Tool Call thực sự diễn ra như thế nào?
Hãy lấy một ví dụ cụ thể.
User hỏi coding assistant:
“Có issue nào đang mở liên quan đến timeout của payment service không?”
GitHub MCP server expose tool:
search_issues(query, state)
Flow có thể diễn ra như sau:
1. Client khám phá available tools
tools/list
│
▼
GitHub MCP Server
2. Tool definition được cung cấp cho LLM
search_issues(
query: string,
state: "open" | "closed"
)
3. Model quyết định gọi tool
search_issues(
query="payment service timeout",
state="open"
)
4. Host gửi MCP request
tools/call
│
▼
GitHub MCP Server
5. Server gọi GitHub API
GitHub MCP Server
│
▼
GitHub API
6. Result quay về
GitHub API
↓
MCP Server
↓
Host
↓
LLM
7. LLM tạo câu trả lời cho user
Một misunderstanding phổ biến là:
“LLM gọi MCP server.”
Về conceptual level có thể nói như vậy, nhưng ở implementation level thì không hoàn toàn chính xác.
LLM sinh tool-selection decision.
Host thực hiện network/process operation.
Đây là distinction quan trọng với security.
Model có thể đề xuất:
delete_database("production")
nhưng chính Host mới quyết định request đó có thực sự được phép đi qua hay không.
Bên dưới MCP: JSON-RPC và Transport
MCP không chỉ định nghĩa semantic primitives. Nó còn cần một wire protocol để Client và Server thực sự giao tiếp.
MCP sử dụng JSON-RPC 2.0 làm message format. Các phiên bản specification trước và sau 2026 đều sử dụng JSON-RPC làm nền tảng.
Một request có mental model như sau:
{
"jsonrpc": "2.0",
"id": 42,
"method": "tools/call",
"params": {
"name": "get_order",
"arguments": {
"order_id": "ORD-1024"
}
}
}
Trong đó:
id
→ dùng để correlate request với response
method
→ operation cần thực hiện
params
→ input của operation
Server trả response tương ứng.
{
"jsonrpc": "2.0",
"id": 42,
"result": {
"...": "..."
}
}
MCP sau đó định nghĩa ý nghĩa cụ thể của:
tools/list
tools/call
resources/list
resources/read
prompts/list
prompts/get
...
Transport không phải Protocol
Một distinction quan trọng khác:
MCP protocol
≠
transport
Protocol định nghĩa nói gì.
Transport định nghĩa message được chuyển như thế nào.
MCP historically hỗ trợ hai transport quan trọng:
stdio
Streamable HTTP
stdio
Với local MCP server:
Host
│
│ launch subprocess
▼
MCP Server Process
stdin ──► requests
stdout ◄── responses
Ví dụ coding assistant có thể chạy một local filesystem server như child process.
Ưu điểm:
- setup đơn giản;
- không cần HTTP server;
- hợp với local tooling;
- process lifecycle do client kiểm soát.
Nhưng có một detail rất dễ gây bug: vì protocol message đi qua stdout, server không thể tùy tiện dùng:
print("debug")
vào stdout.
Một dòng debug text chen giữa JSON-RPC messages có thể làm hỏng protocol stream. Vì vậy log thường phải đi qua stderr hoặc logging mechanism phù hợp. Đây cũng là lưu ý được nhấn mạnh trong research ban đầu.
Streamable HTTP
Với remote MCP server:
AI Host
│
│ HTTPS
▼
API Gateway
│
▼
MCP Server
│
▼
Internal Services
Điều này phù hợp hơn cho:
- cloud deployment;
- enterprise integrations;
- shared servers;
- centrally managed authorization;
- multi-user infrastructure.
Và chính layer này đã thay đổi rất lớn trong MCP 2026.
MCP 2026 thay đổi điều gì? Từ session-oriented sang stateless core
Đây là phần mà nhiều tutorial MCP cũ sẽ nhanh chóng trở nên outdated.
Bản specification chính thức 2026-07-28 chuyển MCP sang stateless protocol core. initialize/initialized handshake và Mcp-Session-Id của modern protocol revision đã được loại bỏ; request hiện mang đủ metadata để một server instance có thể xử lý độc lập.
Trước đây, remote MCP có thể cần lifecycle kiểu:
Client
│
│ initialize
▼
Server
│
│ Mcp-Session-Id
▼
Client
subsequent requests
must preserve session
Trong distributed deployment, điều này tạo ra một bài toán quen thuộc:
Load Balancer
/ | \
/ | \
Server A Server B Server C
Nếu session state nằm ở Server A, request tiếp theo không thể tùy ý sang Server B trừ khi có:
sticky session
hoặc:
shared session store
Với modern MCP 2026-07-28, request được thiết kế self-contained hơn.
Request 1 ─────► Server B
Request 2 ─────► Server A
Request 3 ─────► Server C
Không có requirement rằng request phải quay lại instance trước.
Official Python SDK documentation cũng mô tả modern 2026-07-28 request là sessionless và có thể được phục vụ bởi bất kỳ worker nào.
🏗️ Production Note
Đây không đơn giản là một protocol cleanup.
Nó thay đổi deployment architecture:
Before
Client
│
▼
Load Balancer
│ sticky
▼
Server A
│
▼
Session State
2026-07-28
Client
│
▼
Load Balancer
├────► Server A
├────► Server B
└────► Server C
MCP server nhờ vậy gần với một HTTP workload thông thường hơn.
Nhưng stateless protocol không có nghĩa application không được có state
Đây là nuance rất quan trọng.
Giả sử shopping agent có flow:
create_cart()
→ add_product()
→ checkout()
Ta vẫn cần biết ba calls đang thao tác cùng một cart.
Stateless protocol không cấm state.
Thay vì giấu state trong transport session:
Mcp-Session-Id → server-side state
application có thể expose state explicitly:
create_cart()
→ cart_id = "cart_82"
add_product(
cart_id="cart_82",
product_id="P20"
)
Official 2026 release cũng khuyến khích explicit handles cho những application cần carry state giữa calls.
Điều này có một architectural advantage khá thú vị: state trở thành một phần visible của domain operation thay vì hidden transport metadata.
Hidden state
HTTP session
↓
magic server state
Explicit state
cart_id
job_id
transaction_id
conversation_handle
Explicit handle thường:
- dễ debug hơn;
- dễ retry hơn;
- dễ log hơn;
- dễ distribute hơn;
- dễ kiểm soát authorization hơn.
Multi Round-Trip Requests: làm sao server hỏi ngược lại khi protocol stateless?
Stateless tạo ra một câu hỏi khó.
Giả sử tool:
delete_files(files)
đang chạy và server phát hiện ba files đặc biệt nhạy cảm.
Server muốn hỏi:
“Bạn có chắc muốn xóa ba file này không?”
Trong architecture cũ, server có thể cần một back-channel đang mở.
MCP 2026-07-28 đưa vào Multi Round-Trip Requests — MRTR.
Flow mới có dạng:
Client
│
│ tools/call
▼
Server
│
│ input_required
▼
Client
│
│ ask user / obtain input
│
│ retry original request
▼
Server
│
│ complete
▼
Client
Server có thể trả một result kiểu:
input_required
kèm những input cần bổ sung. Client lấy input, sau đó gửi lại original operation cùng responses.
Mental model:
Không giữ connection state để "đợi user".
Thay vào đó:
Server:
"Tôi chưa hoàn thành.
Đây là dữ liệu tôi còn thiếu."
Client:
"Đây là dữ liệu.
Tiếp tục operation."
Cách tiếp cận này phù hợp hơn với retryable distributed systems.
Một MCP server Python hiện đại trông như thế nào?
Một điểm cần cập nhật so với nhiều tutorial cũ là Python SDK v2 đã đổi high-level server class từ FastMCP sang MCPServer. SDK v2 hiện là stable line và triển khai MCP 2026-07-28.
Ví dụ đơn giản:
from mcp.server import MCPServer
mcp = MCPServer("Inventory")
@mcp.tool()
def get_stock(sku: str) -> dict:
"""Return current inventory for a product SKU."""
# Simplified example.
inventory = {
"KB-001": 24,
"MS-002": 8,
}
return {
"sku": sku,
"quantity": inventory.get(sku, 0),
}
if __name__ == "__main__":
mcp.run()
Đoạn code ngắn, nhưng phía sau decorator:
@mcp.tool()
SDK có thể xây tool metadata từ:
function name
type hints
docstring
Application phía client không cần biết code Python bên trong.
Nó chỉ cần nhìn thấy conceptual interface:
get_stock(
sku: string
)
Đây là một ví dụ nhỏ nhưng cho thấy giá trị thật của MCP.
Không phải việc decorator giúp code ngắn hơn.
Giá trị nằm ở chỗ:
capability vừa được expose theo một contract mà bất kỳ compatible MCP client nào cũng có thể hiểu.
Tool Schema rất quan trọng — nhưng không phải security boundary hoàn chỉnh
Tool definition thường sử dụng JSON Schema để mô tả input.
Ví dụ:
{
"type": "object",
"properties": {
"limit": {
"type": "integer",
"minimum": 1,
"maximum": 100
}
},
"required": ["limit"]
}
Schema có thể ngăn input kiểu:
{
"limit": "banana"
}
nếu limit bắt buộc là integer.
Nhưng cần tránh một kết luận quá mạnh:
“Có JSON Schema nên tool an toàn trước injection.”
Không đúng.
Schema validation giải quyết chủ yếu:
structure
type
required fields
allowed shape
Nó không tự biết string:
"DROP TABLE users"
có nguy hiểm hay không nếu schema chỉ quy định:
sql: string
Tương tự, schema không phân biệt:
user_id = "123"
là account mà current user được phép xem hay account của người khác.
Security thực sự cần nhiều layer:
LLM-generated arguments
│
▼
Schema validation
│
▼
Authentication
│
▼
Authorization
│
▼
Business validation
│
▼
Policy enforcement
│
▼
External system
Schema là một layer quan trọng.
Nhưng nó không phải authorization system, prompt-injection defense hay SQL-injection defense hoàn chỉnh.
MCP không tự động làm AI Agent an toàn
Đây có lẽ là misconception nguy hiểm nhất khi MCP được sử dụng trong production.
Một application có MCP không đồng nghĩa với:
trusted tools
safe actions
correct permissions
secure agent
Official tool specification khuyến nghị application giữ human-in-the-loop và cho user khả năng từ chối tool invocation, đặc biệt khi operation có impact. Nhưng đây là responsibility của implementation; protocol không magically ngăn model gọi một operation nguy hiểm.
Hãy xét architecture:
Untrusted Web Page
│
▼
LLM
│
│ generated tool call
▼
MCP Client
│
▼
Email MCP Server
│
▼
Send Email
Nếu webpage chứa malicious instruction và application cho model quyền gửi email tự động, MCP chỉ giúp request được thực hiện theo một protocol chuẩn.
MCP không biết instruction đến từ:
system prompt
user
webpage
retrieved document
attacker
Do đó security boundary phải nằm ngoài model reasoning.
Một architecture an toàn hơn:
Untrusted Content
│
▼
LLM
│
▼
Structured Tool Proposal
│
▼
┌───────────────────────┐
│ Authorization │
│ Policy │
│ Scope validation │
│ Business rules │
└──────────┬────────────┘
│
▼
User confirmation
│
▼
MCP Tool
Principle of Least Privilege
Nếu agent chỉ cần đọc orders:
orders:read
đừng cấp:
orders:*
Nếu tool chỉ cần query analytics database, dùng read-only credential thay vì database admin account.
Nếu tool cần filesystem:
/project/reports
đừng mặc định expose:
/
Đây là security engineering truyền thống.
MCP không thay thế nó.
MCP Server tốt không nhất thiết expose càng nhiều tools càng tốt
Một trong những lesson quan trọng nhất khi hệ sinh thái MCP lớn dần là:
Tool catalog cũng tiêu tốn context và attention của model.
Giả sử một server expose:
5 tools
Model có thể dễ phân biệt.
Nhưng nếu host kết nối nhiều servers:
GitHub 80 tools
Cloud 120 tools
CRM 60 tools
Database 40 tools
Analytics 90 tools
thì model phải xử lý gần 400 tool definitions.
Vấn đề không chỉ là token cost.
Tool-selection accuracy cũng có thể giảm khi có quá nhiều capabilities tương tự nhau.
search_customer
find_customer
lookup_customer
query_customer
customer_search
Model phải phân biệt subtle semantic differences trước khi thực hiện task.
Roadmap MCP công bố ngày 22/8/2026 cũng xác định scale của tool catalog là một vấn đề cần giải quyết, với hướng progressive discovery: server có thể expose một entry point nhỏ rồi reveal thêm capability khi task được thu hẹp.
🏗️ Production Note
Đừng thiết kế MCP Server như một dump của toàn bộ backend API.
Thay vì:
341 endpoint → 341 tools
hãy nghĩ:
Những capability nào thực sự có ý nghĩa với AI?
Tool interface cho agent và API interface cho frontend không nhất thiết phải giống nhau.
API endpoint tốt chưa chắc là MCP tool tốt
Giả sử backend có API:
PATCH /orders/{id}
body:
{
"status": "cancelled"
}
Có thể expose trực tiếp thành:
update_order(id, fields)
Nhưng với model, interface như vậy quá general.
Một tool tốt hơn có thể là:
cancel_order(
order_id,
reason
)
Tại sao?
Bởi vì tool name và schema đồng thời là semantic interface dành cho model.
Model không đọc implementation.
Nó suy luận từ:
tool name
description
arguments
schema
Do đó:
generic CRUD tool
thường khó kiểm soát hơn:
domain-specific capability
So sánh:
database_execute(sql)
với:
get_customer_orders(customer_id)
get_failed_payments(
from_date,
to_date
)
Tool thứ nhất rất mạnh nhưng permission surface khổng lồ.
Tool phía sau hẹp hơn, dễ reason hơn và dễ secure hơn.
Đây là điểm nơi protocol design gặp application design.
MCP giúp chuẩn hóa contract.
Nhưng chất lượng contract vẫn là trách nhiệm của developer.
Error handling cũng là một phần của Agent Design
Trong software truyền thống, error thường được xử lý cho developer hoặc UI.
Với AI Agent, error còn trở thành feedback cho model.
Giả sử tool trả:
Invalid customer_id
Model có thể thử lại.
Nhưng nếu server trả:
Error
model gần như không biết phải sửa gì.
Một useful error có thể nói:
customer_id must use format CUS-xxxx.
Received: 1234.
LLM có khả năng dùng information đó để sửa operation:
1234
↓
CUS-1234
Điều này tạo ra một interesting loop:
LLM
│
│ tool call
▼
Tool
│
│ actionable error
▼
LLM
│
│ corrected call
▼
Tool
MCP giúp standardized communication, nhưng quality của agent loop phụ thuộc rất nhiều vào quality của:
tool descriptions
schemas
errors
results
Nói cách khác, xây MCP server không chỉ là expose function.
Bạn đang thiết kế một machine-readable interface cho một reasoning model.
MCP làm thay đổi cách chúng ta nghĩ về AI architecture
Không có MCP, integration thường bị embed trực tiếp trong agent:
Agent
├── github.py
├── slack.py
├── database.py
├── jira.py
└── drive.py
Agent và integrations bị coupled.
Với protocol-based architecture:
┌── GitHub MCP Server
│
Agent Host ── MCP ──┼── Database MCP Server
│
├── Slack MCP Server
│
└── Internal MCP Server
ta có thể thay host:
Host A
Host B
Host C
mà vẫn reuse servers.
Hoặc thay server implementation mà client không cần hiểu internal mechanics.
Đây chính là lợi ích lớn nhất của standards.
REST không làm business logic biến mất.
SQL không làm database design biến mất.
HTTP không làm distributed systems trở nên đơn giản.
Tương tự:
MCP không loại bỏ integration complexity. Nó tạo ra một boundary chuẩn để complexity không còn phải được giải quyết lại cho từng cặp hệ thống.
Khi nào MCP thực sự đáng dùng?
Không phải mọi application gọi một API đều cần MCP.
Nếu application chỉ có:
LLM
+
1 internal function
và function đó chỉ được sử dụng ở đúng một nơi, một tool wrapper đơn giản có thể đủ.
MCP bắt đầu có giá trị rõ hơn khi:
nhiều tools
+
nhiều AI hosts
+
nhiều external systems
+
nhu cầu interoperability
Ví dụ:
Một organization có nhiều AI products
Coding Assistant
Support Agent
Ops Agent
Internal Search
và muốn chúng reuse:
GitHub
Jira
Slack
Database
Observability
MCP giúp separation rất đáng kể.
Bạn xây một capability muốn nhiều AI clients sử dụng
Ví dụ:
Company Knowledge Server
Nếu expose qua MCP, nhiều compatible host có thể sử dụng mà không cần viết connector riêng.
Bạn xây AI development tooling
IDE là môi trường rất phù hợp bởi coding agent thường cần:
filesystem
Git
GitHub
database
browser
CI/CD
documentation
observability
Số integrations tăng nhanh, nên shared protocol tạo giá trị lớn.
Khi nào không nên ép MCP vào kiến trúc?
MCP không phải default answer cho mọi integration.
Nếu flow của bạn đơn giản:
API endpoint
→ LLM
→ answer
thêm:
MCP Host
MCP Client
MCP Server
có thể chỉ tạo thêm abstraction.
Tương tự, nếu application có một deterministic backend workflow:
validate payment
→ charge card
→ generate invoice
không có lý do để biến mọi step thành LLM-selected MCP tool.
Một rule hữu ích là:
MCP đáng giá nhất khi interoperability và dynamic capability discovery quan trọng hơn chi phí abstraction mà protocol thêm vào.
Không phải:
“Dùng AI thì phải dùng MCP.”
Những hiểu nhầm phổ biến về MCP
1. “MCP làm LLM truy cập trực tiếp database”
Không.
Thông thường flow là:
LLM
→ Host
→ MCP Client
→ MCP Server
→ Database
Host và Server vẫn enforce execution.
2. “Có MCP thì không cần viết integration”
Vẫn cần.
Bạn vẫn phải viết logic:
MCP tool
→ GitHub API
MCP tool
→ PostgreSQL
MCP tool
→ internal service
MCP chỉ làm integration reusable và interoperable hơn.
3. “MCP chính là tool calling”
Tool calling là model capability.
MCP là integration protocol.
Hai thứ thường đi cùng nhau nhưng không phải một.
4. “MCP Server phải có AI bên trong”
Không.
Một server hoàn toàn có thể deterministic:
def get_stock(sku):
return database.lookup(sku)
LLM nằm phía Host.
5. “JSON Schema làm MCP tools an toàn”
Schema validation giúp kiểm tra structure.
Security vẫn cần:
authentication
authorization
least privilege
business validation
rate limits
audit
user confirmation
6. “Expose tất cả backend APIs thành MCP tools là tốt”
Không nhất thiết.
Tool catalog quá lớn làm tăng context cost và có thể làm tool selection khó hơn.
MCP roadmap hiện cũng đang hướng tới progressive capability discovery để xử lý chính vấn đề scale này.
🔬 Deep Dive — Vì sao MCP quan trọng hơn một bộ SDK tiện dụng?
Nếu nhìn MCP chỉ qua code:
@mcp.tool()
developer rất dễ kết luận:
“Đây chỉ là framework giúp tạo function calling.”
Nhưng decorator không phải phần quan trọng nhất.
Hãy tưởng tượng thế giới không có shared protocol.
Một AI application hỗ trợ GitHub có thể định nghĩa:
{
"operation": "github_search",
"payload": {}
}
Application khác lại dùng:
{
"action": "searchGithub",
"args": {}
}
Application thứ ba dùng REST endpoint riêng.
Mỗi GitHub integration phải hiểu từng representation.
Đây chính là pairwise coupling.
Một protocol tiêu chuẩn tạo ra contract chung:
AI Host
│
│ MCP
▼
Capability Provider
Khi đủ nhiều clients và servers cùng implement contract, network effect bắt đầu xuất hiện.
Một server mới:
Company Analytics MCP Server
không chỉ tích hợp với một assistant.
Về nguyên tắc, nó có thể tích hợp với cả ecosystem những host hỗ trợ MCP.
Và một host mới không cần tự viết connectors cho mọi vendor nếu ecosystem đã có MCP servers tương ứng.
Đây chính là lý do Language Server Protocol là analogy phù hợp.
Không phải vì MCP và LSP có cùng use case.
Mà vì cả hai cùng chuyển ecosystem từ:
pairwise integrations
sang:
shared protocol boundary
Đó mới là architectural significance thực sự.
MCP đang đi về đâu?
MCP bắt đầu tại Anthropic nhưng hiện không còn đơn thuần là một Anthropic-specific interface. Cuối năm 2025, Anthropic đã đóng góp MCP cho Agentic AI Foundation thuộc Linux Foundation, trong bối cảnh protocol được nhiều AI platforms và infrastructure vendors hỗ trợ.
Bản 2026-07-28 tiếp tục đẩy protocol theo hướng phù hợp hơn với production infrastructure:
stateless core
header-based routing
cacheable discovery/list results
MRTR
extension framework
authorization hardening
Roadmap ngày 22/8/2026 cho thấy các hướng tiếp theo tập trung vào:
agentic messaging
HTTP transport unification
agent identity
enterprise security
progressive discovery
SDK ergonomics
Trong security, roadmap đang tiếp tục công việc quanh DPoP, Workload Identity Federation và delegation cho cloud agents — nhưng đây là hướng phát triển đang tiếp tục hoàn thiện, không nên nhầm với việc mọi MCP deployment hiện tại đã tự động có workload identity an toàn.
Điểm này cho thấy MCP đang chuyển từ một protocol chủ yếu nổi tiếng nhờ local developer tools sang một infrastructure layer được thiết kế ngày càng nhiều cho distributed agent systems.
Kết luận
Quay lại bài toán ban đầu.
Bạn có một AI application cần:
đọc GitHub
query database
xem Sentry
gửi Slack
đọc filesystem
gọi internal APIs
Vấn đề không phải LLM không hiểu những hệ thống này.
Vấn đề là mỗi hệ thống có interface khác nhau, authentication khác nhau, data model khác nhau và integration code khác nhau.
Nếu mỗi AI application tự xây toàn bộ connectors của riêng mình, architecture nhanh chóng trở thành một ma trận pairwise integrations khó tái sử dụng.
MCP đưa vào một boundary mới:
AI Application
│
│ standardized protocol
▼
MCP Server
│
▼
External System
Từ đó, ta có một mental model rõ ràng hơn:
- LLM reasoning không phải MCP. Model chỉ quyết định nó cần context hoặc capability nào.
- Host mới là coordinator. Host quản lý model, permissions, context và MCP clients.
- MCP Server expose capability thông qua một contract chuẩn.
- Resources cung cấp context, Tools cung cấp actions, Prompts cung cấp reusable interaction templates.
- MCP không loại bỏ integration hay security complexity — nó đặt chúng sau một interoperability boundary tốt hơn.
Và đó là cách hữu ích nhất để hiểu MCP.
Không phải:
“Một framework mới để gọi tools.”
Mà là:
một protocol layer giúp các AI applications và thế giới phần mềm bên ngoài có thể phát triển độc lập hơn nhưng vẫn hiểu cách nói chuyện với nhau.
Nguồn tham khảo
- Anthropic — Introducing the Model Context Protocol (25/11/2024).
- Model Context Protocol — Architecture.
- Model Context Protocol — Resources.
- Model Context Protocol — Tools.
- Model Context Protocol — Prompts.
- Model Context Protocol — The 2026-07-28 Specification.
- MCP Python SDK — What's new in v2.
- Model Context Protocol — The New MCP Roadmap, 22/8/2026.
- Anthropic — Donating the Model Context Protocol and establishing the Agentic AI Foundation.
