MCP: trust, scope, and minimal permissions
Model Context Protocol (MCP) connects your IDE to tool servers that can read files, call HTTP APIs, or query databases. That power is convenient—and dangerous if a server is malicious, misconfigured, or over-scoped. Treat MCP like installing a new background service: verify source, pin versions, and deny by default.
Widget tour: pipeline traces a single tool call; the table compares trust dimensions; the graph maps capabilities around the hub; text-blocks capture policy bullets.
Path of one MCP tool invocation
Each hop is a place to log, throttle, or block—defense in depth applies here too.
🧩
Client
IDE / Claude
→
🔌
Transport
stdio / SSE
→
🖥️
MCP server
your process
→
🗂️
Tool
read_file / http
→
🌍
Side effect
disk / network
What to evaluate before you enable a server
If any column is unknown, pause installation until you can answer it.
| Question | Why it matters |
|---|---|
| Who publishes the package? | Supply-chain risk—prefer signed releases and known maintainers. |
| Which directories or hosts can it touch? | Filesystem and outbound URL scope should be minimal. |
| How are secrets injected? | Env vars vs prompts—avoid passing prod tokens through the model. |
Capability map (conceptual)
Click through—if any spoke should not exist for this project, disable that tool in config.
MCP server
📁Filesystem
🌐HTTP APIs
🗄️DB / SQL
💻Shell
Policy snippets you can adopt
Team norms
Maintain an allowlist of MCP servers per repository; require code review for new entries the same way you would for new CI secrets.
Separate configs for personal experiments vs work machines—do not reuse prod-capable servers on untrusted networks.
When a tool returns large blobs, remember they burn context—another reason to prefer narrow tools.
⚠️MCP does not replace security reviews of third-party code—if a server can execute arbitrary commands, treat it as high risk.