03.05 · Concept
Reading somebody else's MCP server
Audit a third-party server before you let it into your loop.
A third-party MCP server should be reviewed as a dependency with access to model context, credentials, files, networks and automation. The important work is mapping its tools, resources and prompts to real permissions, side effects and data flows before deciding whether to sandbox, restrict, fork or reject it.
What this lesson answers
- how to audit a third party MCP server
- what can an MCP server expose to agents
- is MCP safe because it is a protocol
Notes
An MCP server is software that gives a model-controlled client access to external capabilities: tools it can call, resources it can read, and prompts or templates it can request. Reading somebody else’s server means treating it like any dependency that will sit near sensitive context, credentials, files, networks, and automation. Your first question is not “does it work?” but “what can it cause the agent to see, send, modify, or execute?”
The concrete mental model is a small API surface offered to an agent loop. Start by finding the manifest or server definition, then enumerate every tool,…
Common questions
- What should I inspect first in an unfamiliar MCP server?
- Start with the server definition or manifest, then list every exposed tool, resource and prompt. For each capability, read the implementation rather than trusting the name. You want to know what inputs it accepts, what it returns, what it can read or change, and whether it reaches the network, filesystem, environment or subprocesses.
- Does MCP make a server safe to use with an agent?
- No. MCP standardises the conversation between client and server, but it does not guarantee that the server is trustworthy, least-privileged or resistant to prompt injection. Risk comes from the powers the server exposes, such as broad file access, arbitrary URL fetching, shell execution or careless handling of untrusted content.
- How do I decide whether to allow an MCP server?
- Translate each exposed capability into concrete permissions and likely failure modes. Check what secrets and data it can touch, what it can send elsewhere, and what it can modify or execute. If the access is broader than the use case requires, prefer sandboxing, configuration limits, a fork with reduced permissions, or rejection.