MCP Servers for DevOps: Giving AI Agents Live Infrastructure Context

The Model Context Protocol is a specification for how an AI client and an external system describe and exchange capabilities. A server advertises a list of tools, each with a name, a description, and a JSON Schema for its inputs. A client reads that list, decides which tool answers the question in front of it, calls it with structured arguments, and receives a structured result. The transport is JSON-RPC 2.0, either over stdio to a local process or over HTTP to a remote one.

Strip away the framing and MCP is a convention for tool discovery, not a new kind of computing. Its value is that the convention is shared: before it, every assistant had its own plugin format, so integrating one system with four assistants meant four integrations. That is the entire problem it solves, and it is worth being precise about it, because a protocol that is oversold gets adopted for workflows it does not improve and then blamed when it does not.

This guide covers what changes for an operations team specifically: which workflows get better, which do not, how local and remote servers differ in ways that matter for a security review, and what to check before you let an agent call a server you did not write.

An assistant without tools is working from a frozen snapshot of the world. That is fine for questions whose answers are stable and actively harmful for questions whose answers change by the minute. Infrastructure state is the second kind. Whether a region is degraded, whether a deploy succeeded, whether an incident is open: none of these are knowable from training data, and all of them are things a model will happily produce a confident sentence about.

The failure mode is specific, and it is not the one people expect. A model asked about live state does not usually say it cannot know. It reaches for the closest thing in its weights, which is a plausible general statement about that vendor, and delivers it in the same register as a fact it is certain about. There is no formatting cue separating the two. During an incident, where the entire job is deciding whether the fault is yours, a confident wrong attribution costs more than silence.

Tools change the epistemics, not the interface. The model is no longer where the answer comes from; it only has to pick the right question and read what comes back. Picking questions is work it is genuinely good at, which is why a tool call beats a longer prompt: you cannot prompt your way into knowledge the weights do not contain.

Not every operations task gets better with an agent in it. The honest pattern is that MCP helps most where the work is reading scattered state and correlating it, and helps least where the work is judgement or consequence. The table below reflects where the improvement is real rather than where a demo looks good.

MCP servers come in two shapes, and the distinction gets flattened in most introductions in a way that matters once you are reviewing one.

A local server is a process your client launches on your machine, speaking over stdio. It runs with your user's privileges and can read your filesystem, your environment variables, and your network. Its credentials are whatever you put in its config. The security question for a local server is supply chain: you are executing someone else's code on your laptop with your permissions, and calling it an MCP server does not change that.

A remote server is an HTTP endpoint somebody else operates. Nothing executes locally. The questions are different ones: what does it do with what you send, how does it authenticate you, what can the token it issues reach, and how do you withdraw access later. These are ordinary third-party-API questions with a familiar answer shape, which is why remote servers are usually the easier review even though they sound scarier.

Transport tracks that split. Local servers use stdio. Remote servers use Streamable HTTP, which is JSON-RPC over POST and is what replaced the older HTTP-plus-SSE pairing. A client restricted to stdio can still reach a remote server through a local bridge process, which is the standard workaround and is how CLI tools that only launch commands end up connected to remote services.

Connecting an MCP server is granting an agent a capability, and the review should look like a dependency review, closer to vetting a library than to installing a browser extension. Six questions cover most of it.

First, what can the tools reach? Read the tool list, not the landing page. A server whose tools are all reads of public data is a categorically smaller decision than one with a tool that can modify state, and the tool schemas say which it is in a way marketing copy does not.

Second, how does it authenticate? For a remote server, the good answer in 2026 is OAuth with a short-lived token and an explicit consent screen. A server that asks you to paste a long-lived key into a config file is asking you to manage a secret whose copies you will lose track of. None of that disqualifies a server, but it is a real ongoing cost and it should be priced in.

Third, what is the token bound to? A token valid only for one resource is useless if it leaks. A token that is a general-purpose credential for your whole account with that vendor is a much larger blast radius for the same convenience.

Fourth, how do you disconnect? There should be a visible list of connected clients and a way to revoke one without rotating anything else. If the only answer is to delete the config file, then anybody who already copied it retains access.

Fifth, what are the rate limits, and are they per-account or per-address? Agents retry. A limiter keyed on address means every engineer behind one office NAT shares a budget, which produces failures that look random and are hard to attribute.

Sixth, does the response say what it does not know? Most reviews skip this, and for status data it may be the most important question on the list. A server that returns a confident "operational" for a vendor it could not actually reach is worse than one that says the signal is only a reachability check with no published component detail behind it. Ask for a case where the data is thin and look at what comes back.

Vendor status is the cleanest example of the pattern because it has every property that makes a tool worthwhile: the data changes constantly, it is genuinely unknowable from training data, it is scattered across hundreds of inconsistent sources, and the cost of a confident wrong answer is high.

PulsAPI publishes a remote MCP server for exactly this, with five read-only tools covering the vendor list, one vendor's current status, its component and region breakdown, open incidents, and uptime over a window. It connects with a URL and an OAuth sign-in instead of a pasted key. The full write-up is the PulsAPI MCP server announcement, and the specification details are in the OAuth build log.

The general lesson transfers even if you use something else. Pick the workflows where the bottleneck is gathering scattered live state, connect a read-only tool for those, and keep the judgement and the writes with a person. The teams that get value out of agents in operations are not the ones that gave them the most access. They are the ones that gave them the freshest inputs.

Is MCP the same as function calling? Not quite. Function calling is a model capability, the ability to emit a structured call. MCP is a protocol for how tools are discovered, described, and invoked across a client and server boundary. MCP servers are typically consumed through function calling, but the point of the protocol is that the same server works with any compliant client instead of being rewritten per assistant.

Do I need a separate server per vendor? No, and that is the wrong unit. An MCP server exposes a capability, and one server can cover many underlying systems. A status aggregator exposes one server covering thousands of vendors, because the tool is "read vendor status", not "read this vendor".

Should an agent be allowed to trigger remediation? Not without a person in the loop, and the reason is structural, not a question of maturity. An agent acts on inferred intent, so the failure mode is a confident action taken for a plausible but wrong reason. That is tolerable for a read, where a person sees the answer before acting, and not tolerable for a write that has already landed in production.

How do remote MCP servers handle authentication? The current pattern is OAuth 2.1: an unauthenticated call returns 401 with a header pointing at the server's metadata, the client registers itself dynamically, and the user approves a scope on a consent screen. Nothing is pasted and nothing long-lived is stored on disk. The mechanics are covered in what OAuth 2.1 actually requires.

What does this change about monitoring strategy? Very little, and that is the honest answer. An MCP server is a new way to read signals you should already be collecting. If your vendor coverage is thin or your alert routing is noisy, connecting an agent surfaces those problems faster without fixing either. The underlying work is unchanged: know your dependencies, watch the components you actually use, and keep your own measurements alongside vendor claims. That is the argument in the third-party observability gap.