Danh sách kiểm tra Máy chủ MCP trong Môi trường Sản xuất: Từ Công cụ đến Hành động đáng tin cậy

TL;DR

• Danh sách kiểm tra máy chủ MCP sản xuất nên xác minh hành động đằng sau mỗi công cụ, không chỉ là việc máy chủ có kết nối và liệt kê công cụ hay không.
• Áp dụng quyền hạn của người gọi cho tài nguyên và thao tác cụ thể trước khi thực hiện yêu cầu.
• Giữ tham số công cụ, nội dung được truy xuất, thông tin xác thực và trạng thái thuê bao ở bên đúng của ranh giới ứng dụng.
• Kiểm thử các hành động bị từ chối, đầu vào không hợp lệ, kết quả không chắc chắn và quyền truy cập bị thu hồi trước khi mở rộng triển khai.
• Phát hành với người phụ trách, kết quả có thể quan sát được và cách dừng công việc mới trong khi cân đối các thao tác đang tiến hành.

Sản phẩm sẵn sàng cho sản xuất là gì đối với máy chủ MCP?

Sản phẩm sẵn sàng cho sản xuất có nghĩa là máy chủ MCP có thể thực hiện công việc được phép với sự phê duyệt rõ ràng, kết quả dự đoán được và bằng chứng về lỗi hữu ích. Một kết nối thành công chỉ chứng minh rằng khách hàng và máy chủ có thể giao tiếp. Nó không chứng minh rằng người đúng có thể thực hiện hành động đúng trên tài nguyên đúng. CapSolver có thể cung cấp khả năng CAPTCHA được tài liệu hóa trong quy trình tác nhân, trong khi ứng dụng của bạn vẫn chịu trách nhiệm cho các quy tắc thực thi rộng hơn.

Xét một công cụ gửi nhiệm vụ và một công cụ nhận kết quả của nó. Cả hai có thể hoạt động riêng lẻ trong khi hệ thống vẫn cho phép một thuê bao đọc nhiệm vụ của thuê bao khác. Một cuộc kiểm tra phát hành cần xem xét mối quan hệ này. Bắt đầu từ hành động và người phụ trách của nó, sau đó mở rộng qua giao thức, thời gian chạy và quy trình vận hành.

Kiểm tra hợp đồng công cụ trước cài đặt triển khai

Hợp đồng công cụ nên giải thích hành động được phép, đầu vào cần thiết, ý nghĩa của kết quả và hành vi khi lỗi xảy ra. Mô tả rõ ràng giúp tác nhân chọn công cụ, nhưng máy chủ phải thực thi các giới hạn thực tế.

Thông tin chính thức thư mục công cụ MCP định nghĩa việc phát hiện công cụ, gọi, lược đồ và xử lý kết quả. Xem phiên bản giao thức đã triển khai là lựa chọn tương thích rõ ràng. Không sao chép bao yêu cầu cũ vào triển khai mới mà không kiểm tra phiên bản mà khách hàng và máy chủ của bạn sử dụng.

Đối với mỗi công cụ, viết mô tả hoạt động ngắn độc lập với tên thương mại của nó. Xác định tài nguyên mà nó có thể truy cập, liệu nó có thể tạo ra hiệu ứng phụ hay không và bằng chứng nào xác định việc hoàn thành. Nếu không ai có thể định nghĩa kết quả một cách chính xác, công cụ đó không sẵn sàng cho đối tượng sản xuất rộng rãi.

Tránh tên hành động mơ hồ

Một tên như "xử lý yêu cầu" để lại quá nhiều điều chưa được xác định. Ứng dụng nên biết liệu thao tác đọc một bản ghi, gửi một nhiệm vụ đã thanh toán hay thay đổi cấu hình. Hãy làm rõ những khác biệt này trong mô tả công cụ và thực thi trong mã.

Liệt kê các giả định. Công cụ có yêu cầu phiên đăng nhập hiện tại không? Nó hoạt động trên một nhiệm vụ đã tạo trước đó không? Kết quả có thể đến sau khi người gọi dừng chờ không? Những câu hỏi này xác định mô hình trạng thái của ứng dụng và quy trình hỗ trợ.

Kiểm tra quyền truy cập tại ranh giới tài nguyên

Quyền truy cập nên được kiểm tra cho hành động và tài nguyên cụ thể bằng cách sử dụng bối cảnh người gọi đáng tin cậy. Biết ai đã kết nối không đủ để quyết định liệu người gọi đó có thể sử dụng một tham chiếu nhiệm vụ hoặc đích cụ thể hay không.

Hướng dẫn phê duyệt của OWASP khuyến nghị nguyên tắc ít quyền hạn nhất, từ chối mặc định và kiểm tra quyền hạn trên các yêu cầu. Áp dụng các nguyên tắc này cho các thao tác đầu ra cũng như điểm vào MCP.

Sử dụng định nghĩa bảo mật API cho khái niệm rộng hơn. Trong triển khai cụ thể, tài liệu quan trọng là mối quan hệ được triển khai giữa người gọi, hành động và tài nguyên. Tên thuê bao do mô hình cung cấp không nên ghi đè lên tên thuê bao được xác định bởi ứng dụng đã xác thực.

Kiểm thử yêu cầu chéo thuê bao một cách chủ động

Tạo tài nguyên thử nghiệm tạm thời cho các thuê bao riêng biệt và xác minh rằng một thuê bao không thể truy xuất hoặc sửa đổi tài nguyên của thuê bao khác. Sử dụng môi trường và tài khoản kiểm tra của bạn. Ghi lại kết quả từ chối mà không tiết lộ nội dung được bảo vệ của tài nguyên.

Lặp lại cuộc kiểm tra cho việc truy xuất kết quả nhiệm vụ, tải xuống và các thao tác chậm trễ. Một điểm cuối tạo nhiệm vụ an toàn không xác định rằng mọi truy vấn sau đó sử dụng cùng kiểm tra quyền sở hữu. Kiểm tra nên theo dõi toàn bộ quy trình thay vì chỉ yêu cầu đầu tiên.

Tách biệt thông tin xác thực khỏi tham số công cụ

Thông tin xác thực nên được cung cấp qua ranh giới thời gian chạy đáng tin cậy, không phải là tham số công cụ do mô hình tạo ra. Mô hình có thể chọn thao tác được phép; nó không nên được yêu cầu lặp lại một bí mật sản xuất trong nội dung yêu cầu có thể nhìn thấy bởi cuộc trò chuyện.

Hướng dẫn bảo mật MCP thảo luận về các rủi ro bao gồm truyền token, giả mạo yêu cầu và lạm dụng xử lý trạng thái. Áp dụng các biện pháp kiểm soát phù hợp cho triển khai của bạn thay vì coi kết nối MCP là lớp bảo mật tự động.

Đối với máy chủ từ xa, xác minh xem máy chủ chấp nhận danh tính nào và sử dụng thông tin xác thực nào ở phía dưới. Đối với máy chủ cục bộ, xem xét tệp thực thi, nguồn gốc của nó và quyền truy cập vào hệ tệp và mạng được cấp bởi máy chủ. Một quy trình được khởi chạy cục bộ vẫn có thể sở hữu quyền lực đáng kể.

Xem xét dữ liệu được trả về cho tác nhân

Kết quả công cụ có thể chứa văn bản không đáng tin cậy từ trang, tài liệu hoặc hệ thống bên ngoài. Giữ nguyên trạng thái của nó như dữ liệu nhiệm vụ. Một tài liệu yêu cầu tác nhân thay đổi hướng dẫn hoặc tiết lộ khóa không thể cấp quyền thực hiện điều đó.

Giữ kết quả tập trung vào kết quả của thao tác. Trả về tệp cấu hình đầy đủ hoặc kho lưu trữ mạng thô có thể tiết lộ nhiều hơn những gì tác nhân cần. Định nghĩa hình dạng kết quả an toàn và đặt tài liệu chẩn đoán chi tiết phía sau các quyền truy cập phù hợp.

Xác minh đầu vào ngoài hình dạng JSON

Xác minh đầu vào nên kiểm tra cả cấu trúc và ý nghĩa. Một chuỗi hợp lệ không nhất thiết là đích được phép, một định danh nhiệm vụ do người gọi sở hữu hoặc một thao tác được phép.

Sử dụng tập các trường được chấp nhận hẹp cho mỗi công cụ và từ chối các giá trị không mong đợi tại ranh giới biết ý nghĩa của chúng. Các định danh tài nguyên nên được giải quyết dựa trên trạng thái đáng tin cậy. Các kiểm tra đích nên tính đến đường dẫn mạng thực tế, bao gồm chuyển hướng khi cần thiết, thay vì dựa vào tiền tố chuỗi bề ngoài.

Bản kiểm tra này là khung đánh giá ứng dụng, không phải triển khai bảo mật hoàn chỉnh. Xác minh URL, phê duyệt và tách biệt mạng cần các bài kiểm tra cụ thể cho từng triển khai. Biểu thức chính quy chung không thể xác định rằng người lấy dữ liệu an toàn cho mọi triển khai.

Giữ nguyên sự không chắc chắn thay vì đoán

Nếu một tham số mơ hồ, hãy trả về lỗi hữu ích hoặc yêu cầu thông tin thiếu qua tương tác được hỗ trợ của khách hàng. Không thay thế tham số sản xuất thiếu thốn cho tham số kiểm tra thiếu thốn một cách im lặng. Một mặc định có vẻ hữu ích có thể thay đổi phạm vi của hành động.

Xem xét cách khách hàng trình bày lỗi. Tác nhân nên có thể phân biệt đầu vào không hợp lệ với sự cố dịch vụ tạm thời. Ngược lại, nó có thể thử lại yêu cầu không thể thực hiện thay vì sửa thông tin thiếu.

Nhận mã thưởng CapSolver của bạn

Tăng ngân sách tự động hóa của bạn ngay lập tức!
Sử dụng mã thưởng CAP26 khi nạp tiền tài khoản CapSolver để nhận thêm 5% thưởng trên mỗi lần nạp — không giới hạn.
Nhận mã thưởng ngay lập tức trong Bảng điều khiển CapSolver

Định nghĩa Hoàn thành, Hết thời gian và Thử lại riêng biệt

Hoàn thành, hết thời gian và thử lại mô tả các trạng thái khác nhau và nên dẫn đến các quyết định khác nhau. Ứng dụng cần biết liệu một thao tác bị từ chối trước khi thực hiện, vẫn đang chạy, kết thúc thành công hay có kết quả không chắc chắn.

Đối với quy trình CapSolver được hỗ trợ, tài liệu dịch vụ MCP mô tả bề mặt tích hợp có sẵn. Giao diện kết quả nhiệm vụ cung cấp hợp đồng kết quả nhiệm vụ được tài liệu hóa. Sử dụng các nguồn này để diễn giải kết quả dịch vụ; không biến các nhãn do ứng dụng sở hữu thành trạng thái do nhà cung cấp giả định.

Nếu một yêu cầu có thể tạo ra nhiệm vụ thanh toán hoặc hiệu ứng phụ khác, một thời gian hết hạn nên kích hoạt cân đối trước khi nộp lại. Xác định bất kỳ tham chiếu nhiệm vụ từ xa nào đã nhận và xác định điều mà dịch vụ có thể xác định. Một khách hàng đã dừng chờ không nhất thiết đã hủy bỏ công việc từ xa.

Đặt giới hạn tại người sở hữu mỗi tài nguyên

Ứng dụng nên thực thi thời hạn tổng thể và ngân sách thử lại. Các giới hạn được tài liệu hóa của dịch vụ vẫn riêng biệt. Một tác nhân không nên có thể đặt lại ngân sách tổng thể bằng cách gọi cùng công cụ dưới mô tả mới.

Đối với công việc kéo dài, xác định điều gì xảy ra khi máy chủ thoát hoặc quyền được thu hồi. Dừng các hành động mới không còn được phép và cân đối các công việc còn lại theo ngữ nghĩa của thao tác. Không hứa hẹn kết quả chính xác một lần trừ khi triển khai thực sự cung cấp và kiểm tra nó.

Sử dụng danh sách kiểm tra phát hành với bằng chứng có thể quan sát được

Danh sách kiểm tra phát hành nên kết hợp mỗi yêu cầu với quan sát cụ thể và người phụ trách. Các mục đánh giá sau đây là các đề xuất cho triển khai của bạn, không phải là chứng nhận hay tuyên bố rằng bất kỳ máy chủ nào được tên đã vượt qua chúng.

Vùng đánh giá	Bằng chứng cần thu thập	Quyết định phát hành
Hợp đồng công cụ	Hành động được phép, đầu vào, kết quả và hiệu ứng phụ	Từ chối các hành động sản xuất mơ hồ
Phê duyệt tài nguyên	Yêu cầu được phép và bị từ chối cho tài nguyên thử nghiệm	Giải quyết truy cập không được phép trước khi triển khai
Cách ly thuê bao	Kiểm tra truy xuất chéo thuê bao và thử nghiệm kết quả chậm trễ	Giữ nội dung được bảo vệ tách biệt
Xác minh đầu vào	Tham số không hợp lệ, thiếu và ngoài phạm vi	Trả về từ chối có thể dự đoán
Xử lý bí mật	Xem xét đầu vào, đầu ra, nhật ký và tài liệu	Loại bỏ việc tiết lộ thông tin xác thực
Xử lý lỗi	Trường hợp hết thời gian, kết quả không chắc chắn và lỗi dịch vụ	Định nghĩa hành vi cân đối và dừng
Thu hồi	Người gọi bị thu hồi cố gắng thực hiện công việc mới	Áp dụng quyền hạn thay đổi
Thao tác	Người phụ trách được đặt tên, giám sát và quy trình dừng	Làm cho lỗi có thể hành động

Chạy các trường hợp trên triển khai thực tế trong môi trường được kiểm soát. Tài liệu liệt kê hành vi mong muốn không phải là bằng chứng rằng máy chủ thực thi nó. Giữ phiên bản đã kiểm tra, cấu hình khách hàng và kết quả liên quan để một thay đổi sau này có thể được xem xét theo cùng ranh giới.

Bao gồm các trường hợp nên thất bại. Quy trình phát hành chỉ minh họa các cuộc gọi công cụ thành công cung cấp ít thông tin về phê duyệt hoặc kiểm soát. Từ chối nên là kết quả mong đợi rõ ràng, không phải ngoại lệ không giải thích ẩn trong báo cáo kiểm tra.

Lên kế hoạch triển khai và quy trình dừng cùng nhau

Lên kế hoạch cách mở rộng triển khai và cách dừng công việc mới trước khi sử dụng sản xuất. Một đối tượng ban đầu hẹp và tập hợp các thao tác hạn chế dễ quan sát liệu hợp đồng công cụ có khớp với việc sử dụng thực tế hay không.

Theo dõi các kết quả có ý nghĩa: các hành động được phép hoàn thành, yêu cầu bị từ chối, các thao tác chưa giải quyết và lỗi theo danh mục. Tránh coi số lượng cuộc gọi công cụ là bằng chứng về giá trị kinh doanh. Số lượng cuộc gọi tăng có thể phản ánh các thất bại lặp lại hoặc mô tả công cụ gây nhầm lẫn.

Hướng dẫn thiết lập MCP của CapSolver bao gồm kết nối ban đầu và bối cảnh sử dụng. Đánh giá sản xuất thêm bằng chứng phát hành và sở hữu vận hành. Xem lại các biện pháp kiểm soát khi công cụ, thông tin xác thực, quyền người dùng hoặc dịch vụ phía dưới thay đổi.

Giữ cách để vô hiệu hóa công cụ có vấn đề mà không mất các tham chiếu cần thiết để điều tra công việc đang tiến hành. Tài liệu ai có thể đưa ra quyết định đó và cách người dùng biết một thao tác không khả dụng. Quy trình dừng nên giữ lại bằng chứng hữu ích trong khi tuân thủ các yêu cầu lưu trữ dữ liệu.

Phát hành các hành động bạn có thể giải thích và kiểm soát

Một máy chủ MCP sản xuất nên hiển thị các hành động mà nhóm bạn có thể giải thích. Xác minh triển khai với các trường hợp tiêu cực được kiểm soát và giữ lại đủ bằng chứng để vận hành một cách có trách nhiệm. Sử dụng CapSolver để các nhiệm vụ thử thách được tài liệu hóa và được phép trong hệ thống đó, với ứng dụng xung quanh thực thi các ranh giới tài nguyên và thực thi của riêng nó.

Câu hỏi thường gặp

Câu hỏi: Một kết nối MCP thành công có chứng minh tính sẵn sàng cho sản xuất không?

Không. Nó chỉ chứng minh giao tiếp tại thời điểm đó. Tính sẵn sàng cho sản xuất cũng yêu cầu quyền truy cập được xác minh, xử lý đầu vào, hành vi lỗi và sở hữu vận hành cho các công cụ thực tế.

Câu hỏi: Mô hình có nên cung cấp tên thuê bao hoặc thông tin xác thực dịch vụ không?

Bối cảnh ứng dụng đáng tin cậy nên xác định tên thuê bao của người gọi và cung cấp thông tin xác thực dịch vụ qua ranh giới thời gian chạy phù hợp. Các tham số do mô hình tạo ra không nên ghi đè các biện pháp kiểm soát này.

Câu hỏi: Điều gì sẽ xảy ra sau khi cuộc gọi công cụ hết thời gian?

Xác định liệu thao tác bị từ chối, vẫn đang hoạt động hay có kết quả không chắc chắn. Cân đối các hiệu ứng phụ có thể trước khi nộp lại cùng công việc.

Câu hỏi: Danh sách kiểm tra này có phải là chứng nhận tuân thủ MCP không?

Không. Đó là khung đánh giá ứng dụng thực tế. Tương thích giao thức và bảo mật yêu cầu kiểm tra đối với phiên bản triển khai, thời gian chạy, quyền hạn và các thao tác phía dưới.