bouncerBlog · By Bouncer ·
MCP Security Scanner: Check a Server Before You Connect
You found an MCP server that does exactly what your agent needs. The setup is one command or a URL. Before you connect it, there is a more useful question than “does it work?”: what are you about to give it access to?
An MCP security scanner helps you inspect a server before making that decision. With Bouncer, you can check a remote server’s advertised tools or inspect the published npm package behind a local server. Then you can decide what to connect and which calls to allow.
No account needed for a first check. Already ready to configure tool permissions? Create a free gateway account.
First, choose the right kind of check
A local MCP server and a remote MCP endpoint expose different things to review.
| What you have | What to enter in Bouncer | What the check inspects |
|---|---|---|
| An npm-based local server | The package name or npm install command, in npm mode | Published package files and registry metadata |
| A hosted MCP server | Its MCP endpoint URL, in MCP server mode | The tool definitions the endpoint advertises |
| A private remote endpoint | Its endpoint URL and a one-time token, in MCP server mode | Advertised tools, using the token for that request |
Bouncer reads published npm files as text; it does not install or execute the package. The remote check connects to discover tool definitions. It does not inspect the server’s private implementation.
That distinction matters. Local server code runs on your machine with the permissions its process receives. Remote tool definitions describe an interface, not everything the service can do internally. The official MCP local-server security guide explains why installation choices and operating-system permissions deserve their own review.
How to check an MCP server with Bouncer
1. Check the exact thing you plan to connect
Open Security Check, select npm package or MCP server, and paste the input.
For a local package, specify an exact version when you know which version you intend to use. For a remote server, use the actual MCP endpoint rather than its marketing homepage. For private endpoints, use the token field instead of placing credentials in the URL.
2. Read the findings behind the verdict
Bouncer uses three verdicts:
- On the list: nothing notable turned up in the automated check.
- Worth a look: there are findings to review before connecting.
- Turned away: the check found something rated high or critical.
Treat the verdict as a starting point. For npm packages, review install scripts, credential access, outbound destinations, release metadata and known advisories. For remote MCP servers, review unexpected tools, hidden characters, and descriptions that try to direct the agent beyond the tool’s job.
A finding needs context. An install script can be legitimate. A familiar package name can still be the wrong package. A clean report does not prove that a package or server is safe.
3. Compare the tools with the task
Imagine an agent whose only job is to summarize project notes. The following names are fictional:
| Advertised tool | Does the task need it? | Review decision |
|---|---|---|
| read_note | Yes, for the selected project | Consider allowing with a narrowly scoped credential |
| delete_note | No | Keep it outside the allowed tool set |
| export_all_notes | No | Exclude it and review why it is exposed |
Do not approve everything just because the connection works. Write down which operations the task needs and which data it may access.
Tool annotations such as readOnlyHint can help describe expected behavior, but they do not enforce permissions. The official MCP annotations explainer makes that limit explicit. An allowed tool still needs appropriate arguments, upstream authorization and careful handling of returned content.
Your MCP security checklist
Before connecting the server, record these decisions:
- Identity: confirm the publisher, package name and endpoint.
- Version: choose an exact local package version where possible.
- Findings: review anything unexpected rather than relying on the verdict alone.
- Permissions: give the server only the files, data and credentials its task needs.
- Tool access: allow the required operations and exclude unrelated ones.
- Limits: set request limits appropriate to the task.
- Review: keep a record of what you approved and revisit material changes.
Pinning a local package version makes that selection explicit. It does not freeze every dependency or external service. A remote URL is also an address, not an immutable release.
For the broader risk picture, read Bouncer’s MCP security guide. For ongoing review, see what happens when MCP tools change.
Turn your review into tool permissions
The check helps you decide whether to connect. A gateway gives you a place to configure which requests may pass after connection.
With Bouncer, you can register an existing MCP endpoint or import an OpenAPI specification, issue a scoped gateway key, and configure tool allow/deny policies. Per-key rate limits, daily quotas, configured spend caps and a call log help you bound and inspect usage.
For the fictional notes assistant, start with a default-deny policy and permit only the required read tool. Give the upstream credential access only to the intended project. Then connect the agent through the gateway and inspect its calls.
Those policies apply to requests routed through Bouncer. Remove direct connections or credentials that would let the agent bypass that path. A tool-name rule cannot determine whether every argument or response is appropriate, and a gateway does not sandbox a local npm process.
Start with one endpoint, one scoped key and the tools your task needs. The gateway is currently free; see pricing for optional per-call payments and network fees.
Common questions
Does an MCP security scanner guarantee a server is safe?
No. Bouncer’s automated findings support a review of the inspected package files or advertised tool definitions. They are not a security certification or proof of future behavior.
Can I check a private MCP server?
Yes. Bouncer’s MCP check accepts a one-time token. According to the product’s current check page, it is used for that request rather than saved to the database, and the resulting report stays private.
Do I need an account?
A first security check does not require an account. Re-scans require sign-in. Gateway setup, keys and policies require an account.
What should I do after a clean check?
Confirm that the permissions fit your task. For supported gateway connections, configure the allowed tools and request limits before routing the agent through Bouncer. Review tool changes separately.
Check the server. Set its boundaries.
Bring the package or endpoint you are considering. Read its findings, decide which tools the task needs, and configure access before giving your agent the connection.