Engineering / Field guide
MCP tool permissions: separate a lookup from a write
Reading a delivery address and changing one are different privileges. Make those differences explicit in the tools a server offers.
2XD Studio · · 2 min read
Start with the caller's authority
Write a small matrix with roles down the side and operations across the top. A support rep might read shipping status, a dispatcher might propose a correction, and a supervisor might approve it. Enforce those decisions on the server. A tool description can guide an assistant but cannot prevent an unauthorized API call.
Show the proposed change
For a write, present the target record and the before-and-after values at the approval step. Bind the approval to that specific proposal. If the order or destination changes while the proposal is waiting, require another review. Keep credentials in the integration layer rather than passing secrets into the conversation.
Design a useful audit entry
Record the acting identity, operation, target, outcome, and a reference to the approval. Avoid writing unnecessary customer data to logs. Test a denied operation, a stale approval, and two attempts to apply the same change. A green test for an authorized user covers only one corner of this design.
Try an approval race
Two operators open the same change proposal. The first updates the address; the second approves an older version. Compare the current record version with the version shown at review. Reject the stale approval and show the new state. That prevents an apparently valid confirmation from overwriting a correction made seconds earlier.
Reader questions
Can we use one powerful token for every caller?
That makes isolation harder. Where a backend requires a service identity, the server still needs enforceable per-caller authorization.
Does every write need human review?
Choose controls based on the consequences and reversibility of each action. A payment or address change deserves different treatment from saving a private draft.
Further reading MCP documentation: understanding servers