What MCP Servers Add to an Assessment: Correlating Your Whole Operations Stack ​

September 28, 2026 · InfraScout Team

InfraScout's own tools reach two places: your hosts, through agents, and the Microsoft cloud. Your operations run on a great deal more than that. This post walks through the systems teams typically connect as external MCP servers, what a typical question to each looks like, and what changes when the AI can hold all of them in one conversation, under your identity, in one audit trail.

Two Ways In, One Conversation ​

Any system that speaks the Model Context Protocol can be registered as an MCP server. That can be an MCP server for the product in question, whether vendor-supplied, community-built, or your own. If the server is published on the internet, InfraScout connects to it directly. If it sits on an internal network, one of your agents hosts it from inside, so nothing gets published and no inbound firewall rule is needed.

Each registered system is useful on its own. The real value is correlation: a finding on a host, lined up against the ticket that requested it, the firewall rule that governs it and the monitoring check that flagged it, stops being an observation and becomes an explanation.

Ticketing and Wiki ​

Teams use this pairing the most, because it is where work arrives and where results need to end up. A typical request is to point the AI at a ticket: "read this and implement or verify it." The AI reads the requested change, such as a new firewall rule or SMBv1 being disabled, checks whether it is actually in place on the real hosts, and writes the result back as a ticket comment, a follow-up ticket, or a status transition. Scheduled health checks can publish each run's report as a new wiki page, with a time server supplying the run window so the page covers the right period.

InfraScout adds the part a ticketing system cannot do: going to the host and checking. Insights and memory keep that evidence after the conversation ends, so the next person working a related ticket starts from what was already proven. The ticket-to-verified-change walkthrough covers this loop in depth.

Virtualization ​

Teams mostly use the vCenter connection for reads: power state, VM details and events, alarms, snapshots, and datastore and disk usage. Typical questions are "is this VM actually running?", "which snapshots are older than a month?", and "which datastores are close to full?". For bulk jobs like checking VM hardware versions across a cluster, an agent with PowerCLI installed can run the job as a script.

What InfraScout adds is the view from inside the guest. The hypervisor knows a VM is powered on. The agent knows whether the service you care about is running, and why it stopped if it isn't.

Firewall Configuration ​

A connection to a firewall's live configuration answers the questions that usually mean a ticket to the network team. Is this admin port reachable from the internet, or only from inside? Which policies make up the effective rule set for these hosts? Why can't some hosts reach an endpoint on an outbound port when others can?

InfraScout adds the host side. The agent reports each host's local firewall and routing, so the AI can compare what the appliance allows with what the host actually does. Earlier insights on the same hosts show up alongside, and the results can be charted when a table gets too long to read.

Firewall Logs and SIEM ​

Configuration shows what should happen. Logs show what did happen, and that makes them the natural second step.

Firewall log analytics ​

A log analytics platform confirms what a policy change did to real traffic. Typical cases include an RDP session that lags only through one firewall path, or a package update that fails on a jump host. InfraScout puts host-side evidence, like event log entries, service state and local connection attempts, next to the log timeline so you can line the two up by the minute.

Fleet-wide sweeps ​

A SIEM is good at breadth. Once the AI has found the root cause on one host, and that finding gives you a signature, such as a specific installer error or a crash pattern, the SIEM can find every other host showing the same thing. InfraScout does the deep investigation on one host that produces the signature. The SIEM tells you how far the problem has spread.

Monitoring ​

Monitoring is one of the most heavily used connections, and it is a good example of splitting access by environment. Teams often connect production read-only and give write access only to a separate test instance.

The most useful question here is an intersection: list the hosts and services with open problems, then keep only the hosts that have an InfraScout agent. The result is a list of problems you can fix now, not just a list of problems. In one typical case, SNMP checks had shown as unknown for months on several Windows hosts. The AI compared a healthy reference host with the failing ones and found the Windows SNMP feature had never been installed. After confirmation it installed the feature, the checks turned green within minutes, and each host got an insight recording the fix.

Identity Governance and Privileged Access ​

With an identity governance platform, the connection is usually diagnostic. The AI reads the platform's database to explain why a sync, provisioning run or attestation behaved the way it did, then checks the affected accounts and hosts from the InfraScout side.

Privileged access management is where per-user identity matters most. A PAM system such as GrantFlow can be connected so that each call runs as the signed-in user, not as a shared service account. The PAM system applies that user's own rights and records that user in its own audit log. Eligibility changes return a preview first and only go through after a separate reply from the user.

Reference, Diagrams and Notifications ​

A few smaller servers do a lot of work in the background. Documentation servers such as Microsoft Learn and Context7 ground the AI's answers in current vendor documentation. A Mermaid diagram server turns a findings summary into a topology or dependency diagram. A time server gives scheduled runs a reliable "now". An SMS gateway can page on-call staff when a user asks for it.

Three Cross-System Stories ​

A memory problem that was an installer ​

Users blamed a host's memory pressure on security agents. The real cause, traced on the host, was a scheduled task deployed by group policy that kept relaunching an installer that crashed each time. After approval, the fix went in on the host. An administrator extended the virtual disk in vCenter and the AI grew the partition to match. Then a SIEM sweep for the same installer failure found it on other hosts. The root-causing walkthrough goes through the full method.

Sorting monitoring problems into "fixable now" and "not yet" ​

Faced with a long list of open monitoring problems, the AI split them into problems on agent-connected hosts, which could be investigated and fixed in the same conversation, and problems on hosts without an agent, which needed a different route. It also explained a check that looked like a duplicate: a passive freshness check that had been assigned deliberately, which made it something to leave alone rather than clean up.

Firewall, ticket and host ​

Some hosts could not reach an endpoint on an outbound port. The AI checked the firewall configuration, found an earlier insight about the same hosts, and pulled up the change ticket that had requested the rule. The rule existed. That left one question worth a person's time: whether the address group behind the rule actually covered every affected host.

The prompt that starts this kind of investigation can stay short:

text
Some hosts in the application tier cannot reach the vendor endpoint on its
outbound port. Check the firewall's effective policy for those hosts, find any
change ticket that requested a rule for this, and compare it with each host's
local firewall and routing. Look at earlier insights first. Do not change
anything; summarize where the path breaks and what you would propose.

Governance Stays Where It Was ​

Adding more systems doesn't widen who can reach them. Tools from external servers are scoped to security groups through tool groups and held to the caller's role tier. A tool that doesn't declare itself read-only stays behind the operator tier by default. One caveat is worth stating plainly: whether a tool is read-only is a claim the external server makes about itself, and an administrator's override is also a policy assertion — a writing tool that a server labels read-only can reach a read-only caller. So verify a third-party server's classifications yourself before you widen who can use it, rather than trusting the label. For agent-hosted servers, credentials never touch the host's disk.

Inside a conversation, the AI is set up to pause for your confirmation before a state change — a VM restart for a hardware upgrade, a paging file change, a Windows feature install, a partition resize — with read-only and write execution kept separate. That pause depends on the tool being correctly classified, which is the reason the point above matters. Questions before any fix give you the choice, and "document only" is always a valid answer. Content that comes back from memory or from any tool is treated as data, never as instructions. So a wiki page or ticket description cannot steer the AI into doing something you didn't ask for.

Start read-only

Connect each new system read-only first, and add write access only on a test instance or for the specific tools a workflow needs. Most of the value above comes from correlation, and correlation only needs reads.

Next Steps ​

MCP as the extension layer explains the model behind all of this. MCP Servers covers registration, agent hosting and the tool allowlist, and Per-User Identity for MCP Servers shows how to connect systems like PAM so each call runs as the person asking. Tool Groups is where you decide who gets which of them.