2026-07-31 · RESEARCH · The Offensive Technology team

Remote MCP Server Security: What a Census of 19,321 Published Servers Shows

Half of the servers in the official Model Context Protocol registry are remote. We pulled the full published population on 31 July 2026, 19,321 unique servers, and read how each one ships. 50.0% expose a remote endpoint, a URL your AI agent connects to over the network so the code runs on someone else's machine and you see only the results it returns. The other half, 48.3%, are local packages that run on your own box where you can inspect them. That single split is the security question buried in every MCP install: are you adding a library you control, or wiring your agent into a stranger's server? On top of that, 30.5% of servers ask you for a credential before they will run, and the remote half resolves to 7,420 distinct third-party hosts. None of these numbers name a server, a company, or a person. They are the base rates of an ecosystem most teams are adopting faster than they are auditing.

What a remote MCP server actually is

The Model Context Protocol is the wiring that lets an AI agent call external tools: read a ticket, query a database, open a pull request. A server advertises a set of tools, the agent picks one, sends arguments, and reads the response back into its working context. There are two ways that server can reach you. A local server is a package, on npm or PyPI or an OCI image, that you install and run yourself; it talks to the agent over stdio on your own machine. A remote server is a URL. Your agent opens a connection to it, streams tool calls out, and streams results back in.

The difference is a trust boundary. With a local server the code, the dependencies, and the outbound network calls are all on hardware you control and can inspect. With a remote server the code lives on the operator's infrastructure. You do not see it, you cannot pin its exact version by hash the way you can a package, and every argument your agent sends, along with whatever your agent chose to include as context for the call, crosses to that operator. The tool results that come back are then trusted by the agent as if they were its own reasoning. That return path is exactly where tool-poisoning and indirect prompt injection live.

How the 19,321 published servers ship

Here is the whole population, broken down by how each server reaches your agent. The remote share is the headline, because it is the share where the trust boundary leaves your machine.

The exact split is worth stating plainly, because the rounded halves hide a detail. Of the 19,321 servers, 8,642 (44.7%) are remote only, with no local package you could run instead. Another 1,014 (5.2%) offer both a remote endpoint and a local package, so you can choose. 9,323 (48.3%) are local-package only, and a residual 342 (1.8%) declared neither a package nor a working endpoint. So when a server is remote, most of the time it is remote with no fallback: using it means accepting the third-party endpoint, or not using it at all.

The credential ask: a third of servers want your keys

A tool that reads your GitHub issues or queries your observability stack needs to authenticate somewhere, so credential requests are expected. The number is still worth pinning: 30.5% of published servers, 5,888 of them, declare at least one secret-shaped credential, an environment variable or an auth header whose name carries a token like KEY, TOKEN, SECRET, PASSWORD, or AUTH. Roughly one server in three wants a live credential before it will do anything.

Pair that with the remote share and the risk sharpens. When you hand a credential to a local server, the secret sits in your environment and the tool uses it from your machine. When you hand a credential to a remote server, you are either passing it across to the operator or authorizing the operator to act with it on your behalf. Either way the operator becomes a holder of your key. If that operator is careless with logs, or is compromised, the credential you scoped for one tool becomes an attacker's. Least privilege is not optional here: a server should get a token scoped to exactly what its tools need and nothing else.

Where the remote endpoints actually live

The remote half does not resolve to a handful of trusted clouds. The 9,656 servers with a remote endpoint spread across 7,420 distinct hosts. The long tail is real: 98.1% of those hosts serve exactly one server, which is a lot of independent operators, each a separate party you would have to vet. If your agents adopted the registry wholesale they would be opening connections to thousands of different endpoints, most run by someone you have never heard of.

At the other end of the distribution sits concentration. The single largest gateway host fronts 13.5% of all remote servers, and the ten busiest hosts account for 18.9% of remote endpoints between them. About a quarter of remote servers ride a shared, multi-tenant host rather than their own domain. That is the double-edged shape of any marketplace: a few aggregators carry a big slice of the traffic, which is convenient and also means a single operator or a single outage sits under a large fraction of the ecosystem. We are not naming those hosts; the point is the shape, not the address.

The scare that was not there: hidden Unicode

One well-demonstrated MCP attack hides instructions for the agent inside the text fields a server publishes, using invisible characters: Unicode tag codepoints, zero-width joiners, bidirectional controls, ANSI escapes. The agent reads them, a human reviewer does not. We scanned every model-visible text field of all 19,321 servers for those codepoint classes. The result is a clean null: 0 of 19,321 servers carried a non-printing or injection-class character in their registry metadata.

That is good news with a boundary on it, and the boundary matters. The registry publishes a server's name, title, and description, but not the descriptions of the individual tools it exposes, which are the fields loaded into the agent's context on every call and the richer target for a hidden-instruction attack. Our null says the registry's own metadata layer is clean today. It does not say the tools behind those servers are, because the registry does not hand out that surface to read passively. So the honest headline is narrow: at the layer we can measure without touching anyone's server, the invisible-character channel is not being used.

The attacker's read of this registry

Look at these numbers from the chair that decides whether a control matters. An attacker who wants into an organization through its AI tooling has two obvious plays here, and the census shows both are viable at scale. The first is to operate a server: publish something useful, get it installed, and now you legitimately receive every request the agent sends and you control every result it reads. With half the registry already remote, one more remote server draws no suspicion. The second is to compromise an operator who already holds many teams' trust, and the concentration at the top of the host distribution shows where that leverage sits.

The credential figure is the multiplier. A third of servers are already trusted with a secret, so a poisoned or seized server is not limited to reading traffic; it can hold keys that reach the systems behind the tools. This is the same widening of a footprint we describe in our guide to what attackers can actually see about your company, moved one layer inward: the surface is no longer just your public DNS and services, it is the set of external servers your agents are authorized to talk to. Every one of them is a dependency, and dependencies are how modern intrusions start.

How to keep remote MCP servers on a leash

None of this argues against remote MCP servers. It argues for treating them like the third-party dependencies they are. If you run agents against MCP tooling, this is the short list.

• Keep an allow-list, not an open registry. Decide which specific servers your agents may use and pin them. Half the registry being remote means half of it is an operator you are choosing to trust, so choose deliberately rather than installing on discovery.
• Prefer local when both exist. For the 5.2% that ship both a package and an endpoint, the local package keeps the code and its traffic on your machine. Take it when the tool does not genuinely need to be remote.
• Scope every credential to the tool. With 30.5% of servers asking for a secret, issue a token limited to exactly what the server's tools require, rotate it, and never hand a broad key to a server you have not audited.
• Treat tool output as untrusted input. Results returned by a server can carry instructions aimed at your agent. Constrain what the agent is allowed to do with them, and do not let a tool result silently trigger privileged actions.
• Know who is on the other end. A remote endpoint resolves to someone's host. For the servers you depend on, know the operator, and remember that most hosts in this registry serve a single server run by a single party.

Method, so a skeptic can trust the numbers

The dataset is our own, built from a public source, aggregate only. We queried the official Model Context Protocol registry's public listing API and paged through the entire catalog on 31 July 2026, storing 62,430 version records. We reduced that to the 19,321 servers marked as the current, latest version, which is the deduplicated live population and the denominator for every percentage here. Deployment was classified from each server's declared packages and remote endpoints; the credential figure counts any declared environment variable or auth header whose name contains a secret-shaped token; host concentration was computed by resolving the hostname of each remote endpoint; and the hidden-character scan tested every text field against the Unicode tag block, zero-width and bidirectional format characters, ANSI escapes, and other control and private-use codepoints.

We read only the registry's own public API. We did not connect to a single one of the servers it lists, did not send a request to any operator's endpoint, and did not collect anything about any individual. Reading a public catalog is a passive act; touching the hosts in it would not be, and we did not.

What this does not prove

A number without its limits is marketing, so here are the boundaries on these.

• It is one registry. The official registry is the central catalog, but servers exist that are never published to it, and other directories list their own. This measures the published, discoverable population, not every server in existence.
• Declared, not observed. Deployment and credentials come from what each server declares in its registry entry. A server could require a secret it did not list, or ship a package it does not really support. We measured the manifest, not a live install.
• Remote is a risk surface, not a verdict. A remote server is not insecure because it is remote. Plenty are run well by serious operators. The 50.0% is the size of the trust decision, not a count of bad actors.
• The null is scoped. Zero hidden-character hits covers the registry's server-level fields only. The per-tool descriptions that load into an agent on every call are not published for passive reading, so this is not a clean bill of health for the tools themselves.
• It is a snapshot. The registry grows daily. These figures describe 31 July 2026, not a trend, and a re-pull next month will move them.

Frequently asked questions

Are remote MCP servers safe to use?

A remote MCP server is only as safe as the operator running it, because your agent sends requests to and reads results from that operator's endpoint. In this census 50.0% of servers were remote, and all of them used HTTPS, so transport is not the gap. Trust is. Pin the servers you vetted and give each one least-privilege credentials.

What is the difference between a local and a remote MCP server?

A local server runs as a package on your own machine, so its code and network calls are yours to inspect. A remote server is a URL your agent connects to, so the code runs on someone else's infrastructure and you see only the responses. In the census 48.3% were local only, 44.7% remote only, and 5.2% offered both.

How many MCP servers are there?

The official registry listed 19,321 unique published servers when we pulled the full population on 31 July 2026, counting only the latest version of each. It is growing fast, so treat that as a dated snapshot.

Do MCP servers require API keys or credentials?

Many do. In the census 30.5% of servers declared at least one secret-shaped credential, so roughly one in three asks for a key or token before it will run. That widens the blast radius if the server or its operator is compromised.

Can an MCP server steal your data?

A malicious or compromised server can read every request your agent sends it and return crafted results back into the agent's context, which is how tool-poisoning and prompt-injection work. It cannot reach past the tools and credentials you grant it, so least privilege and an audited allow-list are the defense.

Is the MCP registry vetted?

No. Listing is publication, not a security audit. The registry records where a server lives, not whether its operator is trustworthy. Remote servers resolved to 7,420 hosts, 98.1% of which served a single server, so most of the supply chain is operators you would vet individually.

What are the security risks of MCP servers?

The main ones are a server returning poisoned tool output into your agent, a remote operator seeing and logging every request, credential exposure when a server demands keys, and concentration when many servers sit behind one gateway. In this census, exotic tricks such as hidden Unicode were absent from registry metadata, 0 of 19,321, so the near-term risk is trust and access, not encoding.

Related reading

• What can attackers actually see about your company? The surface this post extends inward to your agent tooling.
• Is p=none enough? The same passive-measurement method, applied to email authentication.
• Authorization first. Why every measurement we publish stays on the lawful side of the line.