A local MCP server starts as a convenience. Someone adds it to a config file, points it at a database, and uses it to speed up a task. Six months later, nobody remembers who owns it, what it can read, or why it has a write token.
That is the point where an MCP server stops being a helper and becomes infrastructure. Infrastructure needs an owner, a scope, logs, and a way to turn it off.
This is the checklist I use before an agent gets access to anything that matters.
1. Name an owner and a backup
Every MCP server needs one person who is accountable for it and one person who can revoke it. Put both names in the repository, next to the server configuration.
If the owner leaves the team, the server should not become a mystery. The backup should be able to explain what the server does, which credentials it uses, and how to disable it.
A simple line in the repo is enough:
Server: postgres-read
Owner: Dana
Backup: Miguel
Purpose: read-only customer lookup for support agents
Kill switch: remove the tool from the MCP config and revoke the database role
2. Write down the exact tool surface
Do not describe the server as "database access." List the tools and what each one can do.
For each tool, record:
- the input it accepts
- the data it returns
- whether it reads or writes
- the maximum result size
- the scope it can reach
A tool that runs SELECT against a read replica is a different risk from a tool that runs migrations. A tool that returns 50 rows is a different risk from a tool that returns the whole table.
If the tool list is too long to review, the server is too broad.
3. Scope credentials to the minimum
Use a separate credential for each MCP server. Do not reuse an admin token because it is convenient.
For a read-only server, use a read-only role. For a write-capable server, restrict it to the tables or actions it actually needs. If the server only creates draft records, it should not be able to delete them.
Store the credential in the environment or the OS credential store, not in the repository. Rotate it on a schedule and after any suspected exposure.
4. Log reads and writes separately
Most teams log errors and ignore successful tool calls. That makes it hard to answer basic questions:
- Which customer records did the agent read?
- Which records did it change?
- Which agent session made the change?
- What did the human verify before the change was accepted?
Log the tool name, the scope, the record IDs, and the session. Do not log raw secrets or full customer records. Separate read logs from write logs so a write review does not get buried in read noise.
5. Record provenance in the pull request
"The agent used the database" is not provenance. The pull request should say which server, which record, and what the human checked.
A useful line looks like this:
Source: postgres-read, customer 1842, subscription status changed on 2026-10-30
Human check: verified the cancellation reason in the billing dashboard
That line gives the reviewer something to inspect. It also makes the agent's reasoning auditable after the fact.
6. Test revocation before you need it
Revocation is not a document. It is a test.
Pick one server and walk through the shutdown:
- Remove the tool from the agent configuration.
- Revoke the credential.
- Confirm the agent can no longer call the tool.
- Confirm the audit log shows the failed attempt.
- Record how long the process took.
If the test takes an hour, the real incident will take longer. Do it while the system is calm.
7. Set a review cadence
MCP servers drift. A token that was read-only last quarter may have been widened for a demo. A tool that was internal may now be exposed to a customer-facing agent.
Review the server every quarter:
- Is the owner still on the team?
- Is the credential still scoped correctly?
- Are the tools still necessary?
- Are the logs still complete?
- Has the server been used in the last 30 days?
If nobody uses it, remove it. An unused server with a live credential is pure risk.
A read versus write example
Consider a memory server for a coding agent.
A read-only version can recall decisions and return the source. The worst case is a bad answer that a human catches.
A write-capable version can store a new decision, close an old one, or change the scope of a memory. The worst case is a corrupted project record that later agents treat as true.
The tool surface should make that difference obvious. The read tools should be separate from the write tools. The write tools should require an explicit scope and return a receipt.
How Engraphis handles this
Engraphis is the local-first memory server I built for coding agents. The governance model is the part I care about most.
- Memories are scoped by workspace, repository, and session.
- Every record keeps its provenance and temporal history.
- Superseded facts are closed, not silently overwritten.
- Recall is bounded and cited.
- The local dashboard lets you inspect, correct, and review conflicts.
- The local core is Apache-2.0 and free. Pro adds hosted memory health and sync.
The retrieval is useful. The ownership model is what makes it safe to leave running.
If you want the setup done for you
I do a fixed-scope MCP setup for teams. It includes:
- clean setup of Claude Code, Cursor, or Codex
- integration of up to three MCP servers
- environment, credential, and security configuration
- a one-page runbook with the owner, scope, logs, and revocation steps
- seven days of async text support
The price is $250, the turnaround is 24 hours, and the delivery is text only. No calls or screen sharing.
Start here: https://engraphis.com
Disclosure: I built Engraphis. This checklist comes from building and operating it, not from a certification or a vendor audit.
Top comments (1)
Item 6 is the only one on this list that produces evidence. The other six produce documents. That is not a criticism of them, it is the order I would implement them in.
Two things I would change.
The kill switch in item 1 is written in the wrong order. Remove the tool from the MCP config, then revoke the database role, leaves a window where a live session still holds an open connection and the tool is merely absent from new configs. Revoke the role first. The agent then fails loudly on its next call, which is also what item 6 is checking for. Config removal is reconfiguration, not revocation, and the two get written as one line.
Item 7 is quarterly against drift that is continuous. A credential widened for a demo on a Tuesday is caught up to ninety days later, by which time whoever widened it has lost the context. The cheap fix uses what item 2 already gives you. You have written down the exact tool surface, so diff it against the grants the database itself reports, in CI, every build. Declared surface against actual role, and the actual role is maintained by Postgres for its own reasons rather than by whoever wants the review to pass. A quarterly review reads a document. A nightly diff reads the system.
The one I would add is narrower, and it is what an auditor asks before any of this: which rows did the agent read, and can you answer that per customer rather than per session. Item 4 gets most of the way there by logging record IDs. The part that bites is retention, because the question arrives months after the log rotated out. In regulated work the access log has to outlive the incident by a long way, and that is a storage decision somebody makes once, early, usually by accident.