An MCP Server Runs Like Installed Software—Verify It Before the First Command

Verify an unfamiliar MCP server as executable software before installing or connecting it: identify the publisher and exact artifact, inspect the startup path, inventory effective access, review dependencies and tool definitions, then plan an isolated first run. Installation, connection and tool discovery should not authorize an operational command.

For a local server, that caution is literal: the process runs on the user’s machine and may inherit the MCP client’s privileges. The official MCP security guidance identifies arbitrary command execution, data exfiltration and data loss as risks of inadequately restricted local servers; it calls for displaying the full startup command, obtaining explicit consent and restricting filesystem, network and other system access.

1. Establish provenance before evaluating features

A registry entry is a discovery lead, not proof of trust. Trace the package or remote endpoint to a publisher-controlled repository or website, then confirm that the package namespace, documentation, repository and release metadata describe the same project. Look closely at near-match names, unexplained ownership changes, unrelated download domains and installation instructions that execute fetched content.

Record the exact version, commit or container digest under review. Verify a publisher-provided checksum or signature when available, while recognizing its limit: integrity establishes that the artifact matches a referenced release, not that its code is safe. If a package cannot be mapped to reviewable source, admit it as opaque software rather than assuming its public listing supplies that assurance.

For a remote server, replace the package check with an operator and endpoint check. Confirm who controls the hostname, where authorization redirects lead, which downstream services the server can reach and how credentials can be revoked. Remote execution reduces direct host exposure, but a broadly scoped cloud token can still create a large blast radius.

2. Read the startup path and supply chain

Expand a local server’s complete launch command exactly as the client will execute it: executable or interpreter, arguments, working directory and supplied environment variables. Pin package-runner commands to a reviewed version or immutable digest. Unexplained shell expansion, privilege elevation, encoded commands, chained download-and-execute steps or access to sensitive paths should stop admission.

Review the code at trust boundaries rather than reading only the README: process creation, filesystem operations, outbound requests, credential loading, installation scripts, update behavior and tool registration. Inspect the lockfile and inventory direct and transitive dependencies, including packages that execute installation hooks.

The OWASP MCP Security Cheat Sheet recommends verified sources, source and tool-definition review, checksums or code signing, dependency scanning, least privilege and monitoring for post-install changes. It treats tool descriptions, parameter fields and schemas as an attack surface, so a clean package name or plausible documentation is not sufficient.

3. Assign a risk tier from effective access

Classify a server by what it can actually reach and change, not by its product category or whether it is local or remote. When several capabilities apply, use the highest applicable tier and retain the controls required by the lower tiers. The following tiers are a sample admission policy, not part of the MCP standard.

• Tier 1 — isolated read-only: no network, credentials, shell or writes; access is limited to explicitly mounted, non-sensitive data. Use read-only mounts and resource limits.
• Tier 2 — networked: outbound access is required, but broad filesystem access and local secrets are not. Allowlist necessary destinations, block unnecessary private-network routes and record destination changes.
• Tier 3 — filesystem write: tools can create, edit or delete files. Mount only named working directories, exclude home and system paths, and require confirmation for destructive operations.
• Tier 4 — shell or process execution: tools can launch commands or child processes. Use an isolated account or container, constrain executables and working directories, and show complete arguments for per-call approval.
• Tier 5 — credentials or administration: the server receives production tokens, signing keys, database credentials or privileged API scopes. Use narrow, per-server, short-lived credentials, centralized audit records and a tested revocation procedure.

Runtime defaults do not justify access. A local indexer does not need outbound networking merely because its runtime enables it, while a remote server should not receive write scopes when its approved tools only read data.

4. Make the first run disposable and observable

Start the admitted artifact outside the normal developer profile. Use a disposable workspace, synthetic files and test credentials; mount only reviewed paths and disable network access unless the approved function requires it. Apply CPU, memory and runtime limits, then capture child-process creation, file activity and outbound connection attempts.

Discover the server’s tools in that environment before allowing a model to invoke them. Compare every name, description, input schema and declared effect with the reviewed snapshot. Reject definitions that instruct the model to disregard higher-level instructions, collect unrelated context, invoke other tools or transmit data outside the stated purpose.

Exercise only representative calls with harmless inputs. A read-only operation should not write files; a local transformation should not open a network connection; an authorization test should not request undocumented scopes. An unexpected effect pauses admission until it is explained and the policy is updated deliberately.

5. Print the admission checklist and retain the baseline

Complete every applicable item before connecting the server to real data or credentials. Record a reason for “not applicable”; treat “unknown” as an unresolved control rather than approval.

• Publisher identity, official repository and distribution channel agree.
• The admitted version, commit, checksum, signature or image digest is recorded.
• The complete local command, or the remote endpoint and authorization path, is visible and reviewed.
• Source, installation scripts, update behavior and tool definitions match the stated purpose.
• Direct and transitive dependencies are inventoried and scanned.
• Filesystem, network, process, credential and API access are justified separately.
• The risk tier has an owner, isolation policy and human-approval boundary.
• The disposable first run shows no unexplained process, file or network activity.
• Tool names, descriptions and schemas are stored as the approved baseline.
• Logs redact secrets, and rollback, revocation and removal procedures are defined.

Approval belongs to the reviewed artifact and behavior, not permanently to a server name. Pin the artifact where possible and compare tool definitions after an update or remote-service change. A new parameter, write capability, destination or scope requires renewed review; an unexplained definition change should disable the affected tool until its provenance and effect are understood.

Also read:

• Student Startup Marketing Starts Before You Post: Prove Demand First
• Startup Option Pools: Calculate the Pre-Money Dilution Before You Sign
• How to Read a Startup Term Sheet Before You Sign It