MCP servers by what they reach

Group servers by the system on the other end

The most useful way to sort MCP servers is by what they reach: a database, a code host, a file system, a browser, a chat or ticket tool, cloud storage. Each of those comes with its own kind of credential and its own way of going wrong, so a server for a database and a server for a ticket tracker deserve different questions even when their READMEs look alike. The directory's reach column records which services a server names in its own description and credential names.

That column is read from documentation, not traced through code. Treat it as the author's own statement of what the server touches, which is a good place to start and a poor place to stop.

Databases

A database server usually offers a tool to describe tables and a tool to run a query. The second is the one to think about. If it accepts any SQL, it can run anything the connection's role allows, including writes, schema changes and very large reads that return private rows into the conversation.

Connect as a role created for the purpose, with read access to the tables the task needs. If writing is required, scope it to one schema. Point it at a copy or a replica where you can. For warehouses billed by the query, a model that loops on a bad query can also run up a bill, so check whether the service lets you cap usage on that role.

Code hosts and ticket trackers

Servers for code hosts and issue trackers tend to wrap a large API with many tools: list, read, comment, open, merge, close. The token decides how many of those are real. A token limited to one repository and to reading is a narrow install. An organisation-wide token with write scope lets the model open and merge changes anywhere it reaches.

These servers also read text written by other people, such as issue bodies and comments. That text can contain instructions aimed at the model. Keeping the token narrow limits what such text could get a model to do.

Files, browsers and the local machine

A filesystem server reaches whatever folders it is pointed at, and a local process often reaches more than that, because it runs as your user. Give it one folder made for the work. Check in its code that paths outside that folder are refused, including paths that climb out with two dots.

Browser automation servers open pages, click and read what is on screen. They act inside whatever sessions the browser holds, so a browser signed into your email lets the model read your email. Run them with a fresh profile that is signed into nothing you would not hand over.

Chat tools, cloud storage and everything else

A server for a chat tool can usually read channels and post messages. Posting is the risky half: a message sent cannot be unsent in most tools, and it goes out under your name or your bot's. Restrict the bot to a test channel until you trust the setup.

Cloud storage servers sit on buckets that often hold more than the task needs. Scope the key to one bucket or one prefix. For any service, the MCP server directory lets you filter by what a server reaches and shows the credential next to it, and the post on what credentials expose goes through narrowing a key step by step.

Servers that call model APIs, search engines or payment services each spend something: money, quota or a reputation for sending. The question to ask is the same for all of them: what does the key allow, and what is the most expensive thing the model could do with it by mistake?

One task, two very different installs

Consider an assistant that needs to answer questions about last month's support tickets. One option is a server for the ticket tracker, with a token that can read one queue. Another is a server for the database that sits behind the tracker, with a connection string for the whole database. Both can answer the question.

The first reaches tickets, through the tracker's own permission model, and the token says exactly which. The second reaches every table in that database, including whatever else lives there, and a query tool will run whatever the role allows. The answers may be the same. The exposure is not.

This is the reason to sort by reach before sorting by feature. When the same task can be done through a narrow service or a broad one, the narrow one is usually the better install, even if its server has fewer tools. Pick the system closest to the data the task needs and no closer to anything else.

When reading the reach column in the directory, a server that names several services deserves a second look. It may be a general tool that works with many systems, which is fine, or it may be one that wants keys for all of them at once. The credential column next to it usually tells you which.

The same reasoning applies to files. A server pointed at one exported folder of reports and a server pointed at the drive those reports came from can answer the same question about last quarter. Only one of them can also read the payroll spreadsheet sitting two folders over, and the model will not know to stay away from it.