MCP Server Supply Chain: What You Install When You Add a Server

Map the dependency before approving the connection

A server listing, an installation command and a running tool are different things. The MCP transport specification describes stdio as communication with a client-launched subprocess, while Streamable HTTP sends messages to an endpoint. That distinction changes your review: a local package brings executable code into your environment; a remote service brings an operator into the path of tool arguments and results.

For each proposed connection, record the publisher, package or endpoint, exact approved release, runtime, dependency inventory, startup command, credential owner and permitted data. Include the installer as well as the server. A shell wrapper that downloads another program adds a dependency that a review of the named repository alone would miss.

Keep this record attached to the agent configuration. Someone reviewing the connection should be able to identify the approved artifact without reconstructing a developer's package cache. For the deployment choice itself, see remote versus local MCP servers.

Verify the publisher and the distributed artifact separately

The MCP Registry's own documentation says it hosts metadata pointing to packages and uses namespace authentication to establish publisher identity. It delegates security scanning to package registries and downstream aggregators. Treat a verified namespace as evidence about who published the listing, not as a code review.

Follow the publisher's own website or repository to the package identifier and endpoint. Compare spelling, organization, release history and installation instructions. If the package and repository claim different owners, resolve that discrepancy before supplying company credentials. For hosted servers, verify the endpoint through the provider's documentation rather than a copied configuration snippet.

Where npm provenance exists, inspect the source and build information it links to. npm explicitly warns that provenance does not establish that a package lacks malicious code. Use it to connect the downloaded artifact to its claimed build, then review that build and its inputs. Record missing evidence as an unresolved review item rather than silently treating it as verified.

Separate installation from agent startup

npm's execution documentation explains that missing requested packages can be installed into its cache before execution. A convenient launch command can therefore also be an installation path. Avoid making a fresh agent session the moment an unreviewed dependency is first fetched and executed with production credentials available.

For a Node-based server you package internally, review its dependency changes and committed lockfile before installation. In a disposable build environment containing that project's package.json and matching lockfile, an initial installation can use:

npm ci --ignore-scripts

npm documents that ci fails when the lockfile and manifest disagree and does not update them. The flag suppresses package scripts during installation. A server requiring generated files or native build steps needs a separately reviewed build; suppressing scripts does not make the resulting application trustworthy.

After deploying your reviewed server at the illustrative path below, Claude Code's documented stdio syntax can launch it directly:

claude mcp add --transport stdio reviewed-docs -- node /opt/company/mcp/reviewed-docs/server.js

Replace the path with your deployment's entry point. This removes package downloading from the launch command; it does not provide process isolation. Record the deployed Node runtime version alongside the server release.

Give the process only the environment it needs

The MCP security guidance warns that inadequately restricted local servers can execute with the client's privileges. For document search, review the process boundary before judging the advertised operations.

Run the server under a restricted identity or isolated environment with only the required directories mounted. Define its outbound destinations and supply an explicit environment containing only the credentials it needs. Test denied access as well as successful searches: an unrelated repository, a private key directory and an unapproved network destination should remain unavailable.

For a hosted server, request the equivalent operational evidence from its operator: who deploys updates, which dependencies are maintained, what data is retained and how incidents are handled. Those answers belong in the connection record. The practical local-process boundary is covered further in local stdio server risks.

Review tool descriptions as part of the release

The MCP tools specification exposes tool names, descriptions and input schemas through discovery. These fields help the model choose what to call. They belong in the review alongside executable code because changing a description can change the agent's decisions without changing the user's request.

Capture the complete tools/list result for the reviewed connection. Inspect descriptions for instructions unrelated to the operation: requesting credentials, directing the agent to read unrelated files, or telling it to send output to another service. Review parameter descriptions too. A top-level summary can look ordinary while a field description asks for unnecessary data.

The specification requires clients to treat annotations as untrusted unless they come from trusted servers. A claim that a tool is read-only is therefore insufficient evidence of its implementation. Verify the upstream permission and actual behavior with a restricted test credential.

Compare discovery snapshots when upgrading or reconnecting. Require review for added tools, broader schemas and changed descriptions. Pinning a local package alone cannot freeze a hosted server's interface or prevent its operator from changing behavior behind the same URL.

Trace each credential to the code that receives it

Draw the authentication path for this particular server: agent to MCP endpoint, then server to database or upstream API. The MCP authorization specification covers HTTP authorization and directs stdio implementations toward environment credentials instead. Authentication to the server and permission at the upstream system need separate review.

Use a dedicated upstream identity restricted to the required repositories, tables or projects. Establish which component stores its token and whether disconnecting the agent also revokes that upstream grant. Test those operations separately. Stopping a local process is not a substitute for revoking a credential it may already have exposed.

MCP's security guidance also rejects accepting tokens intended for another resource and passing them downstream without the proper audience boundary. Ask proxy operators how they separate client authentication from upstream credentials. Avoid approving a server whose only explanation is that it forwards whatever bearer token the agent supplies. For credential placement, continue with where agent OAuth tokens should live.

Where SPYN3 changes the dependency footprint

SPYN3 puts connected systems behind one MCP endpoint per workspace. Upstream credentials stay envelope-encrypted in the workspace; the agent holds a SPYN3 key or OAuth token. Connections are configured, updated or removed once for the workspace instead of on every laptop or VM. Keys can be scoped to chosen sources, and writes require a separate grant. Revocation takes effect on the next call. This centralizes connection ownership; it does not scan server code, pin tool descriptions or detect rug pulls. Keep publisher and interface review in the process.

Make every upgrade a reviewable change

Assign an owner to each approved server who can answer two questions during an advisory: which environments run the affected artifact, and which credentials did it receive? Keep the runtime and transitive dependency inventory with the release so an issue below the server package is still discoverable.

Use the same acceptance record for the first installation and later upgrades:

1. Confirm publisher identity and the artifact or hosted endpoint being approved.
2. Review dependency, build-script, runtime and startup-command changes.
3. Compare discovered tools, descriptions, schemas and requested upstream permissions.
4. Exercise representative calls with test data and verify denied operations.
5. Record deployment locations, the previous working release and the credential revocation procedure.

Schedule updates rather than freezing a release indefinitely. If a release fails review, retain the previous approved artifact only while it remains acceptable; otherwise disconnect the server. A connection is ready when another engineer can reproduce the deployment and remove its access using the recorded evidence.