MCP server security checklist: how to evaluate tools before connecting them
Evaluate MCP servers for provenance, permissions, credential handling, tool integrity, prompt-injection controls, logging and revocation.
By Scrollport

In brief
An MCP server listing is a discovery signal, not proof that the server is safe. Before connecting one, verify its source and change control, review every requested permission, keep tokens out of model context, test tool inputs and outputs, isolate risky actions, require approval for material changes, and confirm that access can be logged and revoked. Publication checks and a full security assessment are different levels of assurance.
An MCP server listing is a discovery signal, not proof that the server is safe. Before connecting one, verify its publisher and release path, minimise permissions, keep tokens out of model context, test every tool boundary, isolate risky execution, require approval for material actions, and confirm that access can be logged and revoked. Publication verification and a full security assessment provide different levels of assurance.
A listing is not verification
A directory or registry can help you find an MCP server. It cannot by itself prove that the package, remote endpoint or future update is trustworthy. The official MCP Registry terms of servicestate that entries are not endorsed or guaranteed. Treat registry metadata as the start of due diligence, not its conclusion.
Record the exact server, publisher, package or endpoint, version and review date. For a remote service, identify the legal operator and data path. For a local package, identify who can publish updates and whether the installed artefact matches the reviewed source.
Verify source and change control
- Follow registry or directory links to the canonical source and publisher identity.
- Pin a reviewed version or digest where the installation model allows it.
- Review install scripts, runtime dependencies, network destinations and update behaviour.
- Define what change requires re-review, including new tools, schemas, permissions or endpoints.
- Keep an owner, review date and revocation path with the approval record.
The OWASP MCP Security Cheat Sheetcovers server authenticity, tool poisoning and supply-chain controls in more depth.
Check permissions and credentials
Grant the narrowest scopes that support the intended workflow. Keep provider keys and OAuth tokens in the host or a dedicated secret store, never in the prompt, tool description or returned content. Use separate credentials across environments and users where practical, and verify that disconnecting the server or app actually revokes the relevant authority.
For remote HTTP servers, compare the implementation with the MCP authorization specification. Validate resource indicators, redirect URIs and token audience. Do not pass through tokens issued for a different upstream service.
Test tool inputs and outputs
- Review tool names, descriptions and schemas for hidden or overly broad instructions.
- Reject unexpected fields, oversized inputs, unsafe paths and untrusted command fragments.
- Treat retrieved pages, files and tool results as untrusted content that may contain prompt injection.
- Require human approval before destructive, externally visible or materially expensive actions.
- Test errors and partial failures, not only the happy-path example.
Re-check the visible contract after an update. A server that keeps the same name can still change a tool description, request wider authority or return new data classes.
Require isolation, logging and revocation
Run local servers with the smallest useful filesystem, process and network access. Separate high-risk servers from routine tools. Log the connection, selected tool, human or agent principal, decision, result state and material spend without logging secrets or sensitive payloads unnecessarily.
Before approving production use, prove that you can pause or revoke access, rotate a credential, identify affected runs and remove a compromised version from discovery. Add spending boundaries where a tool can trigger paid work. The AI agent spending controls guideexplains price inspection, prepaid exposure and approval thresholds.
Separate publication verification from a security assessment
Publication verification can confirm that a declared tool contract, worked example, price and health state have evidence. It is not automatically a penetration test, source-code or dependency audit, threat model, privacy review, compliance assessment or restricted-scope security assessment. State exactly which assurance was performed and which risks remain.
Scrollport’s publication verification processchecks catalog evidence and ongoing health. Use this broader checklist before connecting an independently operated MCP server, then obtain a specialist assessment when the data, permissions or consequences justify one.