What MCP Servers Are Actually Used For

The five shapes

Files and repositories. Reading a working tree, searching it, writing changes, inspecting version history. This is the most commonly installed category and it is where agents spend most of their tool calls. It is also the easiest to over-scope, because granting a whole home directory is one line of configuration and feels no different from granting one project.

Databases and data warehouses. Running queries, inspecting schemas, sometimes writing. Enormously useful and the category where a read-only credential is most obviously correct and most often skipped.

Third party APIs. Issue trackers, chat platforms, calendars, payment systems, cloud providers. The value is that the agent can act in the systems where work actually happens rather than only describing what should be done.

Internal services. A company's own systems, wrapped so an agent can reach them. Usually the highest value category for a team, because the knowledge encoded in internal tools is exactly what a general model does not have.

Browser and operating system control. Navigating pages, filling forms, clicking, taking screenshots, running commands. The broadest capability available and the one that deserves the most scrutiny before installation.

Almost everything in a public catalogue is one of these five wearing a specific brand.

What goes wrong, by category

The useful thing about the categories is that the failures are predictable.

File servers fail on scope. The agent reaches something you did not intend, often a credential file, a personal directory or another project. Nothing dramatic happens most of the time, which is exactly why the over-scoping persists. Configure the narrowest root the work requires.

Database servers fail on ignorance, not access. The connection works, the query runs, and the answer is wrong because the agent did not know that a status column has five meaningful values, or that deleted rows are soft deleted, or that one table is a deprecated copy of another. Access does not confer understanding, and this is the single most common disappointment with database servers.

API servers inherit the API. Its rate limits become your agent's stalls. Its outages become your agent's failures. Its pagination becomes an agent making forty calls where a human would have made one, and paying for forty results in context.

Internal service servers fail on drift. They are built once against a service that then changes, and nobody updates the tool descriptions, so the agent confidently calls something that no longer behaves as described.

Browser and system control fails on ambiguity. The page changed, the selector moved, the command was destructive in a way the description did not convey. This category is where a disposable environment stops being a nicety.

How to decide what to install

Adoption is cheap and reversal is not, so a short discipline pays.

Install for a task you have, not for a catalogue you saw. Every installed server adds tool descriptions to every request, so unused servers are a recurring cost and a source of wrong tool selection.

Prefer read-only until write is demanded by real work. Most value in the first weeks is retrieval and inspection. Write access can be added when a specific workflow needs it.

Scope credentials to the narrowest thing that works. One database, one repository, one project, one API key with a limited role.

Read the tool descriptions before installing. They are what your agent will act on and they reveal how carefully the server was built. Vague descriptions predict wrong selection.

Prune on a schedule. Servers accumulate the way browser extensions do. Once a quarter, remove anything no workflow depends on.

The compounding version of this: a small, well scoped set of servers plus a good retrieval layer beats a large catalogue, because the agent spends less of every request reading about capabilities it will not use.