Xây Dựng MCP Server Cho Production: Bài Học Từ Thực Tế B2B Lead-Gen

Model Context Protocol (MCP) đã đi từ "spec thú vị của Anthropic" đến "cách AI agents giao tiếp với thế giới thực" chỉ trong khoảng sáu tháng. Đến giữa năm 2026, mọi công cụ AI coding, agent framework, và nền tảng tự động hóa enterprise đều có hỗ trợ MCP. Tôi đã build pp-mcp-leadgen — MCP server của Parcel Perform cho B2B lead-gen tooling — và tôi muốn chia sẻ việc build một MCP server production thực sự trông như thế nào, vượt ra ngoài tài liệu quickstart.

MCP Thực Sự Là Gì (Qua Cơn Hype)

MCP là một protocol cho phép các AI model khám phá và gọi tools được host trên external servers qua giao diện JSON-RPC tiêu chuẩn. Hãy nghĩ đó như một REST API có typing được thiết kế đặc biệt cho LLM consumption — các tool definitions (tên, mô tả, input schema) là hợp đồng mà model đọc để quyết định gọi gì và gọi như thế nào.

Điểm mấu chốt: MCP chuyển tool definitions ra khỏi application code và vào một standalone server. Điều này có nghĩa là tools của bạn có thể tái sử dụng trên các agents khác nhau, models khác nhau, và orchestration frameworks khác nhau — mà không cần viết lại integration logic mỗi lần.

Kiến Trúc của pp-mcp-leadgen

MCP server của chúng tôi expose sáu tools cho Sales Agent: prospect_lookup (Apollo), company_enrich (Clearbit), email_validate, crm_check (HubSpot), linkedin_signal, và campaign_history. Graph LangGraph của Sales Agent gọi các tools này khi cần trong phase enrichment.

# Tool definition pattern that works well for LLM consumption
{
    "name": "prospect_lookup",
    "description": "Look up a B2B prospect by email or LinkedIn URL. Returns company, role, seniority, and contact confidence score. Use before drafting outreach.",
    "inputSchema": {
        "type": "object",
        "properties": {
            "email": {"type": "string", "description": "Business email address"},
            "linkedin_url": {"type": "string", "description": "LinkedIn profile URL"}
        },
        "oneOf": [{"required": ["email"]}, {"required": ["linkedin_url"]}]
    }
}

Cạm Bẫy Khi Thiết Kế Tool: Những Gì LLM Cần Mà Con Người Không Cần

1. Tên Tool Là Prompt

Model đọc tên tool và description của bạn để quyết định khi nào và cách dùng nó. Tên như "get_data" hay "fetch" vô nghĩa. Tên như "prospect_lookup" hay "campaign_history" cho model biết domain, action và object dự kiến — trong hai từ. Description text còn quan trọng hơn: giải thích *khi nào nên dùng* tool, không chỉ nó làm gì.

2. Độ Granular: Một Tool Cho Một Quyết Định

Ban đầu chúng tôi có một tool "enrich_prospect" duy nhất gọi Apollo, Clearbit và HubSpot trong một lần. Vấn đề: khi enrichment thất bại một phần, agent không thể retry chỉ nguồn bị lỗi. Tách tool theo data source và để agent compose. Granularity nhỏ hơn = agent reasoning đáng tin cậy hơn.

3. Return Schema Mà Model Có Thể Navigate

Giữ return objects phẳng và có nhãn rõ ràng. Model phải reasoning về output của bạn. JSON lồng nhau sâu với tên key chung chung buộc model phải đoán. Chúng tôi đã flatten mọi thứ thành typed fields với tên mô tả: "company_employee_count" thay vì "data.company.size". Một buổi chiều thiết kế lại response schema giảm 30% token prompt.

Các Vấn Đề Production

Xác thực: MCP server của chúng tôi dùng API key auth theo từng client. Key được rotate hàng tháng qua AWS Secrets Manager — agent fetch key lúc khởi động, không phải mỗi call.

Rate limiting: mỗi upstream tool (Apollo, HubSpot) có rate limit riêng. Chúng tôi implement token buckets theo từng tool bên trong MCP server. Agent không bao giờ thấy upstream rate limit errors — nó thấy response gọn gàng "tool tạm không khả dụng, thử lại sau Xs", mà LangGraph xử lý gracefully.

Observability: mỗi tool call log vào ELK với: tên tool, input hash (không phải raw input vì lý do PII), latency, upstream status, và campaign ID. Điều này giúp chúng tôi phát hiện upstream APIs bị suy giảm trước khi chúng cascade thành agent failures.

Giá Trị Thực: Khả Năng Tái Sử Dụng

Sales Agent là MCP consumer đầu tiên của chúng tôi. Ba tháng sau, chúng tôi kết nối cùng một MCP server với một AI Visibility scoring pipeline cần dữ liệu company enrichment. Không thay đổi gì ở MCP server — pipeline chỉ đăng ký là client mới. Đây là giá trị thực sự của MCP như infrastructure: build tool layer một lần, kết nối nhiều agents với nó.

Kết Luận

Nếu bạn đang build AI agents cần giao tiếp với external APIs, hãy build một MCP server — dù hôm nay bạn chỉ có một agent. Protocol buộc bạn viết tool interfaces gọn gàng, được mô tả tốt, giúp agents đáng tin cậy hơn. Đầu tư vào description text của tool nhiều như implementation. Và thiết kế observability từ đầu: bản thân tương lai của bạn sẽ debug agent runs lúc 2 giờ sáng và sẽ cảm ơn bạn.