Free MCP Servers: A Working Catalogue

There are many ready servers and their quality varies. More useful than a link list that will go stale is an understanding of the categories and the selection criteria.

The categories

Files and the local environment. Reading and writing files, search, directory work. The most common first install and the one most sensitive to permission setup.

Version control. History, branches, changes, issues and pull requests. Useful where the agent needs the context of changes rather than only the current code.

Databases. Schema, queries, sometimes writes. The largest benefit and the largest risk. Start read-only.

External services. Trackers, messengers, spreadsheets, CRMs, cloud storage. Increasingly there is an official server from the service itself.

The web. Fetching pages and searching. Useful for current data; remember that page contents enter context with all that implies.

Documentation and knowledge bases. Search over internal documents. Often the most underrated class: that is where the decisions live that the code does not record.

Choosing between similar servers

Five criteria, in order of importance:

1. Who publishes it. A server from the service vendor is more reliable than a third-party one: it is maintained by whoever owns the API.
2. Whether the project is alive. Last change date and responsiveness to issues. A dead server breaks at the first external API change.
3. What permissions it asks for. A server that needs write access to read is a bad sign.
4. How many tools it exposes. A server with thirty tools occupies a noticeable share of context in every task, even if you use three.
5. Description quality. Read how the tools are described. Vague descriptions mean the agent will choose wrongly, and you cannot fix that from your side.

What to check before connecting

Connecting a server is adding a dependency, not clicking a button. A reasonable minimum:

• What the package is and who publishes it. A typo in a package name is a known way to slip you somebody else code.
• Which permissions it needs and why. If it asks for a full-access token and the task is reading, issue a read-only token.
• Where it goes on the network. A local server that somehow needs the internet deserves an explanation.
• What lands in context. A server returning large responses will be expensive in every task.

And the main rule: start with reads. Write access is added once you have seen how the server behaves. The long version is in security.

What to avoid

• Servers with broad permissions “so it definitely works”. The most common source of trouble.
• Abandoned projects. Six months without changes against a live external API is a bad sign.
• Servers duplicating what the agent already does. A separate file-reading server when file access already exists is pure context cost.
• Ten servers at once. Connect one at a time and see whether you still use it a week later.
• Project configs from unfamiliar repositories without reading them. Cloned a project? Look at which servers it brings along.

A practical starter set

For development, three usually suffice: files with a restricted root, version control, and a database with read-only rights. That covers most tasks and leaves the context free.

Everything else gets connected for a specific task and disconnected when the task is done.

How to connect: step by step. If the server you need does not exist: write your own. The overview is in the MCP guide.