MCP Installation Method Statistics 2026: npx Leads 40% of Listings

MCP installation is still command-line first: 209 of 520 listings use npx as their normalized launcher, compared with 99 using uvx and 56 using a direct remote URL.

Contents

• Methodology and limitations
• Main findings
• Interpretation
• Practical decision guidance
• How to cite or download the data
• Related MCPtrove research
• FAQ

Methodology and limitations

This analysis uses MCPtrove’s 520-listing snapshot. It describes the primary installation configuration stored for each listing, rather than every installation path a server may support.

A listing may offer several ways to run the same server. For example, its documentation may include a package-manager command, a Docker image, a source installation, and a remote endpoint. MCPtrove records the primary configuration represented in the directory, then assigns it a normalized installation method. The result is useful for understanding how MCP servers are presented to users, but it should not be read as a complete inventory of every available setup option.

The classification rule is straightforward. A configuration containing a URL or HTTP transport is classified as Direct remote URL. Otherwise, MCPtrove normalizes the command or installation prefix into npx, uvx, Docker, Python or uv, JavaScript runtime, or Other executable. Both the raw command and normalized method are available in the raw CSV.

The labels used around MCPtrove listings also require context. Category, auth, transport, official, and verified are MCPtrove-normalized fields where relevant. They make listings easier to compare, but they are directory metadata, not claims that MCPtrove independently audited every implementation or authenticated every publisher.

This dataset does not measure user behavior, installation success, runtime performance, or preference. It also does not represent every MCP server in existence. It represents the listings included in this MCPtrove snapshot and the primary configuration associated with those listings.

Main findings

The normalized launcher distribution is:

npx is the clear leader, accounting for 40.2% of the snapshot. uvx follows at 19.0%, while Direct remote URL represents 10.8%.

The distribution has two important characteristics. First, the dominant methods are familiar command-line launchers. npx and uvx together form the center of gravity for local package-oriented setup. Second, the remainder is meaningfully fragmented. Direct remote URLs, Python or uv runners outside the normalized uvx group, other executables, alternate JavaScript runtimes, and Docker all appear as distinct operational patterns.

That fragmentation matters because “installation method” is not merely a presentation detail. It indicates where setup work happens, what has to be trusted, and which parts of the runtime environment remain under the user’s control.

Interpretation

npx leads because it is often the shortest path from a directory listing to a client configuration. Users familiar with the JavaScript ecosystem can copy a command, let the package runner resolve the dependency, and move directly to testing the server. uvx offers a similar experience for Python-oriented projects, with an emphasis on running tools in an isolated environment without requiring a conventional global installation.

The advantage of these launchers is operational simplicity. They compress several setup steps into a client configuration and are well suited to experimentation, evaluation, and personal workflows. Their convenience does not eliminate trust decisions, however. A command that downloads and executes a package still crosses a software supply-chain boundary.

Direct remote URLs move more of the runtime responsibility away from the local machine. They can reduce local dependency management and may be attractive when a provider operates the server as a hosted service. But Direct remote URL does not mean zero setup. OAuth, account creation, permissions, client support, network access, and provider-specific configuration may still be required.

Docker addresses a different concern. Its appeal is isolation and repeatability: the server can run inside a controlled image with its dependencies packaged alongside it. That can be valuable for teams, testing environments, and workflows where host-level dependency drift is undesirable. The tradeoff is additional operational weight, including image management, container permissions, networking, and sometimes more complicated credential handling.

The dataset does not establish that any method causes better adoption, higher reliability, or stronger security. It shows how primary configurations are distributed in this snapshot. Any relationship between launcher choice and user outcomes would require separate behavioral or operational measurements.

The editorial conclusion is practical: launcher choice is an operational dependency. npx and uvx win on copy-paste speed; remote URLs reduce local runtime work; Docker improves isolation at a cost. The right choice depends on the trust boundary and the desired repeatability, not on the shortest command alone.

Practical decision guidance

Choose npx when the server is JavaScript-oriented, the package source is trusted, and quick local setup matters most. It is a strong default for trying a server from a client configuration, especially when the project documents a clean package entry point.

Choose uvx when the server is Python-oriented and the project provides a reliable uv-compatible command. It can keep the local environment tidy while preserving a command-line workflow. Review the package source, requested permissions, and authentication behavior before treating convenience as sufficient assurance.

Choose a Direct remote URL when you prefer the provider to operate the runtime or when local dependency installation is undesirable. Confirm which transport the client supports, how authentication works, whether data leaves the local environment, and what account or subscription requirements apply.

Choose Docker when environment isolation, repeatability, or team consistency outweighs setup friction. Verify the image source, required mounts, network access, exposed ports, and credential mechanism. Docker can improve separation, but it does not automatically make an untrusted image trustworthy.

Treat Other Python or uv runner, Other JavaScript runtime, and Other executable as prompts for closer inspection rather than as interchangeable categories. Read the listing’s raw command, check the project documentation, and identify what the command downloads or executes. The normalized label is a comparison aid; the raw command is the operational detail.

For client-specific setup, use the Claude MCP setup guide or Cursor MCP setup guide. If the configuration is unclear, the MCP config generator can help produce a client-ready entry, while the MCP config doctor can help diagnose common configuration problems.

How to cite or download the data

Download the complete source table from the MCP installation method statistics CSV. The file contains the raw configuration information and the normalized installation method used for this analysis.

For the original figures, cite the page and preserve the snapshot context. A copyable citation is:

MCPtrove, “MCP Installation Method Statistics 2026: npx Leads 40% of Listings,” accessed September 23, 2026, https://mcptrove.com/research/mcp-installation-method-statistics.

Related MCPtrove research

For a broader view of the ecosystem, compare this analysis with MCP transport statistics and MCP server language statistics. Transport helps explain how a server communicates after setup, while language provides context for why particular launchers appear.

For hands-on configuration advice, see How to add an MCP server, then use the client guides and configuration tools linked above.

FAQ

Does this show every installation option supported by each server?

No. It records the primary configuration stored by MCPtrove. A single listing can expose many tools and may also support several installation paths, including package managers, Docker, source code, and remote access.

Does a Direct remote URL mean the server requires no setup?

No. Remote execution can reduce local runtime work, but OAuth, accounts, permissions, client compatibility, and network access may still be required.

Is npx automatically the best installation method?

No. npx is the most common normalized launcher in this snapshot, but the best choice depends on the trust boundary, project documentation, client support, and the repeatability you need.

Why are some methods grouped under Other?

The grouping preserves a compact comparison while keeping the raw command available for inspection. Commands that do not match the normalized npx, uvx, Docker, Python or uv, or JavaScript runtime patterns are placed into the appropriate broader category.