MCP best practices
MCP server best practices: a deployment and operations checklist
Design bounded tools, separate identity from upstream access, test failure paths and prepare a repeatable MCP release with an actionable acceptance checklist.
Design a tool around a decision, not an entire API
Consider a project-status assistant. A useful first tool is get_project_status with a project identifier and a bounded date range. Returning every project, message and attachment forces the agent to sift through irrelevant data and exposes more information than the task needs. Specify required fields, allowed values, maximum page size and pagination behavior. Return stable record identifiers, source links and timestamps when available. Explain whether an empty result means no matching records or insufficient access; do not quietly return an empty list when the upstream API failed. Tool descriptions should explain when to use the operation, not instruct the model to ignore its other rules.
Treat identity and authority as separate questions
Ask who is calling the MCP and whose upstream account executes the request. Those identities may differ. Giving two customers different gateway keys does not isolate their data if both keys reach an unrestricted shared upstream account. Enforce tenant and object authorization on the server, using trusted identity context rather than a caller-supplied tenant identifier. Separate source-repository credentials from runtime credentials. The official MCP security guidance warns against token passthrough and describes SSRF risks during discovery. Validate the destination and intended audience rather than treating possession of any bearer token as sufficient authority.
Make failure behavior part of the contract
Set explicit limits for request size, result size, execution time and concurrent work. For a read operation, a bounded retry may be appropriate after a transient failure. For a write, first establish whether retrying could duplicate a task, payment or message. Where the upstream service supports idempotency, persist and reuse the operation identifier. Otherwise return an uncertain outcome and provide a reconciliation step instead of blindly repeating the write. Test a slow upstream, an invalid identifier, a revoked credential, quota exhaustion and cancellation. These are recommended acceptance cases, not guarantees that every MCP host implements them.
Release a known version and keep recovery possible
Pin the source commit and dependency lockfile. Save the build command, entrypoint, configuration names and approved tool inventory alongside the release. Before updating, compare names, schemas, permissions and side effects. A renamed field can break a client even if the process remains healthy. Retain the previous image and understand whether a database or upstream change prevents rollback. Use a read-only smoke test after rollout, then check that a real client can discover and execute the intended tool. Process liveness alone does not establish workflow health.
Collect evidence without collecting secrets
Record a request identifier, tool name, duration, outcome, release and a privacy-conscious consumer reference. Keep credentials and sensitive arguments out of ordinary logs. Separate transport success from a tool-level failure: an HTTP response can arrive successfully while the requested business action fails. In MCP Ops guided early access, review supported Node.js stdio imports, bearer-key access and per-MCP history before choosing it for a workflow. Do not infer OAuth, enterprise isolation or every operational recommendation in this article from the presence of a hosting dashboard.
git rev-parse HEAD
git status --shortRead-only commands. Run inside your repository.
Before you proceed
Mark the items you have reviewed. This is a local reading aid, not a security assessment; it resets when you leave.
Use this checklist during your own review. It is not a certification or an automated test result.