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.

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, or CLAUDE.md governed 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.

Common questions

• How should a team set up MCP for team workflows?

  Start with one markdown connector card per MCP server: allowed actions, forbidden actions, owner, rollback. Then add a scope ledger for agent runs and a replay note for CLI work. The protocol defines what a connector can technically do. The cards define what your team actually lets it do, which is the part that keeps reviews honest.

• What goes on a connector card?

  Four fields: allowed actions, forbidden actions, a named owner, and the rollback procedure. The card stays short by design, because its job is operational. It tells whoever is on call what "off" looks like before an incident happens. It is not API documentation, and trying to make it both makes it useless for both.

• Why do MCP connectors keep surprising reviewers?

  Connectors default to capability demos, while least privilege needs explicit trust boundaries that demos never include. Every defense layer has holes in it, so a server without a card eventually reaches data nobody listed on the diagram. The surprise was scheduled, not random. A card is what removes it from the schedule.

• When is a connector ready for team use?

  When its card exists, its owner is named, and the review gate can answer "which MCP servers fired, and were they expected?" from the PR body alone. Until those three things are true, the connector is still a demo. Demos are great for learning and bad in the merge path, so keep them out of it.

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.