The MCP Server Database. What each server holds.
One record per Model Context Protocol server, answering a single question: what does it hold, and what does that reach. Only servers whose access is officially documented are listed, and every record links its source.
- Every record answers one question: what does the server hold, and what does that reach.
- Servers are sorted into four risk classes: holds a credential, reads the filesystem, reaches the network, holds nothing.
- Only servers whose access is officially documented are listed. Every record links its source.
- 9 records today. It starts with the official reference servers and GitHub, because those are the ones whose behaviour is published.
Four risk classes.
A vendor name predicts nothing. What the server holds predicts everything.
Every server on record.
Sorted by risk class. The authentication column is the short version, each record has the full one.
| Server | Publisher | Authentication | Risk class |
|---|---|---|---|
| GitHub | GitHub (official) | OAuth, a personal access token, or GitHub App authentication. | Holds a credential |
| Filesystem | MCP reference server | None. | Reads the filesystem |
| Git | MCP reference server | None. | Reads the filesystem |
| Fetch | MCP reference server | None. | Reaches the network |
| PostgreSQL | MCP reference example | A database connection string, for example postgresql://localhost/mydb. | Holds a credential |
| Memory | MCP reference server | None. | Holds nothing |
| Everything | MCP reference server | None. | Holds nothing |
| Sequential Thinking | MCP reference server | None. | Holds nothing |
| Time | MCP reference server | None. | Holds nothing |
What is not in here yet
Vendor-operated remote servers are the obvious gap: the ones a company runs for its own product and connects over OAuth. They belong in this database, and they are not in it yet, because each one needs its documented scopes read rather than assumed.
The same rule will apply to them. If a vendor does not publish what their server holds, that absence is the finding, and the record will say so rather than filling the gap with a guess.
Documented, or not listed. An empty row is more useful than a wrong one.
Questions, answered.
How the database is built, and why it is sorted this way.
How are servers chosen for this database?
By whether their access is documented by the people who publish them. A server whose credential handling we would have to guess at does not get a record, because a database of guesses is worse than a short database. That is why it starts with the official reference servers and GitHub, and grows from there.
Why group servers by what they hold rather than by vendor?
Because that is what decides the blast radius. A server holding a scoped token and a server reading the home directory fail in completely different ways, and a vendor name predicts neither. The four risk classes are the useful sort order.
Use it with these.
The database says what. These say what to do.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.