Most MCP roundups are written for app developers. This one is for the people who keep infrastructure running — the servers that actually help when your day is logs, databases, containers, and incident triage rather than building a frontend.
A blunt caveat up front: the MCP ecosystem is large and uneven. Plenty of servers are weekend experiments that haven’t been touched in months. The picks below lean toward servers with real ops value and a maintenance story you can check. Verify package names and the current recommended install against official sources before you wire anything into a workflow that matters.
New to all this? Read the MCP explainer and the Windows and WSL setup guide first — this article assumes you know how claude mcp add works.
The ops shortlist with links
Ops shortlist
The MCP servers worth adding first
10 ops picks
GitHub
Issues, PRs, repo search, and review context.
Install / setup
/plugin install github@claude-plugins-official Source / docs
Why it belongs in ops: Issues, PRs, repo search, and change review are daily ops glue.
Filesystem
Scoped access to runbooks, Compose files, scripts, and IaC folders.
Install / setup
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/ops-repo Source / docs
Why it belongs in ops: It lets Claude work against the exact files you operate from, while the directory path keeps the blast radius visible.
DBHub
One database MCP server for Postgres, MySQL, MariaDB, SQL Server, and SQLite.
Install / setup
npx @bytebase/dbhub@latest --transport http --host 127.0.0.1 --port 8080 --dsn "<connection-string>" Source / docs
Why it belongs in ops: It is practical for incident digging because it includes read-only mode, row limits, and timeouts instead of exposing a loose SQL pipe.
Docker MCP Toolkit
Managed MCP servers from Docker Desktop instead of one-off local server configs.
Install / setup
Docker Desktop 4.62+ MCP Toolkit Source / docs
Why it belongs in ops: It runs MCP servers as managed containers, profiles them, and keeps filesystem access explicit.
Playwright
Real browser checks, screenshots, and interaction.
Install / setup
/plugin install playwright@claude-plugins-official Source / docs
Why it belongs in ops: It lets Claude verify deployed web apps and UI flows instead of guessing from code or curl output.
Sentry
Production stack traces and issue context inside the fix session.
Install / setup
/plugin install sentry@claude-plugins-official Source / docs
Why it belongs in ops: When the actual exception is in the coding session, triage is faster and less dependent on pasted logs.
Datadog
Logs, metrics, traces, and dashboard context.
Install / setup
/plugin install datadog@claude-plugins-official Source / docs
Why it belongs in ops: It belongs if your team already lives in Datadog and wants incident context next to the code being changed.
PagerDuty
On-call and incident context while you make a risky change.
Install / setup
/plugin install pagerduty@claude-plugins-official Source / docs
Why it belongs in ops: It helps when deploy history, incident timing, and escalation context should affect what you do next.
Terraform
Terraform ecosystem help without hand-rolling the MCP config.
Install / setup
/plugin install terraform@claude-plugins-official Source / docs
Why it belongs in ops: Ops teams spend real time in IaC, and Terraform-specific context is more useful than generic cloud advice.
AWS / Azure / Cloudflare
Platform-specific helpers for the cloud you actually run.
Install / setup
Pick aws-core, aws-serverless, azure, or cloudflare from @claude-plugins-official Source / docs
Why it belongs in ops: Choose the provider you operate every day; these are useful precisely because they are not generic cloud placeholders.
How to read these picks
For each server: what it does, when it earns its place in an ops workflow, and one setup line to get going. The setup lines use the claude mcp add pattern; adjust scope and the cmd /c wrapper per your platform.
The core pair: filesystem and GitHub
Filesystem is the one most people add first, and for good reason. It lets the agent read and edit files inside a directory you choose — configs, scripts, IaC, runbooks. For ops work that often means pointing it at a repo of Ansible playbooks or a folder of Compose files and letting the agent navigate and patch them.
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/ops-repoThe directory argument is the guardrail. Give it the project folder, not / or your home directory.
GitHub covers issues, pull requests, and repo browsing through the GitHub API. When your work lives in GitHub — triaging issues, drafting PR descriptions, checking what changed before a deploy — having the agent reach it directly removes a lot of copy-paste. Authenticate with a token scoped to the repos it needs and nothing more.
Filesystem vs GitHub
| Server | Best for |
|---|---|
| Filesystem | Editing local configs, scripts, IaC |
| GitHub | Issues, PRs, repo browsing |
Databases: Postgres and SQLite
When an incident comes down to “what’s actually in the table,” a database server pays off. The agent can run a query and reason about the result instead of you context-switching to a SQL client.
Postgres servers take a connection string and let the agent inspect schemas and run queries. SQLite servers point at a local database file — handy for the countless small tools and apps backed by a .db file. If you want one concrete server that covers both, DBHub is the practical pick because it supports Postgres, MySQL, MariaDB, SQL Server, and SQLite with a small tool surface.
npx @bytebase/dbhub@latest --transport http --host 127.0.0.1 --port 8080 --dsn "sqlite:///path/to/data.db"These are usually separate servers per engine. If you run both Postgres and SQLite, expect to add both.
Containers: Docker
For anyone managing containers, Docker’s own MCP Toolkit is the path to check first. It is built into Docker Desktop 4.62 and later, lets you browse MCP servers from Docker’s catalog, runs them as containers, groups them into profiles, and connects those profiles to clients. That is more maintainable than pasting a random Docker-socket MCP server into every project.
The ops value is concrete: “show me the logs for the container that keeps restarting” is a question the agent can answer directly when the right server is connected. That same access is why you should be deliberate about granting it — anything that can inspect containers may also be able to affect real runtime state, depending on the tools you enable.
Web and monitoring: fetch, Sentry, Playwright
Fetch servers let the agent retrieve a URL and read the content — useful for pulling a status page, an API response, or vendor docs into the conversation without leaving the terminal. It’s read-only by nature, which makes it one of the lower-risk additions.
Sentry servers connect the agent to error-tracking data, so it can look at an issue, the stack trace, and surrounding events while you’re working a fix. When the agent can read the actual exception instead of your paraphrase of it, the debugging conversation gets a lot sharper.
/plugin install sentry@claude-plugins-official
/reload-pluginsPlaywright servers drive a real browser. For ops that’s less about test-writing and more about checking that a deployed service actually loads, walking a login flow, or grabbing what a page returns after JavaScript runs. It’s heavier than a fetch server — a full browser — so add it when you genuinely need rendered pages.
/plugin install playwright@claude-plugins-official
/reload-pluginsA sensible starter set for ops
- Filesystem — pointed at your ops repo, not your home folder.
- GitHub — token scoped to the repos you work in.
- A database server — read-only, non-prod target.
- Fetch — low-risk way to pull web content in.
- Add Docker, Sentry, or Playwright only when a workflow needs them.
Be honest about maturity
It’s worth repeating: a lot of MCP servers are not production-grade. Before you build a habit around one, check a few things — when it was last updated, whether it’s an official project or one person’s side project, how it handles credentials, and whether the issues list is full of unanswered breakage reports. An abandoned server that worked last month can quietly stop working after a dependency bumps.
The reliable core — filesystem, GitHub, a database server, fetch — is mature enough to lean on. The long tail is where you should stay skeptical. There’s no shame in deciding a given server isn’t worth the operational risk and doing the task by hand.
Wrapping up
For ops work, start with filesystem and GitHub, add a read-only database server for incident digging, and keep fetch around for pulling in web content. Layer Docker, Sentry, and Playwright on top only when a specific workflow demands them, and scope every server’s access before you trust it.
For the general-purpose picks beyond ops, see the best MCP servers for Claude Code roundup, and if you’re setting up Claude Code on a server or admin box, the Claude Code setup for sysadmins guide covers the environment side.
