How to Check an MCP Server Before You Connect It

Published 2026-10-19 · Updated 2026-10-19 · By The Is My Agent Safe team

Connecting a local MCP server is not like flipping a feature flag. The Model Context Protocol's local server security guide is blunt: you download code from the internet and run it as a child process of your user account. That process can inherit your environment variables, read anything your account can read, and open outbound network connections. None of that is governed by the protocol. It is governed by how you run the process.

Nobody can prove in advance that a third-party server will only do what it claims. Provenance checks lower the odds of a bad trust decision. Isolation decides what a bad one costs.

What connecting an MCP server actually gives it

Most local servers use the stdio transport: your client spawns the server as a subprocess and talks over stdin and stdout. MCP's guide says the client and a stdio server share one trust domain. The transport is not a sandbox. Your real decisions happen before launch: what you install, and how you isolate it.

Every server you add also shares the model's context with the others. A malicious or poisoned server can influence how the agent uses tools from every other server.

OWASP's MCP Security Cheat Sheet groups the same themes under least privilege, tool-description integrity, sandboxing, supply-chain checks, and consent at install time.

Prefer remote when it does not need your machine

Before you install anything as a local process, ask what it needs from *your* laptop. Reading a working tree, driving a local tool, or reaching hardware are reasons to run locally. Wrapping a remote API is not.

MCP's advice: prefer the remote (Streamable HTTP) version where one exists. A remote server runs no code on your machine and uses the protocol's authorization flow instead of a token in a local config file. Treat an unnecessary local-only install as a signal worth questioning.

Provenance: publisher, exact package name, pin the version

MCP's "Check Provenance Before You Install" section is the pre-connect baseline:

1. Identify the publisher. Can you tie the package to a source repository and a real maintainer or organization? Is there recent, plausible activity?
2. Verify the exact package name. Typosquatting is cheap. Confirm you are installing the package the documentation names, not a lookalike.
3. Pin the version. Install a specific version rather than latest, so a compromised future release does not land through auto-update. Pair the pin with a deliberate update habit when advisories appear.
4. Know what the pin covers. Pinning with npx or uvx fixes only the top-level package; transitive dependencies are typically resolved fresh. Pinning a container image by digest (image@sha256:...) freezes the whole dependency tree.
5. Prefer provenance metadata when you can get it: signed artifacts, attestations, SBOMs.

A registry listing is not an endorsement. Curated catalogs describe their own checks as best-effort.

Read the tool list (and treat descriptions as untrusted)

Installing is not the last trust decision. At runtime the server sends tool names and descriptions, and the model reads them as instructions. MCP calls this an injection surface that install-time review does not cover (tool poisoning / tool shadowing). Definitions can also change after you approved the server (a rug pull).

• Skim every tool description before you rely on the server. The MCP Inspector lists every tool a server exposes, without a model in the loop.
• Prefer clients that record tool definitions when you approve a server and ask again when they change. The protocol doesn't require this.
• Keep the roster small. More servers mean a larger shared surface.

If a description contains instructions that have nothing to do with the tool's job, remove the server and rotate any credentials you passed to it.

Isolation: container, narrow filesystem, no inherited env

Process isolation is what MCP calls the highest-leverage mitigation: it turns "this server can read my SSH keys" into "this server can read an empty directory."

• Run third-party servers in a container (Docker or Podman) with no volume mounts beyond what the job needs. Stdio still works against the container's stdin/stdout.
• Grant the narrowest filesystem root that works, preferably read-only. Never your home directory for a narrow job.
• Disable network egress when the server does not need it (--network=none for containers). Know the expected destinations when it does.

Credentials: pass secrets per server in the client's config, not from your shell profile. Give each server its own narrowly scoped token. Keep long-lived secrets out of plaintext config where your client can use an OS secret store. Files such as ~/.ssh and ~/.aws are credentials on disk too; isolation is what keeps them out of reach.

OpenClaw-specific: mcp doctor, mcp probe, tool filters

If you run OpenClaw, the MCP registry CLI gives you static and live checks before you lean on a server:

openclaw mcp list
openclaw mcp doctor
openclaw mcp doctor --probe
openclaw mcp probe

Per those docs:

• doctor (without --probe) does not connect. It flags missing stdio commands, invalid working directories, missing TLS files, disabled servers, literal sensitive header/env values, and incomplete OAuth authorization.
• probe (or doctor --probe) connects, lists tools, and reports capabilities and diagnostics. For a local stdio server, connecting means starting it, so do the provenance and isolation steps first.
• configure can update enablement, tool filters, timeouts, OAuth, TLS, and related settings. Add --probe to verify before saving.
• tools <name> --include ... sets per-server tool filters, so agents see only the tools you name.
• add builds a definition from flags and checks before saving unless you pass --no-probe or OAuth is still needed.

probe, doctor --probe, add, configure and tools need the local Gateway stopped first; OpenClaw refuses them while a running Gateway owns its state. add, configure and tools change your saved MCP config, so note the current settings first (openclaw mcp status --verbose shows them without connecting and redacts credential-bearing arguments) and review each change before you run it.

The --approval approve mode skips per-call approval for Codex tool calls. OpenClaw's docs say to use it only for trusted servers, and OWASP's cheat sheet advises against auto-approving tool calls at all, so leave per-call approval on for any server you have just added. After you save a definition, run openclaw mcp doctor --probe again so you know the process starts and exposes the tools you expect.

For credentials that OpenClaw itself holds, prefer the secrets store over plaintext in config — covered in our companion guide on giving agents API keys without exposing them.

What our free check does and does not cover

The free check at /check is paste-only. You paste openclaw security audit --deep output (and ideally openclaw --version). It explains OpenClaw's findings, checks for risky settings such as API keys handed to skills, and checks the version against published security advisories. Look-only and point-in-time. Green means no issues found in the checks we ran.

It does not review MCP server packages or skill code, and it does not detect malicious skills. See Limits of the check. For the wider operator list, use the 12-point checklist.

Where next

• MCP: Local Server Security and Security Best Practices
• OWASP: MCP Security Cheat Sheet
• OpenClaw: MCP registry CLI
• Keys (prevention): Give AI agents API keys without exposing them
• Keys (incident): API key leaked — first hour

Frequently asked questions

Sources

1. MCP docs: Local Server Security (2026-07-28)
2. MCP docs: Security Best Practices (2026-07-28)
3. OWASP: MCP Security Cheat Sheet
4. OpenClaw docs: MCP registry CLI (list, doctor, probe, add)
5. OpenClaw docs: secrets CLI
6. MCP docs: MCP Inspector