Để tạo một bản ghi qua MCP, lượng token dùng nhiều quá.

Thực tế đây là “nỗi đau” chung khi dùng Model Context Protocol (MCP) cho các thao tác CRUD cơ bản như CREATE. MCP thiết kế theo hướng tổng quát, nên mỗi lần gọi tool nó phải gánh một khoản overhead rất lớn:

1. Context/Schema Bloat: Client phải đưa toàn bộ JSON Schema của tool (mô tả từng field, type, description) vào System Prompt của LLM để nó hiểu cách gọi.
2. Conversation History Overhead: Bản ghi gửi đi (JSON payload) nằm lại trong lịch sử chat. Nếu chat tiếp, toàn bộ payload này sẽ bị tính token lặp đi lặp lại ở các turn sau.
3. Verbose Protocol Format: Format JSON-RPC của MCP cộng thêm cách LLM output JSON Tool Call chiếm nhiều token hơn hẳn một lệnh REST/gRPC thuần.

Để giải quyết vấn đề này mà vẫn giữ được tính năng tạo bản ghi qua MCP, bạn có thể áp dụng các chiến lược tối ưu sau:

1. Tối ưu MCP Tool Definition (Rút gọn Schema)

• Thu gọn JSON Schema: Xóa bỏ toàn bộ phần description dài dòng trong từng field nếu tên field đã đủ rõ nghĩa (ví dụ: customer_name thay vì description: "The full name of the customer to be created in the database").
• Dùng Batch Create / Bulk Tool: Thay vì định nghĩa tool tạo 1 bản ghi với 20 field chi tiết, hãy hỗ trợ truyền một chuỗi rút gọn, CSV, hoặc JSON nén.
• Tách Tool “Khởi tạo” và “Chi tiết”: Tạo tool nhẹ với các tham số bắt buộc (Required Fields), các tham số tùy chọn (Optional) để mặc định ở phía Server hoặc truyền qua payload phụ.

2. Tái cấu trúc Luồng (Architecture / Pattern Adjustments)

A. Dùng Reference / Draft ID (Pattern hai bước)

Thay vì bắt LLM tạo toàn bộ JSON lớn qua MCP:

1. LLM gọi tool MCP nhẹ: create_draft(entity_type) $\rightarrow$ Server trả về draft_id và một URL/Form đơn giản hoặc temp file.
2. LLM fill dữ liệu hoặc hướng dẫn người dùng fill trực tiếp, sau đó chỉ gọi commit_draft(draft_id) với các trường cần override.

B. Nén Payload qua Format ngắn hơn (YAML / TSV / Compact DSL)

Thay vì bắt LLM output JSON chuẩn MCP với nhiều cú pháp đóng mở ngoặc { ... }:

• Định nghĩa Input Schema của Tool nhận 1 string duy nhất là data.
• Cho LLM truyền chuỗi theo dạng key: value ngắn hoặc CSV/YAML/DSL. Server MCP sẽ tự parse chuỗi đó thành object đầy đủ để insert DB.

C. Dùng MCP Context Truncation / History Pruning

• Xóa Tool Output thừa: Ngay khi Server MCP trả về kết quả thành công (ví dụ: {"status": "success", "id": 1024}), phía Client/Agent nên chủ động prune (cắt bỏ) bớt payload gửi lên ở lượt tool call đó, chỉ giữ lại kết quả ngắn Inserted ID: 1024.
• Tránh lưu trữ lại toàn bộ input payload cực lớn trong messages array của LLM Context.

3. Chọn Model nhỏ hơn cho tác vụ CRUD

Nếu hệ thống của bạn dùng Agentic Workflow:

• Không nên dùng các model lớn (như Claude 3.5 Sonnet / GPT-4o) chỉ để làm nhiệm vụ map dữ liệu vào MCP Tool Call.
• Đẩy tác vụ extract thông tin và gọi MCP Create Tool cho các model nhỏ hơn, nhanh hơn và rẻ hơn (như Claude Haiku, GPT-4o-mini, Qwen-Coder/Llama-3-8B local) xử lý riêng.

Tóm tắt giải pháp ngắn hạn thực thi ngay:

Rút gọn description trong Input Schema của Tool + Prune lịch sử Chat (chỉ giữ ID trả về, xóa payload gửi đi) là 2 việc giúp giảm ngay 50% – 70% lượng token lãng phí.

---

Đây là điểm “đau đầu” rất đặc trưng khi dùng MCP (Model Context Protocol). Nguyên nhân chính khiến token tăng vọt là vì MCP gửi kèm theo JSON Schema của Tool (parameters, descriptions, types) cùng với toàn bộ System Prompt / Context vào mỗi lượt gọi API để LLM hiểu cách structured output.

Dưới đây là các kỹ thuật thực tế giúp cắt giảm từ 50% – 80% lượng token tiêu tốn khi tạo record qua MCP:

1. Thu gọn Schema của MCP Tool (Schema Slimming)

LLM không cần những mô tả quá hoa mỹ trong JSON Schema để gọi hàm đúng.

• Bỏ description dư thừa: Chỉ giữ lại description ở những trường thực sự dễ gây nhầm lẫn.
• Xóa bỏ các trường Optional không cần thiết: Nếu tool tạo record có 30 trường nhưng chỉ 5-7 trường là bắt buộc khi khởi tạo, hãy tách thành 2 tool hoặc ẩn bớt các trường optional khỏi Schema chính.
• Rút gọn tên property: Thay vì created_at_timestamp_utc, dùng created_at.

2. Dùng Pattern “Pass-by-Reference” thay vì “Pass-by-Value”

Khi tạo một bản ghi phức tạp (ví dụ: tạo Hóa đơn kèm 20 Line Items, thông tin Khách hàng, Địa chỉ):

• Cách tốn token (Pass-by-Value): Nhồi toàn bộ thông tin chi tiết của Khách hàng, Sản phẩm vào Tool Call payload.
• Cách tiết kiệm token: Chỉ truyền customer_id, product_id và quantity. Server MCP sẽ tự lookup/query DB để lấy chi tiết tên, giá, thuế… thay vì bắt LLM “nhắc lại” toàn bộ thông tin đó.

3. Tách Tool: Mini-Create vs. Full-Create

Nếu MCP Tool của bạn định nghĩa một Schema quá lớn (ví dụ: 50 fields cho 1 ERP Record):

• Tạo Tool create_record_quick: Chỉ chứa 3–5 field bắt buộc để insert nhanh.
• Tạo Tool update_record: Để bổ sung chi tiết sau nếu cần.
• Điều này giúp LLM chọn Tool nhỏ gọn hơn trong hầu hết các tác vụ khởi tạo cơ bản mà không phải nạp toàn bộ Schema khổng lồ vào Context Window.

4. Nén Payload Trả về (Response Trim)

Nhiều người chỉ chú ý Input Token mà quên mất Output Token / Context Accumulation từ kết quả trả về của MCP Tool:

• Khi MCP Server thực thi xong lệnh create_record, đừng trả về nguyên Object vừa insert kèm theo 100 metadata fields của DB (created_by, updated_at, internal_hash, v.v.).
• Chỉ trả về gọn nhẹ:JSON{ "status": "success", "id": "REC-12345" } Nếu LLM cần thông tin chi tiết hơn, nó có thể gọi get_record(id).

5. Tối ưu MCP Prompt Instructions (System Level)

Nếu bạn điều khiển được phía Client/Host application:

• Filter Tools theo Context: Đừng nạp toàn bộ 30-40 MCP Tools vào LLM cùng một lúc nếu lượt chat đó chỉ đang làm công việc quản lý dữ liệu bản ghi. Dùng Tool Filtering / Routing để chỉ expose đúng 2-3 tools liên quan đến tác vụ hiện tại.
• Rút ngắn Instruction: Viết hướng dẫn cách gọi Tool ngắn gọn, dùng định dạng bullet point rõ ràng thay vì câu văn dài dòng.