MCP servers: when to build one and when to use what's there
Model Context Protocol is the right abstraction for connecting LLMs to your systems. Most teams should consume the existing servers (GitHub, Linear, Slack, Vercel) and only build their own for proprietary internal APIs.
MCP went from interesting to load-bearing in less than a year. The reason is that it solves the boring half of agent integration: standardised tool definitions, transport, and authentication that any client (Claude Code, Cursor, the Anthropic API) speaks natively.
The build-vs-buy heuristic I land on: consume existing servers for anything that touches a third-party SaaS. The official GitHub, Linear, Slack, Atlassian, and Vercel servers are good enough that writing your own is rarely worth it. They handle auth, pagination, and the long tail of edge cases that always bite when you do it yourself.
Where building pays off: your own internal APIs. A custom MCP server that wraps your commercetools project, your internal feature flag system, or your service catalog turns a 50-line tool-use loop into a single dependency. The engineering cost is one afternoon for a basic server, and the productivity dividend is every agent your team runs from that day forward.
The trap to avoid: building MCP servers for everything in your stack just because you can. Each server is a deploy target, a permissions surface, and a maintenance cost. Build the two or three that matter, consume the rest, and resist the urge to MCP-ify your whole infrastructure.