Scanning MCP Tools for Security Issues Before Your Team Deploys Them

Quick answer: An MCP tool is a piece of code that can read and act on real data, so it deserves the same security review as any service you deploy. Run a repeatable scan before it reaches the team: confirm the provenance and version, check what permissions and network access it actually uses, and verify secrets are injected by the gateway rather than bundled in. A green scan is not a one-time event; wire it into the pipeline so a later update cannot quietly widen the tool's access.

The urgency became real when a teammate pulled a community MCP server from a registry to speed up a workflow. It worked immediately, which was the problem. On inspection it shipped a hardcoded credential and made outbound calls to a host unrelated to the documented feature. Nothing in the registry listing flagged either. If that tool had been deployed into the shared gateway, the credential would have been exposed and the unexpected network path would have been invisible. A lightweight pre-deploy scan caught both before anyone trusted it with production data.

What an MCP tool can actually do

It helps to stop thinking of these as harmless integrations. Once mounted, a tool can reach internal APIs, read whatever the attached credential can read, and trigger actions the agent requests. The risk surface has a few distinct parts:

Provenance and version. Who published it, whether the source is auditable, and exactly which pinned version is deployed.
Permissions. The scopes and role of the credential the tool runs with.
Network access. Which hosts it connects to, including any undocumented calls.
Secret handling. Whether tokens are injected at runtime or embedded in the package or config.
Input handling. Whether the tool validates parameters and avoids passing them straight into commands or queries.

Registry trust versus a local scan

A registry makes discovery easy, but a listing is not an attestation. The table below shows why a hosted catalog cannot replace your own gate.

Check	Trusting the registry listing	Local pre-deploy scan
Provenance	Name and author only	Source and pinned version recorded
Secrets	Not guaranteed	Scans for embedded credentials
Network calls	Often undocumented	Enumerates actual hosts contacted
Permissions	Broad defaults possible	Least-policy scope enforced
Updates	Can change without review	Re-scan triggers on every version

A practical scan sequence

The scan should be scriptable and run before the tool is promoted, starting with provenance and moving outward to runtime behavior.

# 1. Pin the exact version and record the source
mcp install document-tools@1.4.2 --lock

# 2. Scan the package for embedded secrets
rg -n "api[_-]?key|secret|token|password" vendor/mcp

# 3. Enumerate network endpoints referenced in code
rg -n "https?://" vendor/mcp

# 4. Confirm the gateway supplies the credential, not the package
# config contains only a reference, never the raw value

For tools you generate from an OpenAPI spec, much of this is simpler because the provenance is your own contract, the surface is the operations you deliberately exposed, and the upstream token stays in the gateway. That is a structural advantage over pulling an opaque server from a catalog.

Enforce least privilege and injection

Give the tool a credential scoped to the actions it needs, not a team-wide key, and inject it through the gateway so no secret appears in the package or in agent-facing configuration. Validate the input schema strictly so parameters cannot be passed unsanitized into a shell command or a query. Where a tool genuinely needs broad access, make that explicit and reviewed rather than discovering it through an incident.

Exercise the tool in a sandbox before promotion

Static checks find embedded secrets and declared hosts, but they do not reveal what the tool does when it runs. Mount it first in an isolated environment with a throwaway credential and a restricted network policy, then drive representative requests through an agent and log every call. That runtime view surfaces hidden behavior that code reading misses, such as a tool that fetches configuration from an unexpected host or makes more requests than the documented operation suggests. Only after the sandbox behavior matches the documented surface should the tool be promoted to the shared gateway.

Re-scan on change, not just on first use

The most common gap is scanning a tool once and then trusting every future update. A version bump can add an operation, change a host, or request a new scope. Treat the version as the gate: the pipeline runs the same provenance, secret, and network checks on every update, and a change in permissions blocks promotion until reviewed. That keeps the security posture attached to the actual running code rather than to a decision made months earlier.

FAQ

Can't I trust tools from a well-known registry?

A registry is a directory, not a guarantee. Community tools can still embed secrets or make undocumented calls. Verify provenance, permissions, network access, and secret handling yourself before promoting a tool to the shared gateway.

What is the most important check?

Confirm secrets are injected by the gateway and never bundled in the package, and that the credential is scoped to the tool's actual needs. Embedded credentials and over-broad keys are the fastest ways a mounted tool becomes a serious exposure.

Does a generated MCP server need the same review?

It still needs review, but it is easier to trust because the provenance is your own spec, the exposed operations are deliberate, and the token stays in the gateway. Run the same checks so a later spec change cannot silently widen access.

Why re-scan after the tool is already approved?

Because an update can add hosts, operations, or permissions. Pin the version and run the scan on every change; otherwise the security decision stops matching the code that actually runs.

This is part of the Powerduck vs Smithery hub — start there for the full comparison of generating and hosting MCP servers.