MCP Server

What's the concrete difference between local and remote MCP Server deployment in terms of data security? How should I decide which to use?

The core difference is whether data leaves the scope you can directly control during transmission and processing — this directly affects the risk level of data leakage or third-party access.

Local deployment: the MCP Server runs on the user's own computer or self-managed server; when the Agent calls this server, all data processing happens inside your own machine, without being sent to any external third-party server. This is especially important for handling sensitive data (personal files, internal company documents, private financial information) — you fully control the data's flow, without needing to trust any external provider's data-protection measures. The downside: local deployment requires the user to be capable of installing, configuring, and maintaining this server, a higher barrier for non-technical users, and if the MCP Server itself needs to call an external API (e.g., querying a real-time stock price), the data still leaves the local machine to an external service — the MCP Server's own operating environment being local doesn't mean it never communicates with the outside world internally.

Remote deployment: the MCP Server is hosted by a third-party provider, connected over the network by the user, without needing self-installation and maintenance. Advantages: lower barrier to use, and the server side usually keeps updating and maintaining it; disadvantages: your requests and related data must be sent to this third party's server for processing, meaning you partially hand over data control to them, requiring trust in their data-handling and storage policies.

Judgment principle: if the data you'll process is highly sensitive (personal privacy, company secrets, financial credentials), prioritize local deployment — even with a higher setup barrier, it's worth the cost to avoid sensitive data passing through an unfamiliar third-party server; if the data itself isn't sensitive (querying public weather info, public market data), remote deployment's convenience usually outweighs the risk and can be prioritized. The core judgment isn't an absolute rule that 'local is always safer, remote is always riskier' — it's concretely assessing 'how much actual risk the data being processed this time incurs once it leaves my direct control.'

If an Agent connects to multiple MCP Servers simultaneously, and one of them has a security vulnerability or malicious design, can this risk spread to affect other MCP Servers or the entire Agent system?

Yes, and this risk-spreading mechanism directly relates to the 'input isolation' principle discussed in the earlier Prompt Injection entry — if the Agent trusts all connected MCP Servers uniformly, with no isolation design at all, a compromised MCP Server can indeed affect the entire system.

The concrete spreading mechanism: a malicious or vulnerable MCP Server can embed malicious content (like the text discussed in the earlier Prompt Injection entry, attempting to manipulate the Agent's reasoning process) within the tool execution results it returns to the Agent. If the Agent trusts content returned by all MCP Servers equally, feeding it directly into subsequent reasoning without distinction, a compromised or maliciously designed MCP Server can theoretically become a new Prompt Injection attack entry point — meaning connecting to an MCP Server itself expands the Agent's attack surface; the more MCP Servers connected, and the less trusted their sources, the more potential risk entry points exist.

Concrete defense design approaches: trust tiering. Not all connected MCP Servers should get the same trust level — servers with clear, verified provenance (officially maintained, or developed by your own team) can be given higher trust; content returned by MCP Servers of unknown or third-party origin should be flagged as 'external data requiring extra verification,' applying the earlier-discussed input isolation principle, unable to directly trigger high-permission actions. Permission scope restriction: each MCP Server connection should only be granted the minimum permission needed for the specific task (echoing the earlier least-privilege entry), rather than granting an MCP Server full access to the entire Agent system upon connection — even if one MCP Server has an issue, the affected scope should be bounded to the narrow scope it was authorized for. Source vetting: before connecting to any MCP Server, do a basic vetting of that server's source (who maintains it, is there a public security audit record, what's the community reputation), rather than connecting immediately to any MCP Server claiming to provide useful tools — echoing the earlier framework-selection article's principle that 'not every tool that looks convenient should be adopted directly, its credibility needs assessing,' just applied to this specific MCP Server scenario.

As a beginner in Agent development, when should I consider writing my own MCP Server instead of directly connecting to an existing one?

The judgment standard should come back to 'does the existing MCP Server ecosystem already cover the tool capability you need,' not defaulting to assuming 'writing my own is better' or 'using an existing one is better.'

When to prioritize directly connecting to an existing MCP Server: if the tool capability you need is a relatively common, general need (reading a file system, querying public webpage content, operating common cloud services like Google Drive), the ecosystem usually already has a well-maintained existing MCP Server directly usable — writing a new one yourself in this case not only wastes time, but your own implementation quality may fall short of a mature existing solution, actually introducing extra risk or bugs. For a beginner, directly using an existing, verified MCP Server lets you focus your energy faster on the core problem of 'the Agent's own reasoning and decision logic,' rather than burning time reinventing an already-solved tool-integration problem.

When you should consider writing your own MCP Server: if you need access to highly customized data or systems specific to your own scenario (your company's internal proprietary database, an internal tool with no existing integration solution at all), in this case, the ecosystem is unlikely to already have an existing MCP Server covering this need, and writing your own becomes a necessary option.

A recommended starting point for a beginner writing their first MCP Server: don't try to cover everything from the start, providing every function that might possibly be useful — start with 'the minimum-scope tool capability your current Agent project genuinely needs,' write a simple, working MCP Server covering the core need, then gradually expand based on needs discovered through actual use — this incremental approach echoes the 'get something running first, then go deeper gradually' learning principle from the earlier framework-selection article, just applied to the more advanced implementation scenario of 'writing your own MCP Server.'

In practice, most Agent developers' first project usually combines 'connecting to one or two existing MCP Servers (handling general needs)' plus 'writing a small, custom MCP Server (handling proprietary needs)' — not a strict either-or choice.

In a multi-agent system, if multiple Sub-agents need tools provided by the same MCP Server, should each Sub-agent establish an independent connection, or share the same connection?

This question involves a tradeoff between efficiency and isolation, and the answer depends on whether these Sub-agents' trust relationships and permission needs are the same — it's not simply 'sharing a connection is more efficient, so choose sharing.'

When sharing a connection fits: if multiple Sub-agents are highly complementary to each other, belonging to different stages of the same task flow (echoing the scenario discussed in the earlier Handoff entry), and their needed permission scope is essentially identical (e.g., all only need read-only access to the same data), sharing the same MCP Server connection reduces the system overhead of repeatedly establishing connections and simplifies resource management — no need to maintain separate connection state for each Sub-agent.

When sharing a connection doesn't fit and independent connections should be established: if different Sub-agents need different permission scopes from this MCP Server (one Sub-agent only needs read-only query, another needs write or modify permission), sharing the same connection causes the problem of 'permission scope being forced into a union of the two needs' — if, to let both Sub-agents use the same connection, the connection's permission is set to the union of both needs (covering both read and write), the Sub-agent that originally only needed read-only permission unexpectedly gains write permission too, directly violating the repeatedly emphasized least-privilege principle. In this case, even with some extra connection-management overhead, independent connections precisely scoped should be established for Sub-agents with different permission needs.

Another scenario calling for independent connections: if different Sub-agents have different trust levels (one is a core, fully tested Sub-agent, another is still in an experimental stage with higher behavioral uncertainty), even if they theoretically need the same permission scope, independent connections are still recommended — this way, if the experimental Sub-agent's behavior shows anomalies (calling a tool abnormally frequently, triggering the anomaly-detection mechanism discussed earlier), that one connection can be individually restricted or paused, without affecting the core Sub-agent's normal operation.

A simple judgment principle: first ask 'do these Sub-agents need exactly the same permission scope' — if not, use independent connections; then ask 'are these Sub-agents' trust levels and stability the same' — if not, also use independent connections; only when the answer to both questions is 'the same' does the efficiency gain from sharing a connection not come at the cost of isolation's security value.