Model Context Protocol is becoming the common connection layer for agents. The official docs describe it as an open standard for connecting AI applications to external systems: files, databases, tools, apps, and workflows.
That is useful. It also means MCP servers should be treated like software supply chain with inventory, ownership, and review.
The operating model
An MCP server deserves an owner, a purpose, a scope, and a review cycle. Without those four things, tool access grows faster than governance.
The record is intentionally plain. If the team cannot maintain this table, the MCP surface is already too broad.
The useful mental model
| Layer | Question to ask | Default posture |
|---|---|---|
| client | Which agent or app is allowed to call tools? | Named clients only |
| server | What data or action does this MCP server expose? | One purpose per server where possible |
| transport | Is this local stdio, HTTP, SSE, or streamable HTTP? | Treat remote access as a stronger boundary |
| credentials | Which secrets are available to the server? | Scoped, rotatable, never pasted into prompts |
| policy | Which actions need consent or review? | Writes and sends need explicit approval |
| logging | Can we reconstruct what happened? | Receipt or run log for meaningful work |
Start with inventory
Before adding more servers, write down what already exists.
- server name
- package source
- owner
- version
- transport
- scopes and credentials
- allowed clients
- data touched
- mutation rights
- log location
If you cannot list it, you cannot govern it.
The controls I want by default
This does not make MCP slow. It makes it operable. A business should be able to add a useful server without creating a hidden admin channel.
What to avoid
- wildcard scopes
- all-purpose admin tokens
- hidden startup commands
- servers installed from copied shell snippets
- tools that mutate records without a dry run
- multiple MCP clients sharing the same broad credential
How this connects to receipts
MCP is where the agent touches the world. That makes it part of the receipt trail.
For meaningful runs, the receipt should show which server class was used, how many tool calls happened, whether a mutation was requested, and whether approval was required. The public version can omit private arguments while still proving the work moved through a controlled path.
That is why MCP, harness design, and receipts belong in the same operating model. The model decides. The harness enforces. The MCP server touches the business surface. The receipt lets a person inspect the result.
Why this belongs on a marketing site
Om Concepts sells agents as operating systems, so the trust layer has to be visible. A visitor should see that agents do not just "connect to tools." They connect through an inventory, a permission model, and a receipt trail.
That is the difference between a demo and a system a business can live with.
Related agent notes
- Model vs harness vs environment
- Why we built our own agent harness
- Receipts prove each run
- AI services
- Security
