MCP servers landed in our dev workflow with the soft thud of a useful tool that nobody owns. One person installed mcp-server-postgres, another added mcp-filesystem, a third pulled in mcp-github. By the end of the quarter we had five of them, three engineers depending on each, and zero entries in any service registry.
Then one of them broke. Not catastrophically — it returned malformed JSON for a subset of queries. The agent silently produced wrong answers for two days. We caught it because a customer asked a question whose answer should have been “5” and we kept saying “two records found, no values.” Nobody had paged on it because nobody had defined what “down” meant.
What an MCP server actually is
A long-running process that holds credentials, exposes a typed API, and shapes whatever your agent does. That’s the textbook definition of a production dependency. The fact that it speaks JSON-RPC over stdio instead of HTTP doesn’t change the operational profile.
Three things to do, in order of how often you’ll wish you had:
- Pin versions. Not “latest”. A specific tag. Same as you would pin any library going into prod.
- Health-check on a real call. Not just “is the process running” — issue a known-good query against a known fixture, daily, and alert on drift.
- Treat the credentials it holds as your credentials. A compromised MCP server with database write access is the same blast radius as a compromised application. Scope its permissions accordingly. Audit them.
The unpopular conclusion
Some MCP servers should not exist in your prod path. They were written for a demo. They have no maintainer. They will stop working in three months. If you can’t read the source and understand what it does, don’t ship it next to your agent.
The interface is convenient. The dependency is not free.