MCP servers are the connector layer between an AI client and the outside world.
A client like Claude Desktop, Claude Code, Cursor, or another MCP-aware tool talks to a server. The server exposes tools, resources, or prompts. Behind that boundary may be GitHub, a database, a browser, a filesystem, Slack, Notion, Home Assistant, or some custom script on your machine.
Official docs: Model Context Protocol introduction and MCP specification .
Where it fits
| Layer | MCP server role |
|---|---|
| Surface | Usually invisible; configured inside an AI client |
| Connector | Translates model requests into tool/API calls |
| State | Lives in the connected service or local system, not in MCP itself |
| Receipts | Config, scopes, tool call logs, external service logs |
| Risk | One bad server can expose too much authority |
MCP is not memory. It is not an agent. It is the plug socket. What you plug into it matters.
What a server can expose
An MCP server can expose three kinds of capability:
- tools: actions the model may call, such as
create_issue,search_files, orsend_message - resources: data the model can read, such as files, database rows, or API objects
- prompts: reusable prompt templates supplied by the server
Most Personal OS risk sits in tools. Read-only resources are easier to reason about. Write actions need tighter gates.
Good use cases
MCP servers are useful when you need a replaceable tool boundary:
- GitHub or GitLab access for coding agents
- filesystem access scoped to one project folder
- browser automation through Playwright MCP or similar tools
- database reads for internal dashboards
- Home Assistant control with explicit room/action limits
- local scripts exposed as small, named commands
The pattern is better when the server is narrow. “Read this repo” is sane. “Control my whole laptop and all accounts” is how you invent a haunted printer.
Receipts to keep
Keep a small inventory for every server:
| Receipt | Why it matters |
|---|---|
| Config file | Shows command, args, env vars, and allowed paths |
| Scope list | Shows which accounts/actions the server can touch |
| Token owner | Shows who can revoke access |
| Tool list | Shows what the model can actually call |
| Run logs | Shows what happened when the agent used it |
| Revoke path | Shows how to shut it down quickly |
If you cannot list those, you do not have a connector layer. You have vibes with OAuth.
Safe stacking
Stacking servers can be powerful. It also compounds risk.
Start with one read-only server. Add one write-capable server only after logs are clear. Keep risky surfaces separate: browser control, payments, email sending, account changes, and smart-home actions should not be quietly bundled into the same default toolset.
For deeper patterns, read MCP server stacking and what is MCP? .
When not to use MCP
Do not add a server just because it exists. Skip it when:
- the same job works with a simpler export/import flow
- the server needs broad account scopes for a tiny task
- logs are missing
- there is no revocation path
- you cannot explain which actions the model may take
- the server mixes trusted instructions with untrusted content
The boring setup work is the product. Without it, MCP turns tool access into account sprawl.
Personal OS checklist
Before a server joins your stack:
| Question | Good answer |
|---|---|
| What does it expose? | A short tool/resource list |
| Who owns state? | The connected service or local files are named |
| Where does it run? | Local process, container, hosted service, or client-managed runtime |
| What can it write? | Explicit actions, not vague “account access” |
| Where are receipts? | Config, logs, external IDs, screenshots when needed |
| How do you revoke it? | Token revoke, config removal, process kill, account scope change |