MCP ngốn context: cắt từ 15 tool xuống 4, mô tả giảm 88%

Một con số nên làm bạn khó chịu: MCP server chính thức của GitHub nạp khoảng 55.000 token cho 93 tool definition trước khi bạn hỏi câu nào. Trên context window 200K, hơn một phần tư ngân sách đã bay trước khi agent bắt đầu làm việc.

Con số đó đến từ một bài rebuild thực tế: cùng một AWS MCP server, cùng một tài khoản, cùng một câu hỏi — dựng hai lần để đo chênh lệch.

Hai kiểu hỏng: bloat và confusion

Tác giả dẫn một bài của AWS tháng 7/2026, "MCP tool design: Practical approaches and tradeoffs", đặt tên cho hai chế độ hỏng nuôi nhau.

Bloat: mọi tool definition đều nạp vào context mỗi lượt gọi, dùng hay không cũng vậy. Mỗi tool schema tốn 550 đến 1.400 token, nên 50 tool có thể là 30.000-70.000 token mô tả trước khi làm gì. Bài viết ước tính một phiên Claude Code cài 5-10 MCP server đốt 50.000-67.000 token trước prompt đầu tiên.

Confusion: khi context đầy dần và các tool bắt đầu giống nhau — describe_volumes, describe_addresses, describe_snapshots, đều mỏng như nhau — model chọn nhầm, truyền sai tham số, nhận kết quả rỗng rồi thử lại. Mỗi lần thử lại nạp thêm token.

Gốc rễ là thói quen bọc mỗi API endpoint thành một tool rồi ship 30 cái. Nhìn thì đầy đủ, thực tế là cái bẫy.

Bảng điểm sau khi rebuild

Bản v1 có 15 tool, mỗi tool là một wrapper mỏng quanh một lời gọi boto3. Hỏi "tôi đang lãng phí tiền ở đâu trong tài khoản này?", agent gọi 7 tool liên tiếp rồi tự ghép câu trả lời. Bản v2 có 4 tool, cùng khả năng, cùng tài khoản — agent gọi find_waste một lần, rồi estimate_savings để quy ra tiền. Hai lời gọi.

Chỉ số	v1 (15 tool)	v2 (4 tool)	Chênh
Số tool phơi ra	15	4	-73%
Kích thước mô tả tool (ký tự)	7.898	897	-88%
Số lời gọi để trả lời	7	2	-71%
Số phát hiện thật	3 ID	cùng 3 ID	không đổi

Hai bản tìm ra cùng các khoản lãng phí và trích cùng resource ID: một EBS volume gp2 8 GiB không gắn vào đâu (khoảng 0,80 USD/tháng), một snapshot 8 GiB mồ côi (khoảng 0,40 USD/tháng), và một Elastic IP không được associate. Lưu ý đây là số đo của chính tác giả trên tài khoản của họ, không phải benchmark độc lập.

Bốn thay đổi đáng copy

• Tool theo kết quả, không theo endpoint. Thay 15 wrapper mỏng bằng 4 tool, mỗi tool hoàn thành trọn một hành động nghiệp vụ. "Tôi lãng phí ở đâu" thành một lời gọi thay vì bảy.
• Ràng buộc ngay trong schema. Tham số scope là Literal["account", "region", "service"] chứ không phải free text, nên model không thể truyền giá trị rác. AWS Prescriptive Guidance khuyến nghị giữ mỗi tool ở khoảng 8 tham số trở xuống; ở đây mỗi tool chỉ có 2.
• Response gầy đi. Mặc định trả về 5 field phục vụ quyết định cho mỗi phát hiện, thay vì cả blob; cần đủ thì truyền detail=True.
• Lỗi thật thay vì kết quả rỗng. Một scope sai trả về "scope must be one of: account, region, service", không trả về "no results" — model phục hồi được từ cái đầu, cái sau đẩy nó vào vòng lặp thử lại.

Tác giả cũng nhắc hướng tiếp cận Tool Search của Anthropic, theo họ báo cáo giảm tới 85% token nhờ chỉ nạp định nghĩa khi thật sự cần — con số này là của Anthropic, không phải kết quả đo trong bài.

Cùng một bệnh ở phía tài liệu

Một lập trình viên khác mô tả đúng triệu chứng đó nhưng ở phía docs: dự án có 4 tài liệu (PRD, Tech, UI, DB) và mọi phiên chat đều phải đọc cả 4 trước khi code, khiến việc đọc tài liệu ngốn hơn 60% context window 200K trước khi agent chạm vào task. Cách sửa gồm hai bước: thêm một file Overview.md đóng vai bản đồ trỏ đường để agent chỉ mở đúng tài liệu liên quan, và dùng grep kèm offset/limit để đọc đúng đoạn thay vì cả file. Tác giả báo cáo context sau subtask đầu tiên còn khoảng 40%, tức giảm gần một nửa.

Làm gì tuần này

Mở /context (hoặc lệnh tương đương) trong agent bạn đang dùng và đọc con số trước khi gõ prompt đầu tiên. Nếu phần tool definition đã chiếm hai chữ số phần trăm, hãy đếm xem trong 30 ngày qua bạn thực sự gọi bao nhiêu tool — thường ít hơn nhiều so với số đang bật. Gỡ phần còn lại trước khi nghĩ tới việc nâng context window.