Most MCP incidents worth imagining reduce to one shape: a server (or set of servers) that lets the model read content an attacker can influence and act with authority — send, delete, pay, push. Separately each half is manageable; together they hand your permissions to whoever writes the most persuasive document your model reads. Design deployments so that combination requires a human in between, and most of the scare stories stop applying to you.
Why this page is the site
Explainers of MCP are abundant; disciplined adoption guidance is not — and the gap is where teams get hurt. This site\'s bet matches our network\'s pattern everywhere: the durable value is the checklist that stays true as the spec evolves, with modelcontextprotocol.io owning the moving details.
Evaluation questions
What is the prompt-injection risk with MCP servers?
A model reading attacker-influenced content (a webpage, an email, a document) can be steered into calling tools in the attacker's interest — and MCP servers are the tools. The mitigations are architectural, not vibes: least-privilege scopes per server, human confirmation on destructive or exfiltrating actions, separating read-tools from write-tools, and treating any server that both reads untrusted content and holds write power as the highest-risk combination you can deploy.
What should I check before adopting a community server?
Six checks: provenance (who maintains it, is the vendor involved); code volume you can actually review versus what it claims to need; requested permissions and credentials against least privilege; transport and auth story if remote; maintenance signals (recent commits, issue responsiveness, pinned dependencies); and behavior review of what the tool descriptions tell the model — because those descriptions are prompt-adjacent surface too.
How should teams roll MCP out safely?
Like any capability with blast radius: an allowlist of approved servers rather than developer free-for-all; scoped credentials per server, never shared master keys; logging of tool calls so incidents are reconstructable; and a review gate for adding write-capable servers. Teams that already run dependency review can extend that process — the novel part is only that the "caller" is a model that believes what it reads.