Remote vs GitHub vs npm vs PyPI MCP Servers: What’s the Difference?

Point three different people at "the GitHub MCP server" and they may connect three different things: an npx command that downloads a package, a URL they paste into their client, or a repository they clone and run. They are not the same server delivered three ways — they are three delivery models, and the model you choose changes who runs the code, what you have to trust, and how much of the server anyone can actually verify before it touches your data.

An MCP server reaches you in one of four ways: an npm package, a PyPI package, a GitHub repository, or a remote endpoint. This guide explains what each one is, how you connect it, what it means for security, and how the MCP Trust Checker scanner reads each one — because a scanner can only grade what a given delivery model lets it see.

The two axes that actually matter

Before the four types, two questions cut through all of them:

• Where does the code run? On your machine (npm, PyPI, GitHub — the client spawns a local process) or on someone else's machine (a remote endpoint you connect to over the network).
• What can be inspected? The published source (npm/PyPI/GitHub) or only the live tool surface the server chooses to advertise (remote).

Everything below is a consequence of those two answers.

npm — the Node package

The most common MCP server: a Node package published to the npm registry, launched locally with npx. The client spawns it as a subprocess and talks to it over stdio.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/docs"]
    }
  }
}

Trust implications. The code runs on your machine with your user's permissions — it can read the files, hit the network, and run the commands its process is allowed to. But the published artifact is fixed: the exact bytes on npm are what runs, and they are fully readable. That makes npm servers highly auditable. Some carry build provenance (a cryptographic link from the package back to the commit and CI run that built it) or ship under a verified vendor scope, which raises how strongly you can trust that the package is what its author intended.

PyPI — the Python package

The Python equivalent: a package on PyPI, launched with uvx (or pipx). Mechanically identical to npm from a trust standpoint — a local subprocess over stdio, a fixed published artifact you can read.

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "/path/to/repo"]
    }
  }
}

Trust implications. Same as npm: local execution with your permissions, but a published, inspectable artifact. The one difference worth knowing is provenance maturity — PyPI's supply-chain signals (Trusted Publishing, attestations) are newer and less universal than npm's, so a smaller share of PyPI servers can prove where they were built.

GitHub repository — the raw source

Plenty of MCP servers are never published to a registry at all. They are a repo you are told to clone, or a pre-release you want to read before it ships. You point your tooling at owner/repo and run the source directly.

mcptrustchecker scan upstash/context7
mcptrustchecker scan https://github.com/owner/[email protected]

Trust implications. A repository is not a released artifact, and that distinction matters. "The default branch" is a moving target — it can change between the moment you read it and the moment you run it — and there is no publish step, no version pin, and no provenance tying it to a distributed package. You get maximum visibility (all the source is right there) but the weakest guarantee that what you read is what a user elsewhere runs. It is the honest middle ground: fully readable, but unversioned.

Remote endpoint — someone else's server

The newest model, and the one that behaves least like the others. A remote MCP server runs on the provider's infrastructure; you connect to a URL over Streamable HTTP (or the older SSE transport). Nothing is installed and nothing runs on your machine.

{
  "mcpServers": {
    "example": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Trust implications. This flips the whole picture. The code does not run locally, so it cannot touch your filesystem directly — but you also cannot read it. There is no published source to inspect; you see only the tool surface the server advertises over the wire, and that surface can change server-side at any time, with no new version to notice. Many remote servers sit behind OAuth or an API key, which means the tools they expose (and the data they can reach) depend on your account and permissions. The trust question shifts from "what does this code do" to "what is this endpoint allowed to do on my behalf, and do I trust the operator."

Side by side

	npm	PyPI	GitHub repo	Remote
Runs on	Your machine	Your machine	Your machine	Provider's server
You connect via	npx + name	uvx + name	clone / source	a URL
Transport	stdio	stdio	stdio	Streamable HTTP / SSE
Source readable?	Yes (published)	Yes (published)	Yes (repo)	No
Versioned / fixed?	Yes	Yes	No (moving branch)	No (changes server-side)
Auth?	Rare	Rare	Rare	Common (OAuth / key)
Main risk	Local code execution	Local code execution	Unversioned code	Opaque operator + your granted scope

How MCP Trust Checker scans each

A scanner can only grade what the delivery model exposes, so the engine reads each type differently — and says so honestly in the result rather than pretending it saw more than it did.

• npm / PyPI — the scanner fetches the published artifact and reads its real shipped code. Coverage is source. If the package carries build provenance or a verified vendor scope, the verification tier rises to source or vendor, and the Trust Score reflects that stronger identity.
• GitHub repo — the scanner fetches the repository archive over HTTPS and reads the source in memory (nothing is cloned to disk or executed). Because a repo is not a released artifact, the verification tier is capped at repo — public, readable source, but no publish provenance. Never vendor.
• Remote endpoint — there is no source to read, so the scanner connects over the wire (handling OAuth sign-in when required) and inspects the live tool surface: the tools, their descriptions, and their input schemas. Coverage is live — a real check of what the endpoint actually advertises, but not a source-level audit, and the result is labelled that way.

This is why two servers with the same name can score differently: an npm package whose source is fully readable and provenance-verified gives the scanner far more to go on than a remote endpoint that only exposes a handful of tool descriptions. The grade always states what it was computed from.

Which should you prefer?

There is no single winner — it depends on what you are optimising for:

• Maximum auditability → a published npm or PyPI package, ideally one with build provenance. You can read exactly what runs, and it is version-pinned.
• Reading before you run → the GitHub repo, so you can inspect a specific commit — just pin the ref, because the branch moves.
• No local install, or a service you already trust → a remote endpoint, accepting that you are trusting the operator and granting it scope on your behalf. Prefer official vendor endpoints, and treat the OAuth consent screen as the real security boundary.

Whichever you pick, you can check it first. The free online scanner grades all four — paste an npm or PyPI name, a GitHub owner/repo, a remote URL (with OAuth sign-in), a tools.json manifest, or your whole client config — and every result comes with a shareable link and a live Trust Score badge. Browse graded servers of every type in the MCP Trust Registry.

npx mcptrustchecker