MCP for team workflows: scopes, owners, receipts
If you want MCP connectors to be safe for a whole team, write one short card per server that names what it may do, what it must not, and who owns the rollback. MCP, the Model Context Protocol, is an open standard for wiring agents to external tools and data. A connector is one of those wired tools. Treat every connector as a production dependency, with a declared scope, a named owner, and a written rollback, and most of the surprises stop.
The retro apology is always the same. We knew the connector could touch that data, we just never wrote it down. This piece is about writing the boring stuff down before the incident, not after.
Why connectors keep surprising reviewers
Connectors ship as capability demos. A demo shows everything a server can do, which is the opposite of what a team needs, which is the smallest set of things it should do.
So a server without a written boundary eventually touches data nobody put on the diagram. Each layer of defense, your prompts, your rule files, your reviewers, has holes in it. The day those holes line up is the day an unowned connector causes silent rework.
More connectors do not add capability on their own. Unowned connectors add cleanup. The fix is cheap: a card per server, kept short on purpose.
Write one connector card per server
A connector card has four fields and lives in your repo as plain markdown. Allowed actions, forbidden actions, a named owner, and the rollback step. That is the whole thing.
Keep it operational. The card's job is to tell whoever is on call what "off" looks like, not to document the API. Here is a card you can paste and edit:
## Connector: github-mcp
- Allowed: read PRs, read issues, comment on PRs
- Forbidden: push to main, delete branches, edit secrets
- Owner: @maria (platform team)
- Rollback: revoke token in settings, redeploy agent with github disabled
Wire servers from the Model Context Protocol spec as fast as you like. The card is what keeps a fast setup from becoming a quiet one.
Match the artifact to the tool
Different agents leak in different ways, so the boundary lives in a different file for each. The pattern is the same: state the scope where the tool reads it.
| Tool | Where surprises start | What to write |
|---|---|---|
| Cursor | .mdc rules read as vague until reviewers argue about them |
A scope ledger in the parent chat: goal, allowed paths, forbidden paths, verification command, merge owner |
| Claude Code | shared-laptop bash approvals become muscle memory | A precedence note at the top of CLAUDE.md: which hooks win, which folders need human eyes |
| Codex | CLI runs hide whether commands actually ran | A replay note in AGENTS.md: intent line, command transcript, diff summary before the PR |
| MCP servers | a server touches undeclared data | A connector card per server |
The Cursor agent docs explain how rules work, and Claude Code's docs cover hooks and permissions, but neither one knows your boundaries. You write those.
Run the connector audit before you merge
Four questions decide whether a connector-heavy merge is safe to approve. If your PR body can answer all four on its own, you can approve without standing behind a terminal.
- Replay proof: which commands prove the regression guards ran?
- Receipt match: does the PR body list scopes plus a verification transcript?
- Rules precedence: which
.mdc,SKILL.md, orCLAUDE.mdgoverned behavior? - Connector truth: which MCP servers fired, and were they expected?
If your repo cannot state its boundaries plainly, the agent will guess, and guessing scales badly. This is the review habit we teach under our methodology: evidence beats narration when a merge touches shared surfaces, and it sits inside the broader agentic coding governance track.
Try one card this week
Pick the connector you trust least, write its four-field card, and put the owner's name on it. Our training wires those cards into your live MCP setup with the people who own the rollback in the room.