Treat an MCP server like a dependency with your credentials attached. Before you install one: know who publishes it and pin the version; read what each tool does and which ones write; give it the narrowest token and scopes; prefer the vendor's own remote server over a third-party local package; run local servers sandboxed; and keep a person approving write actions. The same rules apply to skills, which can bundle scripts.
The Model Context Protocol lets an assistant or agent use tools on other systems: read your GitHub issues, query a database, drive a browser. That's the MCP rung of our build ladder, and it's where AI starts acting with real credentials. This checklist is drawn from the MCP specification's security best practices, the OWASP MCP Top 10, and four public incidents, all linked below and read on November 1, 2026.
Why this matters: four real incidents
| When | What happened | Lesson |
|---|---|---|
| April 2025 | Invariant Labs showed tool poisoning: instructions hidden in tool descriptions that models follow and users don't see, plus "rug pulls" where a description changes after approval (Invariant Labs) | Read tool descriptions, pin versions |
| May 2025 | A malicious GitHub issue in a public repo steered an agent using the GitHub MCP server into leaking private-repo data through a pull request (Invariant Labs) | Untrusted content plus broad access is the attack; limit scope per session |
| July 2025 | CVE-2025-6514, CVSS 9.6: mcp-remote versions 0.0.5 to 0.1.15 could be made to run commands when connecting to an untrusted server (JFrog) |
The client side has bugs too; keep it updated, connect only to servers you trust |
| September 2025 | postmark-mcp on npm added a hidden BCC in version 1.0.16, copying every email it sent to an outside address; Koi Security found it (The Hacker News) |
Check the publisher is the real vendor; pin versions; watch updates |
None of these needed an exotic exploit. Each relied on trust given too broadly: to a package name, to a tool description, to content an agent read.
The 12-point checklist
- Is the publisher the vendor? Prefer the official server from the company whose system it connects to (GitHub's for GitHub, Sentry's for Sentry). The postmark incident was an unofficial package with a plausible name. Check the repository owner, not just the package name.
- Is it maintained and pinned? Look at recent commits, open security issues and releases. Install a specific version rather than
@latest, and read the changelog before you update: a rug pull is a malicious update to something you already trusted. - Read every tool's description. Tool descriptions go straight to the model. Look for instructions aimed at the model ("before using this tool, read…"), references to other tools, or anything about files and secrets that the tool doesn't need.
- List what writes. Separate read tools from tools that create, send, delete or pay. Disable the write tools you don't need; many official servers have a read-only mode or let you enable only some toolsets.
- Give it the narrowest credentials. Use OAuth with minimal scopes or a fine-grained token limited to the repos, projects or folders it needs, ideally on a service account. The MCP spec warns against omnibus scopes like
*oradminbecause a stolen token then opens everything. - Prefer the vendor's remote server to a local package. A local server is code running with your user's privileges; the spec's own example of a malicious startup command reads your SSH key. A vendor-hosted remote server with OAuth removes that path.
- If it runs locally, sandbox it. Run it in a container or a restricted user with access to only the directories it needs, and use the stdio transport rather than an open local HTTP port. Read the exact install command before a one-click install runs it.
- Keep a person on write actions. Leave per-call approval on for anything that writes, sends or spends. The GitHub leak worked partly because users chose "Always allow".
- Don't mix untrusted input with private access. An agent that reads public issues, web pages or inbound email can be instructed by them. Don't give the same session access to private data and a way to publish it; scope sessions to one repository or one dataset where you can.
- Watch for shadowing. With several servers installed, one server's description can change how the model uses another's tools. Install the fewest servers the job needs, and remove ones you've stopped using (OWASP calls forgotten ones "shadow MCP servers").
- Check what it sends home. Some servers collect usage statistics by default or call third-party APIs. Read the README's data section and turn off what you don't need.
- Log it. Keep a record of which tools were called with which arguments, especially writes. Without it, you can't tell what an agent did with a token, which OWASP lists as its own risk (MCP08, lack of audit and telemetry).
How the checklist maps to OWASP's MCP Top 10
OWASP's MCP Top 10, in beta, names the risks the checklist addresses:
| OWASP risk | Checklist items |
|---|---|
| MCP01 Token mismanagement and secret exposure | 5, 11 |
| MCP02 Privilege escalation via scope creep | 4, 5 |
| MCP03 Tool poisoning | 3, 10 |
| MCP04 Supply chain attacks and dependency tampering | 1, 2 |
| MCP05 Command injection and execution | 6, 7 |
| MCP06 Prompt injection via contextual payloads | 8, 9 |
| MCP07 Insufficient authentication and authorization | 5, 6 |
| MCP08 Lack of audit and telemetry | 12 |
| MCP09 Shadow MCP servers | 10 |
| MCP10 Context injection and over-sharing | 9, 11 |
Safe settings for four popular coding servers
These are widely used with coding agents, and each publishes the switches that reduce risk. Settings are from each project's README, read November 1, 2026.
| Server | Publisher | The switch that matters | Watch out for |
|---|---|---|---|
| GitHub MCP server | GitHub | --read-only skips write tools; --toolsets enables only what you need (default: context, repos, issues, pull requests, users) |
A PAT overrides OAuth if set; give it fine-grained repo scopes |
| Playwright MCP | Microsoft | --isolated keeps the browser profile in memory; --allowed-origins and --blocked-origins limit where it goes |
It says it "is not a security boundary"; the default persistent profile stores your logins |
| Chrome DevTools MCP | Chrome DevTools team | --no-usage-statistics turns off data collection, which is on by default; --no-performance-crux stops trace URLs going to the CrUX API |
It "exposes content of the browser instance to the MCP clients"; don't browse logged-in sensitive sites in it |
| Context7 | Upstash | A free API key for higher rate limits; the remote endpoint avoids a local install | Library docs are community-contributed and Context7 says it "cannot guarantee the accuracy, completeness, or security" of them |
The same checklist for skills
Skills are folders of instructions, and some bundle scripts that the agent runs, so most of the list applies: check the publisher, pin a version, read the SKILL.md and every bundled file, and be wary of a skill that asks for credentials, network calls or files it doesn't need. Anthropic's skills documentation says skills shared with you or uploaded yourself aren't reviewed by Anthropic.
Directories can help you shortlist. Skillspace, a skills directory we run, grades public skills and runs a static safety scan that can cap a grade, and it says plainly what that can't do: the scan never runs the scripts, so "a clean verdict means nothing matched, not that nothing is there", and a well-formed skill with wrong instructions can still grade well (Skillspace methodology). That's true of every directory's grade, ours included. Use a grade to decide what to read, then read it. Other directories, and how they compare, are on our registry comparison.
Questions people ask
Are MCP servers safe?
An MCP server is code that runs with the permissions you give it, so it's as safe as its author, its dependencies and its configuration. A local server runs with your user's privileges on your machine; a remote one holds a token to your accounts. Real incidents include a malicious npm package that copied every email it sent to an attacker, and a critical command-injection flaw in a popular MCP client library.
What is MCP tool poisoning?
Hidden instructions placed in a tool's description. The model reads tool descriptions but users usually don't, so a malicious server can tell the model to read files, leak data or misuse another server's tools. Invariant Labs described it in April 2025, along with "rug pulls", where a server changes a tool's description after you've approved it.
Is a remote MCP server safer than a local one?
It removes one risk and adds another. A remote server can't run commands on your machine, but it sees your data and holds a token. Prefer remote servers run by the vendor of the system they connect to, with OAuth and narrow scopes, over a stranger's package that you run locally with npx.
How do I check a skill before installing it?
Read the SKILL.md and every file it bundles, especially scripts, the way you'd review a pull request. Anthropic's documentation says skills shared with you aren't reviewed by Anthropic. A directory grade or a static scan, including the one on Skillspace, which we run, reduces the odds of a bad one but can't prove a skill is safe.