The MCP ecosystem has no rules. We think you deserve to know what you're installing.
Open source. Non-profit. Forever free.
AI agents are gaining the ability to install and use software on your behalf. The Model Context Protocol (MCP) is becoming the standard way they do it — connecting to servers that access your files, your databases, your credentials, your cloud accounts.
The MCP registry now lists thousands of servers. There is no review process. No verification. No download counts. No trust signals of any kind. Anyone can publish a server that requests your AWS keys, your database password, or your wallet credentials — and nothing in the ecosystem will warn you.
Agents are increasingly auto-selecting MCP servers and handing them credentials with no way to evaluate whether that server is maintained, legitimate, or safe. The registry is a flat list with no quality signal.
This is the wild west, and the land rush is on.
You decide which servers to trust.
We make sure you have the data to decide.
MCP Scorecard scores every server in the MCP registry using publicly available data. We check the source code, the GitHub repo, the package metadata, the credentials it requests, and the people behind it. We publish everything as open data — free for humans and machines alike.
We don't curate. We don't block. We don't sell rankings. We surface facts and let you draw your own conclusions.
Every signal, every weight, every threshold is in the open source code. If you disagree with how we score something, you can see exactly why — and you can fork it.
The entire scoring pipeline — collection, enrichment, scoring, publishing — is open source under MIT. Audit it, fork it, improve it.
No analytics. No cookies. No fingerprinting. The site is static HTML served from GitHub Pages. We don't know who you are and we don't want to.
Flags are observable data from public sources. We don't maintain blocklists. We don't do manual reviews. We don't accept payment to change a score.
Every score is available as static JSON. MCP clients and AI agents can check trust signals programmatically before granting access.
Not affiliated with any MCP server vendor, registry, or marketplace. No commercial interest in any ranking. We exist to inform, not to sell.
We're at an inflection point. AI agents are moving from "suggest code" to "execute code." From "draft an email" to "manage your infrastructure." MCP is the protocol that makes this possible — and the trust infrastructure hasn't caught up.
Right now, an agent can select an MCP server from the registry, request your database credentials, and execute operations on your behalf. The only thing standing between your data and an unmaintained, unverified server is... nothing. There is no gate.
The time to build trust infrastructure is before the first major incident, not after.
We're not trying to slow down the MCP ecosystem. We're trying to make sure it grows with visibility. Every server deserves a chance to prove itself — and every user deserves the information to make that call.
Check servers before installing them. Share the scorecard with your team. Build tools on top of our JSON output.
Found a false positive? Think a signal is weighted wrong? Open an issue or submit a PR. The methodology is meant to evolve.
The scorecard only works if people know it exists. Blog about it, tweet it, drop it in your team Slack. Every person informed is one fewer caught off guard.
We're one project. The ecosystem needs more — package signing, server attestation, runtime sandboxing. If you're building in this space, let's talk.
Every server is scored 0–100 across four categories. The aggregate trust score is a weighted average.
Has a source repo, license, installable package, website, icon, matching namespace, SECURITY.md, code of conduct, and a unique (non-boilerplate) description.
Repo age, how recently it was pushed, active commit weeks in the past year, contributor count, and release activity.
GitHub stars, forks, and watchers on a logarithmic scale. npm/PyPI download counts planned for a future version.
How many secrets it requests, transport type risk (local stdio vs remote), credential sensitivity (API key vs database password vs wallet key), and package type.
Binary flags that indicate structural or behavioral anomalies, independent of the numeric score. These are observable facts, not opinions.
| Flag | What it observes | Count |
|---|---|---|
| DEAD_ENTRY | No packages and no remotes — server can't be installed or reached | — |
| TEMPLATE_DESCRIPTION | Description matches common boilerplate ("A model context protocol server") | — |
| STAGING_ARTIFACT | Name contains test/staging patterns combined with a template description | — |
| HIGH_SECRET_DEMAND | Requests 5 or more secret environment variables | — |
| SENSITIVE_CRED_REQUEST | Requests wallet keys, database passwords, or other high-risk credentials | — |
| REPO_ARCHIVED | GitHub repository is archived by its maintainer | — |
| NO_SOURCE | No repository URL and no verifiable package source | — |
| DESCRIPTION_DUPLICATE | Same description used by 3+ servers from different publishers | — |
Server data is served from a Supabase Postgres database via REST API.
The pipeline runs on-demand. Four stages, all free public APIs.