Understanding MCP
The Model Context Protocol is an open standard for connecting AI assistants to the systems where your work actually lives. It defines how an AI client discovers what a system can do, calls into it, and reads back results — in a form the model can reason about rather than one a human has to translate.
InfraScout is an MCP server. That single fact explains most of how the product behaves: why you connect Claude to it instead of learning a query language, why the tool list changes depending on who you are, and why assessments read like a conversation rather than a script.
InfraScout is also an MCP client, which is the less obvious half. The protocol is not only how you reach InfraScout — it is how InfraScout reaches everything else. Any system that speaks MCP can be brought into an assessment without anyone writing an integration for it, which is what turns a fixed tool set into an extension layer.
The Problem It Solves
Before MCP, wiring an AI model to a system meant writing a custom integration for each pairing: this model, that API, one adapter. Every new client needed its own adapter, and every new system multiplied the work again. The integrations were also fragile in a particular way — the model was handed a wall of API documentation and left to guess which endpoint answered the question in front of it.
MCP replaces that with a common protocol. A server describes its own capabilities in a machine-readable form, and any compliant client can consume that description without being written for this server specifically. Add InfraScout to Claude Desktop and to a completely different MCP client, and both discover the same tools by the same mechanism. Neither one contains a line of InfraScout-specific code.
The comparison people reach for is USB. What matters here is not the plug — it is that the device tells the host what it is, so the host does not need a per-device driver written in advance.
Clients, Servers, and Hosts
Three roles make up an MCP setup, and it is worth keeping them apart because they are easy to conflate.
The host is the application you are actually using — Claude Desktop, Claude Code, the InfraScout portal's own chat. It holds the conversation and decides what the model sees.
The client is the connection the host maintains to one server. A host running three servers holds three clients. This distinction matters mostly when you are reading protocol documentation; day to day, "client" and "host" get used interchangeably.
The server exposes capabilities. InfraScout is one, and it happens to be an unusually large one — most MCP servers wrap a single API, while InfraScout fronts an entire fleet of remote agents plus your Microsoft cloud tenant.
The model never talks to your agents or your tenant directly. It asks InfraScout, InfraScout does the work under your identity, and the result comes back through the same channel.
What a Server Exposes
MCP defines three kinds of capability, and InfraScout uses all three.
Tools are functions the model can call. Each one carries a name, a description written for the model rather than for a human, a schema describing its arguments, and annotations describing its behavior. agent_list returns connected agents; mscloud_security_list_ca_policies returns Conditional Access policies; agent_exec_powershell runs a script on a host. Tools are the bulk of InfraScout's surface — see the tool reference for the full catalog.
Resources are content the model can read: documents, records, structured data. InfraScout serves its assessment playbooks as resources, so the model can pull a structured review procedure into context on demand instead of being pre-loaded with all of them.
Prompts are reusable templates a user can invoke deliberately. Where a tool is something the model decides to call, a prompt is something you choose.
The important property of all three is that they are discovered, not configured. Your client asks the server what it has, and the server answers. When InfraScout adds a tool, connected clients pick it up without anyone editing a config file.
How a Tool Call Actually Works
A conversation that assesses a domain controller looks, from the protocol's side, like a short sequence of exchanges.
The client connects and asks for the tool list. InfraScout answers with the tools that caller is allowed to see — not the full catalog, a point covered in Tool Annotations and Role Scoping. The list arrives as structured descriptions, so the model reads what each tool does and what arguments it needs.
You ask your question. The model picks a tool, fills in its arguments from the schema, and the client sends the call. InfraScout authenticates it, checks it against your role and the resources you are allowed to see, dispatches the work to the right agent or cloud endpoint, and returns the result. The model reads the result, decides whether it answers the question, and either responds or calls another tool.
That loop repeats for as long as the work takes. Nothing about it is scripted — the model is choosing each step from a described set of capabilities, which is why an assessment can follow an unexpected finding instead of running to a fixed plan.
INFO
Tool descriptions are written for the model, and they are deliberately long. A description that explains when not to use a tool, or which tool to use instead, prevents more wasted calls than a short one ever saves.
Transport and Authentication
MCP servers reach clients over one of two transports. stdio runs the server as a local child process and talks to it over standard input and output — fine for a tool on your own machine, useless for a shared service. Streamable HTTP runs the server as a remote endpoint that many clients connect to over the network.
InfraScout uses streamable HTTP, because it is a shared service coordinating a fleet. That choice brings authentication with it: a remote endpoint has to know who is calling. InfraScout authenticates through Microsoft Entra ID using OAuth 2.0, so your client sends you through a normal browser sign-in and receives a short-lived token it refreshes on its own.
There is no API key. Every tool call runs as you, under the roles your organization assigned you, which is what makes the audit trail meaningful — a finding is attributable to a person, not to a shared credential. Connecting Your AI Client walks through the setup for Claude Code, Claude Desktop, and other clients.
Why This Matters for Assessments
MCP's design has two consequences that are easy to miss until you have run a few assessments.
Because tools are discovered rather than hard-coded, the AI works from a live description of what it can do right now — filtered to your role, your visibility grants, and the tool groups your administrators enabled. Two people asking the same question of the same server can legitimately receive different answers, because they were offered different tools. That is the intended behavior, not a quirk.
And because every capability is a discrete, named, annotated call rather than free-form access, each one can be gated and recorded individually. A tool that changes a host is distinguishable from one that reads it — by the protocol itself, before any InfraScout-specific logic runs. That distinction is what the role boundary is built on.
MCP Is Also the Extension Layer
Everything above describes InfraScout as an MCP server. It is equally an MCP client, and that is what makes the protocol InfraScout's extension mechanism rather than just its front door.
Administrators register third-party MCP servers, and the tools those servers publish join the catalog the AI reaches for during an assessment. There is no plugin API to learn, no adapter to write, and no waiting for InfraScout to build an integration. If a system speaks MCP — and increasingly they do, because vendors are shipping servers for their own products — it is one registration away from being part of your assessments.
This is how InfraScout's reach extends past what it ships with. Its own tools cover remote hosts and the Microsoft cloud. Your environment contains a great deal more than that: a ticketing system, a monitoring platform, a virtualization API, network and firewall appliances, a CMDB, whatever else your operations actually depend on. Each of those becomes assessable through the same conversation, under the same identity, recorded in the same audit trail.
What the extension actually buys you
The value is not that you gained one more tool list. It is that the AI can now correlate across systems that were never designed to talk to each other.
An unexpected service on a domain controller is a finding. That same service correlated with the change ticket that authorized it, the monitoring alert that fired at the same hour, and the virtual machine's snapshot history is an explanation. Reaching all four used to mean four consoles and a person holding the thread. Through MCP it is one assessment, because the model can follow the question wherever it leads instead of stopping at InfraScout's own boundary.
That widened reach is deliberate, and it is also why the boundaries around it are strict. A registered server's tools are held to exactly the same rules as InfraScout's own: they can be scoped to specific security groups, they respect the role tier of whoever is calling, and a tool that does not declare itself read-only stays behind the operator tier by default. Extending what InfraScout can reach never quietly extends who can reach it.
The MCP proxy: reaching systems that are not internet-facing
Most of the systems worth connecting are exactly the ones you would never expose to the internet. A vCenter API, a monitoring server, a ticketing system on an internal VLAN — InfraScout cannot reach any of them directly, and it should not be asked to.
The MCP proxy is how they come into scope anyway. An agent you already have deployed acts as the host: InfraScout sends the tool call to that agent over the same mutually authenticated channel every other command uses, the agent talks to the server from inside the network, and the result comes back the same way. The agent's existing outbound connection carries all of it. Nothing gets published, and no inbound firewall rule is created.
A proxy-enabled agent covers two shapes. It can run the server as a child process it launches and supervises — the ordinary way most MCP servers ship — or it can connect outward to a server already running elsewhere on that network. Either way the result is one registration in the portal, and its tools appear in a conversation indistinguishable from any other.
Three properties are worth understanding before you plan around it.
Hosting is off until someone turns it on, on the machine itself. Proxying means the agent launches processes or opens outbound connections, so enabling it is a decision made locally by an operator with access to that host, not remotely from the portal. An agent that has not been enabled cannot be nominated as a host, and an administrator cannot enable it from the portal on the operator's behalf.
Credentials never land on the host's disk. Environment variables and connection headers are stored encrypted, shown back to you only as masked hints, and pushed to the agent over the encrypted channel. A host that reboots comes back with no local record of what it was running, and InfraScout re-provisions it on reconnect — there is nothing to restore by hand and nothing to find on the disk.
A proxied server is still fully governed. Its tools are scoped to security groups, held to the caller's role tier, and recorded in the audit trail exactly like InfraScout's own. Reaching further into your network does not mean reaching around the boundaries.
Agent hosting requires a Linux agent today. Windows and macOS agents connect to InfraScout normally but do not advertise the capability. See MCP Servers (Admin) for enabling the proxy and registering a server through it, and the announcement post for the design reasoning.
Next Steps
Connect Your AI Client
Add the InfraScout endpoint to Claude Code, Claude Desktop, or any MCP client and sign in with your work account.
Tool Annotations and Roles
How annotations classify every tool, and how InfraScout turns that classification into an enforced role boundary.