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.
