MCP Servers Worth Installing: A DevOps Team's Curated List
The MCP (Model Context Protocol) ecosystem has exploded. There are now hundreds of servers covering everything from Notion to Neo4j. Most of them you do not need. Installing too many slows responses, adds debugging overhead, and inflates your context window with tool definitions that never get used.
This guide applies a simple filter: only install a server if it saves your team more than five minutes per day. For a DevOps or platform engineering team, that bar eliminates most of the ecosystem and keeps a short, high-value list.
How MCP Fits Into Claude Code
flowchart TD
Dev[Developer] -->|natural language query| Claude[Claude Code]
Claude -->|tool call| MCP[MCP Server]
MCP -->|authenticated request| Service[External Service\nGitHub / PagerDuty / AWS etc]
Service -->|structured data| MCP
MCP -->|response| Claude
Claude -->|answer in plain English| Dev
Without MCP, you copy-paste data into Claude. With MCP, Claude pulls data directly — no copy-paste, no context switching, no stale information.
The Servers Worth Running
1. GitHub MCP
Why it earns its place: PR reviews, issue management, and CI status checks are daily tasks. With GitHub MCP, you can ask “what is blocking my PR?” and Claude reads the review comments, CI failures, and requested changes without you switching tabs.
claude mcp add --transport http github https://api.github.com/mcp/ \
--header "Authorization: Bearer ghp_YOUR_TOKEN"
Useful queries once configured:
What PRs need my review today?
Summarise the failing CI checks on PR #342
Create an issue for the memory leak we discussed, assign it to me
What did we merge in the last 3 days?
2. PagerDuty MCP
Why it earns its place: During incidents, you want Claude to read the timeline, services affected, and past resolution notes — not you manually fetching them. PagerDuty MCP turns Claude into an effective incident co-pilot.
{
"mcp": {
"servers": {
"pagerduty": {
"transport": "stdio",
"command": "mcp-pagerduty",
"args": ["--api-key", "YOUR_PD_KEY"]
}
}
}
}
Useful during incidents:
What services are currently in alert state?
Summarise the last 5 incidents for the payments service
Who is on-call right now?
3. AWS MCP (read-only)
Why it earns its place: Diagnosing infrastructure issues without console context switching. Read-only access to CloudWatch logs, EC2 status, ECS task definitions, and S3 bucket policies covers 80% of what you need during debugging.
Important: Restrict to read-only. Never configure write access via MCP — destructive AWS operations should go through Terraform or the console with human review.
{
"mcp": {
"servers": {
"aws": {
"transport": "stdio",
"command": "mcp-aws",
"args": ["--profile", "readonly", "--region", "us-east-1"]
}
}
}
}
Useful queries:
What errors appeared in CloudWatch for the payments service in the last hour?
List ECS tasks that are not in RUNNING state
What is the current CPU utilisation on our RDS cluster?
4. Linear MCP (or Jira MCP)
Why it earns its place: Converting Slack conversations and incident retrospectives into properly structured tickets is a time sink. With Linear MCP, Claude creates, labels, and assigns tickets from natural language.
claude mcp add linear --api-key lin_YOUR_KEY
Useful queries:
Create a ticket for the memory leak in the auth service, P2, assign to the platform team
What tickets are blocking the next release?
Mark PLAT-234 as done and add a comment with the fix summary
5. Sentry MCP
Why it earns its place: Production errors with full stack traces and context — queryable in plain English. Stops the copy-paste workflow of grabbing Sentry errors and pasting them into Claude.
What errors spiked in production in the last 2 hours?
Show me the full stack trace for the NullPointerException in the checkout service
How many users were affected by the session bug last week?
Servers to Skip (and Why)
flowchart LR
subgraph Skip[Skip These]
N[Notion MCP\n3-5s latency per call]
P[Postgres MCP against prod\nrisk of destructive queries]
G[Google Drive MCP\nbroad access no daily value]
S[Slack MCP\nbetter handled by webhooks]
end
subgraph Keep[Keep These]
GH[GitHub MCP]
PD[PagerDuty MCP]
AWS[AWS Read-only MCP]
LN[Linear MCP]
SE[Sentry MCP]
end
Postgres MCP against production — the risk of Claude issuing a destructive query outweighs the convenience. If you want database access, point it at a read replica with a read-only user and a row limit.
Notion MCP — high latency, low return. If your team’s knowledge base is in Notion, export relevant pages to markdown and use them in CLAUDE.md instead.
Slack MCP — reading Slack history through MCP is slower than just reading it yourself. Use outbound webhooks for Claude to post to Slack; do not install inbound Slack MCP for retrieval.
Project-Level vs Global Configuration
Put servers that are project-specific in .claude/settings.json (committed to git so the whole team gets them). Put personal preferences in ~/.claude/settings.json.
~/.claude/settings.json ← personal servers (your GitHub token)
.claude/settings.json ← project servers (team Linear workspace)
.claude/settings.local.json ← personal project overrides (gitignored)
Check what is actually being used:
claude mcp list # see all configured servers
/mcp # check server status inside a session
Watch Claude’s responses for tool names like github_list_pull_requests or sentry_search_errors. If you never see a server’s tools in use, uninstall it — it is paying context overhead for nothing.
The Evaluation Framework
Before installing any new MCP server, answer three questions:
- Does this replace a daily copy-paste workflow? If yes, install it.
- Could this server make a destructive change? If yes, either restrict it to read-only or skip it.
- Will Claude actually use it, or will I forget it exists? If unsure, skip it for now.
Five well-chosen MCP servers outperform twenty poorly chosen ones every time.
