Usually yes for anything touching real data. Put read tools on one server or connection and write tools on another, each with its own credentials. Most agents then run with read only access, and write access becomes a deliberate extra grant that can be approved, logged and revoked on its own.
The problem with a combined server
When one server exposes search, update and delete together, the credential behind it needs all three powers. Every agent that connects inherits that credential's reach, even if its task is only to look things up. A narrower token cannot fix this if the server uses one shared backend identity.
The MCP security guidance on scope minimization describes the same pattern for scopes. It warns against omnibus scopes and recommends a minimal initial set of low risk read operations, with elevation requested only when a privileged operation is first attempted.
What a split looks like
| Design | Read access | Write access | Revoke write alone |
|---|---|---|---|
| One server, one credential | Yes | Yes | No |
| One server, scopes per tool | Yes | If scope granted | Yes, if scopes are enforced |
| Two servers, two credentials | Server A | Server B | Yes, cleanly |
Scopes per tool are a fair middle option when the server enforces them on every call. The two server design is stronger because the boundary is physical: a read agent has no route to the write credential at all.
Steps to split
- List the tools on the existing server and mark each read, write, delete or send.
- Create a read credential at the downstream system with read permission only. Test that a write attempt fails.
- Stand up the write tools as a second server, with a separate credential and a separate allow entry.
- Connect most agents to the read server only. Add the write server to the agents that have a documented need.
- Put an approval rule on the write server's tools, and log every call with the agent identity.
When it is overkill
A small internal tool with test data and one user does not need two servers. Use scopes, keep the credential narrow and revisit when the data becomes real. Split when the cost of a wrong write exceeds the effort of running a second connection.
What to watch
Keep the downstream permissions aligned. A read server whose backend account can still write is a split in name only. Check the account's real permissions, not the tool list.
Safeguard offers MCP Guardrail and agent identity for applying this kind of policy to agent tool calls, and you can run a free scan of your own repositories at gold.safeguard.sh/scan. Autonomous fix pull requests are off by default, and every category starts on Manual.
Quick check
Is one server with scoped tokens good enough?
It can be, if the server enforces scopes on every call and the downstream account is also narrow. Two credentials give a cleaner boundary.
Who should hold the write credential?
The write server, not the agent. The agent only reaches it through the approved tool calls.
Sources
Last reviewed: 19 October 2026.
