DevOps guide

Best MCP Servers for DevOps & Infra (2026)

Coding agents are useful for DevOps the moment they can see beyond your repo, workflow runs, error trackers, incident channels, live dashboards. Here are the MCP servers worth wiring in, the pattern for the ones you should build yourself, and the least-privilege lines to hold.

By Kylian Migot · Updated July 2026 · 11 min read

Quick answer

For DevOps work, the MCP servers for DevOps that actually earn their slot are the ones that give the agent structured reach into the systems around your code: git and github for releases and workflow runs, sentry for live errors, slack for the incident room, fetch for status pages and provider APIs, puppeteer for dashboards without a JSON endpoint, plus filesystem and sequential-thinking as scaffolding. Everything else is best done with a scoped shell and explicit approval.
The DevOps shortlist
git · github · sentry · slack · fetch · puppeteer · filesystem · sequential-thinking
All from
Anthropic's reference MCP servers (github.com/modelcontextprotocol/servers)
Not on the list
kubectl / terraform / cloud APIs, wrap them in a scoped shell + approval gate instead
In AIDEN
Inherited from your local Claude Code config; nothing to reconfigure
01

What MCP Unlocks for a DevOps Agent

A coding agent that can only read your repo is a strong pair-programmer and a weak on-call teammate. The Model Context Protocol changes the range: each MCP server exposes typed tools the agent can call, so a single session can pull the last failing workflow run, cross-reference it with a Sentry error, post a status update in Slack, and open a fix PR, all without asking you to paste anything. For DevOps that reach is the entire point, and it is why the servers that matter here are different from the ones that matter for greenfield feature work.

The right lens is capability, not novelty. Ask what the agent still cannot see or do after reading the code, then close those gaps deliberately. Below is the shortlist we would install first on any project doing real infra and incident work, drawn entirely from Anthropic's reference MCP servers. They are maintained, well-scoped, and small enough to reason about.

02

The Shortlist

ServerWhat it gives the agentWhy it earns its slot for DevOps
gitLocal repo operations: log, diff, blame, branch, statusRoot-causing regressions: 'what changed on this file in the last week and by whom' without shelling out.
githubIssues, PRs, releases, workflow_runs, checks via the GitHub APIThe single highest-leverage DevOps server. Read the failing workflow_run, correlate to a commit, open the fix.
sentryQuery issues and events from Sentry projectsTurns 'errors are spiking' into a concrete list of stack traces the agent can group and open PRs against.
slackRead and post to Slack channels the bot is inPost structured incident-room updates, ack alerts, drop a link to the workflow_run, without leaving the agent.
fetchHTTP fetch of a URL, converted to readable textHit internal status pages and cloud-provider status APIs, read release notes, verify an endpoint returns 200.
puppeteerHeadless Chromium: navigate, screenshot, evaluate JSCheck dashboards and admin UIs that have no JSON endpoint; grab a chart or verify a graph rendered.
filesystemRead/write files under explicitly allowed directoriesScoped access to a runbooks folder, generated log bundles, or a scratch dir for incident artifacts.
sequential-thinkingA structured step-by-step reasoning toolNudges the agent to plan an incident response before acting, helpful when the failure mode is unclear.
03

Deep Dives on the Four That Matter Most

Of the shortlist, four servers do the majority of the work in an incident or a release. They are worth setting up carefully.

git + github

Treat these as a pair. The git server answers “what changed here and when” from the local repo; the github server answers everything remote, workflow_runs, check statuses, releases, and the issue and PR APIs. In practice you spend most of your DevOps agent budget in github: reading the failing workflow_run, listing recent releases, cross-referencing the commit range, and opening the fix PR back through the same server. Scope the token to the repos the agent actually needs.

sentry

For error tracking, the sentry server lets the agent list issues, drill into events, and pull the stack trace and breadcrumbs directly. That converts 'the dashboard shows a spike' into a concrete artifact the agent can hand to a fix task or attach to a Slack update. Scope the API token to the specific project(s), not the whole org.

slack

The slack server is what turns the agent from a silent worker into an incidentteammate: it can ack an alert, post a structured status update in the incident channel with links to the workflow_run and Sentry issue, and read your replies to gate its next step. Restrict the bot to specific channels; do not give it a workspace-wide token.

fetch

Do not underestimate fetch. Most cloud providers, status pages, and internal admin surfaces expose HTTP endpoints; a plain GET is often all you need to confirm 'is the region green' or 'did the deploy come up healthy.' Combined with the agent's own reasoning it replaces a lot of tab-switching during an incident.

Your AI workspace for shipping software.

Download AIDEN free and point it at your existing Claude Code or Codex setup. No credit card, running in minutes.

Download AIDEN free

Free to start · macOS 12+ · No credit card required

04

Responding to an Alert with an Agent

Concretely, here is how a well-equipped agent handles a PagerDuty page that fires because the 5xx rate on api-prod crossed the SLO. You start it with one sentence, the rest is servers doing their job:

  1. 1

    Acknowledge and set the room

    Using slack, the agent posts in #incidents: “Investigating 5xx spike on api-prod, will update in 5.” It threads every subsequent update on that message so the room has a single source of truth.
  2. 2

    Correlate deploys and workflow runs

    Via github, it lists the last few workflow_runs onapi-prod and the recent releases. If a deploy landed within the alert window, that is the prime suspect; it captures the commit range for the follow-up diff.
  3. 3

    Confirm the shape of the failure

    Through sentry, it lists new issues on the api-prod project in the last hour and groups them by error class. A single dominant issue (say a 500 in one handler) narrows the search; noisy spread suggests infrastructure, not code.
  4. 4

    Sanity-check external surfaces

    With fetch, it hits your provider's status page and your own/healthz from an out-of-band region. Green + isolated to prod = code or config; red = wait, not roll back.
  5. 5

    Diff and propose

    Via git + github, it diffs the suspect commit range against the last known-good release, drafts a rollback PR or a targeted fix PR, and links both in the Slack thread for your call.
  6. 6

    Stop at the mutation

    It does NOT run the rollback itself. Merging the PR, kicking the deploy, or paging others stays with a human. The agent's job in this pattern is to compress the first 10 minutes of investigation, not to own the outage.
05

What NOT to Expose (Least-Privilege Patterns)

The MCP layer moves capability toward the agent quickly, which means it moves risk quickly too. Two principles keep the blast radius small.

Scope credentials, not prompts

The agent effectively has whatever the server's token has. A GitHub token scoped to one repo cannot exfiltrate the rest of your org; a Slack bot in one channel cannot spam #general; a Sentry token limited to a project cannot see other teams' errors. Ask 'what would this token do if leaked?' before you install the server.

Read from prod, write to staging

For anything that mutates production, kubectl apply, terraform apply, aws s3 rm, do not wire it as a direct MCP tool. Wrap it in a shell command that requires an explicit approval step, or point the agent at a staging cluster/account and require a human to promote. Reads (kubectl get, terraform plan, aws s3 ls) are usually fine.

Prefer typed servers over shell scraping

When a maintained server exists (github, sentry, slack), use it: outputs are structured, error handling is predictable, and the surface is smaller than 'run any command.' Reserve the shell for the last-mile actions, gated on approval.

Log what the agent did

MCP calls should leave a trail: the workflow_run it read, the Sentry issues it fetched, the Slack message it posted. When an incident post-mortem asks 'what did the agent do', the answer should be a boring log, not archaeology.
06

Wire It Into Claude Code (and AIDEN)

All the servers above are the Anthropic reference implementations and install the same way. From your terminal, register them with Claude Code:

# Anthropic reference servers, added to Claude Code
claude mcp add git -- npx -y @modelcontextprotocol/server-git
claude mcp add github -- npx -y @modelcontextprotocol/server-github
claude mcp add sentry -- npx -y @modelcontextprotocol/server-sentry
claude mcp add slack -- npx -y @modelcontextprotocol/server-slack
claude mcp add fetch -- npx -y @modelcontextprotocol/server-fetch
claude mcp add puppeteer -- npx -y @modelcontextprotocol/server-puppeteer
claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

# Credentials live in the server's environment, not in the prompt:
# GITHUB_PERSONAL_ACCESS_TOKEN, SENTRY_AUTH_TOKEN, SLACK_BOT_TOKEN, etc.

Each server takes its credentials from environment variables, keep them in your shell profile or a secrets manager, not in the prompt. Once these are registered in ~/.claude.json (or a project's .mcp.json), every Claude Code session picks them up automatically, and every agent AIDEN launches inherits the exact same setup: AIDEN is a cockpit over your local coding-agent CLIs, so it uses your MCP config rather than a duplicate of it. BYO inference, BYO servers, BYO scopes.

Pair the servers with Claude skills that encode how your team responds, an incident-response skill that dictates the six steps above, a release-rollback skill that dictates the safe path. Capability from MCP, procedure from skills, both landing in the same window, gated by good context hygiene. That is the setup that makes a coding agent useful on-call instead of just useful in a feature branch.

FAQ

What is MCP, in one paragraph?
MCP (Model Context Protocol) is an open protocol from Anthropic that lets a coding agent talk to external tools and data sources through small local or remote servers. Each server exposes a set of tools the model can call, read a GitHub issue, list Sentry errors, post to a Slack channel, fetch a URL, so the agent can act on live systems instead of only reading the files in your repo. For DevOps work, that reach is the entire point.
Is it safe to give my agent kubectl?
Not by default, and rarely as broadly as it first looks. Give the agent a scoped kubeconfig pointed at a non-production cluster, or a read-only role in production, and treat any mutating command as something that needs a human approval step. The MCP layer does not solve authorization for you: whatever token the server uses is what the agent effectively has. Least-privilege belongs in the credentials, not in the prompt.
Does AIDEN preconfigure DevOps MCP servers for me?
AIDEN runs your local Claude Code and Codex rather than replacing them, so any MCP server you have configured, in ~/.claude.json via 'claude mcp add' or in a project's .mcp.json, is available to every agent AIDEN launches. It does not ship an opinionated DevOps bundle; it inherits the setup you already trust. That keeps credentials and scopes under your control instead of ours.
Do I need MCP if my agent already has shell?
Sometimes not. A coding agent with a shell can already run git, kubectl, curl, and gh. MCP earns its slot when the interaction is structured (issues, alerts, log queries) and you want typed tools with clean outputs instead of scraping stdout, or when the target has no CLI at all. For git and workflow_runs the GitHub MCP server beats parsing 'gh api' output; for shelling out to a script, plain bash is still fine.
MCP servers vs custom Claude skills for infra work?
They solve different problems and pair well. An MCP server gives the agent a new capability, list the last ten workflow_runs, open a Sentry issue, post to #incidents. A Claude skill gives the agent procedural knowledge, our incident response is: acknowledge in Slack, capture the failing workflow_run id, open a Sentry link, then post a one-paragraph summary. Capability plus procedure. See agent skills for the SKILL.md format.

Keep reading

MCP servers for AI coding

What MCP is, the servers worth installing, and how AIDEN inherits your setup.

Agent skills (SKILL.md)

Reusable procedural know-how the model loads on demand, and how it differs from MCP.

Agentic loops

The gather-decide-act-observe cycle coding agents run, and how to bound it.

Context engineering for coding agents

The craft of feeding agents the right context: files, specs, memory, and isolation.

Your MCP servers, on every incident.

AIDEN runs your local Claude Code, so every MCP server you've already scoped, GitHub, Sentry, Slack, and the rest, is available to every agent it launches. BYO inference. Free for one project.

Download AIDEN, freeSee pricing

macOS 12+ · Bring your own Claude Code or Codex · Your code stays local