MCP makes AI assistants more useful by connecting them to tools and data. That same power creates security questions: what can the assistant read, what can it change, where are secrets stored, and how does a user approve risky actions?
This guide gives practical MCP security best practices for builders and teams. It is not a formal audit or legal opinion. Use it as an implementation checklist before publishing, installing, or recommending an MCP server.
Key takeaways
- Design MCP tools around least privilege and narrow tasks.
- Separate read-only capabilities from write or destructive actions.
- Protect secrets, log safely, document permissions, and test misuse cases before launch.
Start with least privilege
Least privilege means the server only gets the access needed for its task. A docs search server does not need write access. A formatting tool does not need network access. A GitHub issue reader does not need permission to merge pull requests.
For independent builders, least privilege is also a product advantage. Users are more likely to install a server when the README clearly explains what it can and cannot access.
- Use read-only tokens when possible.
- Limit filesystem paths instead of exposing an entire machine.
- Scope database access to selected schemas or views.
- Expose narrow tools rather than one generic execution tool.
Separate read actions from write actions
Read actions help the assistant understand context. Write actions change the world. Treat them differently. A server that can send email, write files, delete records, deploy code, or submit forms should make those actions explicit and reviewable.
Do not hide destructive behavior behind harmless tool names. A tool called sync_data that can delete production records is harder for users to evaluate than archive_records or delete_stale_records.
- Name write tools honestly.
- Require confirmation for destructive actions when the client supports it.
- Return a preview or dry-run result before mutation.
- Keep audit logs for high-impact actions.
Protect secrets and credentials
MCP servers often need credentials to call APIs. Those credentials should stay in server-side environment variables or local config, not in prompts. The assistant should never need to see raw secrets to complete a normal task.
If the server returns errors, avoid printing complete tokens, cookies, private URLs, or database connection strings. Redacted errors are less convenient during debugging, but they prevent accidental leakage into chat transcripts.
- Redact tokens in logs and error messages.
- Use short-lived or scoped credentials when available.
- Do not expose env dumps as a tool response.
- Rotate credentials after demos or shared screenshots.
Validate inputs and outputs
Every tool should validate inputs before touching the target system. If a tool accepts a path, restrict allowed directories. If it accepts SQL, prefer parameterized queries or predefined operations. If it accepts URLs, block internal metadata endpoints and private network ranges when not needed.
Output validation matters too. A server can accidentally return private data that the user did not ask for. Keep responses minimal, structured, and focused on the task.
- Validate path, URL, SQL, and command inputs.
- Return only the fields needed by the assistant.
- Use allowlists for dangerous operations.
- Reject ambiguous requests instead of guessing.
Document the security model
A secure MCP server should explain its trust model in plain language. Users need to know what the server reads, what it writes, where data goes, whether requests are logged, and which credentials are required.
For BestMCPServers directory pages, security metadata can become a ranking and filtering feature. Servers with clear permissions, active maintenance, and scoped tools should be easier to recommend than servers with broad unreviewed access.
- List required permissions.
- Explain data storage and retention.
- Show example approval prompts where possible.
- Publish a changelog for permission changes.
- Include a contact path for vulnerability reports.
Implementation review before you use this guide
Treat this MCP Security Best Practices guide as a practical starting point, not as a replacement for the current server README, client documentation, or your own production review. MCP clients, SDKs, hosted transports, package names, and security defaults can change quickly. Before you recommend a server or copy a configuration into a real workflow, verify the exact package version, supported client, command path, required credentials, and exposed tool list.
For BestMCPServers, the durable evaluation standard is simple: the page should help a builder complete a real task safely. That means clear setup steps, honest limitations, useful troubleshooting notes, internal links to related MCP guides, and no unsupported claim that a feature is official or already hosted. If the topic touches credentials, private data, deployment, or write actions, start with read-only behavior, document the trust boundary, and add stronger review before production use. When a page is used for SEO validation, keep the content useful for the same developer who arrived from search: answer the immediate setup question, show the safer alternative, explain the failure modes, and point to the next guide only after the core task is clear.
- Verify the current upstream docs and package version.
- Test one narrow prompt before expanding the workflow.
- Keep secrets out of prompts, screenshots, logs, and public examples.
- Document what the server can read, write, call, and return.
FAQ
Are MCP servers safe?
They can be safe when designed with least privilege, clear permissions, safe credential handling, validation, and user approval for risky actions. A poorly scoped server can create real risk.
What is the biggest MCP security risk?
The biggest practical risk is giving an assistant broad read or write access without understanding what tools the server exposes and what credentials it uses.
Should MCP servers have write access?
Only when the workflow needs it. Start read-only, add write tools separately, name them clearly, and prefer preview or confirmation steps for destructive actions.
How should MCP servers handle secrets?
Store secrets in environment variables or secure config, never in prompts. Redact tokens in logs and tool responses, and use scoped credentials where possible.
Do I need a security checklist before publishing an MCP server?
Yes. At minimum, review permissions, credentials, input validation, logging, user approvals, dependency maintenance, and documentation before launch.