Constrain MCP Sampling Requests
Review legacy MCP sampling requests for user approval, data limits, provider destination, and migration from deprecated sampling.
MCP sampling lets a server ask a client to make a model call. In the 2026-07-28 specification, sampling is deprecated, and new implementations should not adopt it. Teams that already use it still need to control what a server may request while they plan a migration. Use this review only for an existing sampling flow while planning its removal.
A sampling request can move data from a server into a model context selected by the client. Map which server initiates the request, what context it can include, which model receives it, and how the user can deny it. The specification says applications should keep a human in the loop with the ability to reject sampling requests.
Legacy sampling policy
| Field | Required limit |
|---|---|
| Initiating server | Explicitly approved server identity |
| Prompt content | Data classification and size cap |
| Model destination | Approved provider and retention terms |
| Frequency | Per-task call and cost limit |
| User decision | Visible request with deny path |
| Evidence | Redacted request ID, decision, and result |
Do not let a server request unrelated conversation history merely because the protocol can carry context. Filter private data before it reaches the model broker. A prompt from a connected server is not a user instruction and cannot create new tool authority. Keep model credentials out of the server when the client owns the call.
Review and migration test
Use synthetic text in an owned client/server fixture. Submit an approved low-sensitivity request and confirm the user can inspect and allow it. Then submit a request containing a synthetic secret marker, an oversized context, and a request from an unapproved server. Each should be denied before provider transmission. Check the broker log or mock transport, not only the UI message.
Migration decision example
Existing call: an approved server asks the client to summarize one synthetic support note. Proposed replacement: a direct model-provider call by the application. Record the note's data class, approved provider, retention terms, spend owner, and audit event before switching. If any term is unknown, keep the flow held; old client consent does not authorize the new transfer. Test the replacement with a harmless note, then reject a secret-bearing note before provider transmission.
Know what your agents can reach
Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.