Before install: resolve source and package identity
Match the server name to the publisher, repository, package identifier, release artifact, and documented command. Look for ownership changes, typo-squatting, unreviewed install scripts, dependency drift, and a mismatch between the registry entry and the code that actually executes. Pin versions when your change process requires reproducibility, then plan how updates will be reviewed.
Open source improves inspectability; it does not prove that the reviewed commit matches the installed package or that the code is vulnerability-free.
Credentials: validate audience and minimize scope
For remote authorization, the access token must be intended for the MCP resource. Current MCP security guidance explicitly rejects token passthrough: a server must not accept a token issued for another service and simply forward it. Use narrow scopes, short lifetimes, secure storage, revocation, and explicit consent for sensitive capabilities.
For local stdio servers, environment-based credentials may be practical, but the child process inherits them and may log or exfiltrate them. Supply only the credential that server needs, not a broad shell environment or an account-wide administrator token.
Runtime: local and remote fail differently
A local MCP server is executable code running with the client's operating-system privileges. Prefer stdio for a private child-process channel, restrict filesystem and network access, and use a sandbox or container where the risk warrants it. A remote server moves execution to an operator, but sends requests and possibly credentials across a network boundary; require HTTPS, inspect authentication, and understand retention and subprocessors.
Tools and prompts are an integrity surface
Tool descriptions and schemas influence model selection and arguments. Record the approved inventory, review additions or permission changes, and require human confirmation for destructive, external-message, financial, administrative, or irreversible actions. Treat content returned by tools and resources as untrusted data that can contain prompt injection.
Cross-server workflows amplify risk: one server can retrieve untrusted instructions and another can execute an action. Keep data sources and action tools in separate permission domains and show the user the actual action and arguments before commitment.
Monitor, revoke, and recover
Log server identity, tool name, approved arguments or a privacy-preserving digest, result status, latency, and correlation ID. Never log access tokens. Alert on new tools, changed schemas, unusual destinations, repeated authorization failures, and spikes in destructive operations. Maintain a fast path to disable the server, revoke its credential, preserve evidence, and restore affected data.
Printable pre-production checklist
Use MCP Radar fields to prioritize review, not to skip it. Registry presence, repository auditability, runnable entry, maintenance activity, adoption, and sandbox install evidence answer narrow questions. None of them certifies the server, its operator, dependencies, downstream API, deployment, or suitability for your data.
- Identity matched across registry, repository, package/endpoint, and release.
- Permissions and credential scopes enumerated; token audience validated.
- Local filesystem/network/process access or remote data flow documented.
- Tool/resource/prompt inventory reviewed and consequential actions gated.
- Logs redact secrets; schema/ownership changes trigger review.
- Disable, revoke, incident, backup, and recovery paths exercised.