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.
QuestionWhy 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.