MCP Servers for Claude: What to Connect First

There is one reason to connect a server: to give the agent what it cannot see. Duplicating what it already does is pure context cost.

What exists without MCP

A coding agent normally has built-in access to project files, repository search and shell commands. That covers most development work.

The practical consequence: start not from a catalogue of servers but from the question of what you were actually missing. The answer is usually data outside the repository.

Useful for development

Version control beyond the local repository. Pull requests, discussions, issue history. None of that is local, and the reasoning behind a decision often lives exactly there.

An issue tracker. The agent reads the ticket itself instead of you pasting it into chat. Especially useful when the ticket contains a discussion.

Documentation. An internal knowledge base or the docs of the libraries you use. It closes the class of problems where the agent relies on outdated knowledge.

Useful for data

A read-only database. The most valuable server after files: the agent sees the real schema and real values rather than your paraphrase. Queries written against the actual structure are noticeably better.

Write access is added separately and deliberately. A dedicated user, only the tables required, and no production until the workflow is proven - see security.

Analytics and metrics, where decisions depend on numbers.

Useful for external services

This depends entirely on the task, but one rule holds: a server from the service vendor beats a third-party one. It is maintained by whoever owns the API and will not break at its next change.

Typical candidates: a messenger for notifications, spreadsheets for reports, cloud storage, a CRM. Connect them for a task and disconnect when the task is done.

Connection order

1. Files with a restricted root - if built-in access is insufficient or you need to work outside the project.
2. Version control.
3. A read-only database.
4. Then per task, one at a time.

A rule worth keeping: after connecting, check a week later whether you use it. If not, disconnect. An unused server occupies context in every task.

What not to connect

• Duplicates of built-in capability, such as a filesystem server when file access already exists.
• Servers with thirty tools for the sake of two.
• Everything in the catalogue at once. Context runs out faster than you work out what was useful.
• Servers with write access before you have watched them work read-only.

The mechanics inside Claude Code are covered in MCP servers in Claude Code, and the general procedure in connecting. How to choose between similar servers is in the catalogue. The overview is in the MCP guide.