Hãy tưởng tượng việc xây dựng một máy chủ API duy nhất hoạt động ở mọi nơi, LSP đã làm được điều đó cho các lập trình viên, liệu MCP có phải là bước tiếp theo?
Trước năm 2016, việc hỗ trợ các ngôn ngữ lập trình trong IDE rất phức tạp.
Mỗi trình soạn thảo phải xây dựng bộ công cụ riêng cho mọi ngôn ngữ mà nó muốn hỗ trợ.
Đánh dấu cú pháp, tự động hoàn thành, linting, tất cả đều được xây dựng tùy chỉnh.
Điều này dẫn đến trải nghiệm rời rạc.
Một ngôn ngữ như JavaScript có thể mượt mà trong một trình soạn thảo, nhưng lại không đầy đủ trong một trình soạn thảo khác.
Và nếu bạn sử dụng một trình soạn thảo dựa trên terminal như VIM,
Bạn thường bị hạn chế về công cụ, hoặc không có gì cả.
Điều đó đã thay đổi khi @Microsoft giới thiệu Language Server Protocol (LSP).
Thay vì các trình soạn thảo và ngôn ngữ xây dựng tích hợp từ đầu,
LSP đã tạo ra một cách tiêu chuẩn để chúng giao tiếp.
Các ngôn ngữ giờ đây có thể cung cấp một máy chủ LSP duy nhất,
Và bất kỳ trình soạn thảo nào có client LSP đều có thể kết nối.
Vì vậy, thay vì phải xây dựng một "plugin Go cho VSCode" và một "plugin Go cho Sublime,"
Bạn chỉ cần xây dựng một máy chủ Go LSP, và nó hoạt động ở mọi nơi. Đối với các nhà phát triển, điều này có nghĩa là các tính năng nhất quán hơn trên các trình soạn thảo.
Đối với những người bảo trì ngôn ngữ, nó đơn giản hóa công việc hỗ trợ các công cụ mới.
Và đối với các trình soạn thảo, nó mở ra một danh sách dài các ngôn ngữ chỉ sau một đêm.
Ngày nay, LSP là thứ làm cho các công cụ như đánh dấu cú pháp và tự động hoàn thành trở nên liền mạch,
Bất kể bạn đang sử dụng ngôn ngữ nào hoặc trình soạn thảo nào bạn thích.
Đây là một hình ảnh đơn giản để cho thấy sự khác biệt giữa thiết lập trước và sau LSP:
Ngày nay, LSP đã âm thầm thay đổi cách các công cụ phát triển hoạt động.
Ngay cả các ngôn ngữ lập trình thích hợp giờ đây cũng có thể mang lại trải nghiệm tuyệt vời cho nhà phát triển trong các trình soạn thảo phổ biến.
Họ không cần phải ký kết các thỏa thuận trực tiếp với các IDE như VSCode hoặc Cursor,
Họ chỉ cần xây dựng một máy chủ LSP, và họ đã tham gia.
Về phía nhà phát triển, sự thay đổi này cũng rất quan trọng.
Chúng ta không còn chọn một IDE dựa trên hỗ trợ ngôn ngữ nữa.
Chúng ta chọn dựa trên thế mạnh của trình soạn thảo,
Giống như giao diện của Cursor hoặc khả năng AI của nó.
Tuy nhiên, việc áp dụng LSP không phải là phổ biến.
Một số hệ sinh thái, như JetBrains hoặc Xcode của Apple, vẫn thích các giao thức riêng của họ.
Nhưng đối với hầu hết, LSP đang trở thành cách tiêu chuẩn để các trình soạn thảo và công cụ ngôn ngữ kết nối.
Bây giờ, vào năm 2025, MCP đang tham gia vào cuộc trò chuyện.
Và đối với chúng tôi, nó có vẻ rất quen thuộc.
Sẽ không có gì đáng ngạc nhiên nếu cấu trúc của LSP giúp truyền cảm hứng cho nó.
Đây là so sánh:
Thay thế "ngôn ngữ lập trình" bằng các API của bên thứ ba như Stripe hoặc Supabase,
Và thay thế "IDE" bằng các AI chat client, @Cursor, Claude, @OpenAI, @vercel, hoặc @LangChainAI.
Đó là những gì MCP trông như thế nào.
Nếu MCP thành công, tác động có thể rất lớn.
Supabase sẽ không cần các tích hợp riêng biệt cho mọi AI client.
Nó sẽ chỉ xây dựng một máy chủ @supabase MCP,
Và bất kỳ client tương thích MCP nào cũng có thể kết nối.
Điều này có thể là một yếu tố thay đổi cuộc chơi cho các nhóm nhỏ.
Họ có thể cung cấp các công cụ đầy đủ tính năng cho người dùng trên bất kỳ nền tảng AI nào,
Mà không cần duy trì năm tích hợp khác nhau.
Nó thậm chí có thể làm cho các marketplace tích hợp trở nên lỗi thời.
Nếu trải nghiệm là nguyên bản trên các nền tảng,
Tại sao ai đó cần phải duyệt và cài đặt plugin theo cách thủ công?
Người dùng cuối sẽ được hưởng lợi nhiều nhất.
Họ sẽ có được trải nghiệm nhất quán, bất kể họ sử dụng công cụ AI nào.
Chúng tôi nghĩ rằng MCP có tiềm năng thực sự.
Và với @AnthropicAI dẫn đầu cùng với @State_Of_Mika.
Nó có thể trở thành tiêu chuẩn mới để liên kết các API của bên thứ ba với LLM.
Nếu bạn tò mò về cách LSP giải quyết một thách thức tương tự,
Bình luận gMika và chúng tôi sẽ gửi cho bạn hướng dẫn.
