Phạm vi nó với tới được
Ranh giới thành thật.
Vai trò của bạn quyết định những công cụ nào tồn tại
Máy chủ hành động với tư cách là bạn, trên kết nối mà bạn đã đặt làm kết nối đang hoạt động. Không có tài khoản dịch vụ riêng nào và không có quyền truy cập nào rộng hơn quyền của chính bạn. Kể từ khi vai trò ra mắt, cũng không có quyền truy cập nào rộng hơn VAI TRÒ của bạn. Danh sách công cụ mà một client nhận được dựng từ các quyền bạn nắm trong workspace đang hoạt động, nên client của một Viewer hoàn toàn không có sendEmail, createRule hay sendWithTemplate trong danh sách.
Đó là một điều mạnh hơn việc từ chối lời gọi. Một công cụ vắng mặt khỏi danh sách là công cụ mà mô hình không suy luận tới, không ngốn context, và không thể bị thử thay mặt ai đó rồi phải xin lỗi sau. Nó cũng có nghĩa là một client trông trống trải thường là do một quyền bạn không có chứ không phải một tính năng máy chủ này thiếu, và đó đúng là điều whoAmI tồn tại để cho bạn biết.
Đăng ký và gọi thực thi là hai cổng chắn, và chỉ cổng thứ hai là giữ được. Danh sách được dựng một lần, lúc phiên mở ra, và setActiveConnection có thể chuyển phiên đó sang một hộp thư nơi bạn được làm ít hơn, nên danh sách cũ đi ngay từ trong thiết kế và giao thức không có cách nào rút lại một công cụ giữa phiên. Vì vậy mọi công cụ có kiểm soát đều phân giải lại vai trò của bạn trên kết nối HIỆN TẠI trước khi chạy. Đăng ký là phép lịch sự; gọi thực thi mới là ranh giới.
Một lời từ chối nêu cả hai nửa, ví dụ Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, để một agent có thể giải thích lại cho người nó đang làm việc cho và dừng thử, thay vì gọi lại một lỗi mờ mịt cho tới khi ai đó bỏ cuộc. Một vai trò bị quản trị viên thay đổi trong lúc phiên đang mở cũng đến theo đúng cách đó, ngay ở lời gọi kế tiếp.
Địa chỉ là trục còn lại và không bị bất kỳ điều nào ở trên tác động. Vai trò nói bạn được làm gì; các địa chỉ được cấp cho bạn nói bạn được làm điều đó với hộp thư nào, và cả hai phải khớp nhau thì một thư mới đi ra được.
Bản thân token vẫn chưa có scope
Thứ KHÔNG thay đổi là phần cấp quyền. Token mà một ứng dụng nhận được với tới mọi thứ vai trò của bạn cho phép chứ không phải một tập con bạn chọn lúc chấp thuận, nên chấp thuận một client là chấp thuận cho nó mọi việc bạn làm được trong workspace đó. Bạn được cho biết ai đang yêu cầu trước khi bất cứ thứ gì được cấp, và Account → Connected apps là nơi gỡ nó về sau, xoá mọi token nó đang giữ cùng phần chấp thuận đằng sau, nhưng việc chọn “chỉ đọc, cho riêng ứng dụng này” thì chưa được xây dựng.
Vậy nên trần của một client MCP chính là trần của BẠN. Thu hẹp những gì một ứng dụng làm được nghĩa là thu hẹp vai trò của người đã kết nối nó, điều đó cũng thu hẹp luôn những gì họ làm được trong ứng dụng. Đó là hình hài thành thật của nó ngày hôm nay, và là lý do một scope riêng cho từng lần cấp quyền vẫn đáng để xây.
Bộ từ vựng thì đã dùng chung sẵn: quyền của một vai trò và scope của một API key đều rút ra từ cùng một bảng chữ cái, chính điều đó khiến thẩm quyền của một key tính được bằng giao của hai thứ. Một scope MCP riêng cho từng lần cấp quyền, khi ra mắt, sẽ được diễn đạt bằng đúng những từ đó.