MCP in a Minute: Local vs remote servers

In one sentence

Local MCP servers execute as processes you control; remote MCP servers provide tools through a network endpoint you must trust.

Why it matters

Coding agents inherit the reach of every connected server. Local vs remote changes latency, secret handling, update control, and attack surface.

How it works

Local

• good for filesystem tools, personal CLIs, and private experiments;
• runs with your user permissions unless further sandboxed;
• easier to inspect, easier to accidentally over-privilege.

Remote

• good for shared team systems and centrally managed integrations;
• requires transport security and auth you understand;
• expands blast radius beyond one laptop when credentials are powerful.

Pick based on data classification and who can change the server’s tool surface.

Example

Use a local docs-search server over your checked-out handbook. Use a remote, least-privilege issue tracker server for team tickets—not a personal token with org-admin rights.

Agentic coding use

Many agent setups mix both. Inventory them. A forgotten remote server with write tools is a silent production dependency.

Watch out

“Local” is not synonymous with “safe.” A local server that shells out can still destroy your machine state. Apply the same tool allowlists either way.