What is an MCP server,
and how does it work?

How an MCP server works

The clearest way to see the mechanism is to follow a single question through it. You ask your assistant something about your own environment. The assistant works out that it needs facts it doesn't have, picks a tool from the list the server published and calls it. The server runs that one action against the system behind it and returns the result. The assistant then turns the result into an answer.

Underneath, the messages are plain JSON-RPC 2.0. Two transports are defined: standard input and output for a server running locally on your own machine, and streamable HTTP for a remote server a vendor hosts. Enterprise vendors almost always run the remote kind, which is why there is usually nothing for your team to install.

The part worth holding on to is step three. The model never gets a connection to the system. It gets a menu. Everything it can do is something the server author decided to publish, and anything not on the menu is unavailable no matter how the question is phrased.

Three things an MCP server is not

Most of the confusion we hear in customer meetings comes from three assumptions, and all three are worth correcting before you evaluate anything.

1. It isn't an AI

An MCP server contains no language model. It doesn't reason, generate text or decide anything. A typical one is a few hundred lines of code that accepts a request, fetches something and returns it. If a vendor's MCP server gives you a well-written answer, the writing came from Claude or Copilot or ChatGPT. The facts came from the server.

2. It isn't a copy of your system

Connecting an MCP server doesn't hand a copy of anything to an AI vendor. The server is an interface, in the same way a portal or an API is an interface. Whether a particular server holds a store of its own is a design choice by whoever built it, so ask. The answer tells you where your information actually sits.

3. It isn't necessarily something you host

Teams used to running vendor software on their own servers often assume an MCP server works the same way and ask for installation documentation. For remote servers there usually isn't any. The vendor runs the server at their end, and your side of the work is authorizing the connection.

Why MCP servers matter now

Modern AI assistants are genuinely good at infrastructure. They can explain a migration pattern, weigh two architectures against each other or lay out what a compliance framework expects of you, and they do it well because that knowledge is written down in public. What they haven’t seen is your estate.

Ask one what happens if you change a particular firewall rule and you'll get a competent, well-structured answer about firewall rules. It won't be about your environment, because the assistant has never seen your environment. The gap between reasoning well in general and reasoning well about your estate is exactly the gap an MCP server closes.

That gap is now the main brake on agentic AI programs. Gartner® puts the scale of it plainly:

“By 2028, 99% of I&O-led investment in agentic AI without system data and operating model improvements will fail to achieve sustainable ROI.”

Gartner, Hype Cycle™ for I&O Automation, 2026, Chris Saunderson, 8 July 2026

Enterprise buyers have drawn the obvious conclusion, and an MCP interface has gone from novelty to baseline in about a year. Vendors without one are increasingly filtered out before a formal evaluation begins. That makes the interesting question no longer whether a vendor has an MCP server. Every serious one will. The question is what sits behind it.

The security questions worth asking

MCP was designed for interoperability and ease of adoption first. Security came later, and the public record of the past 18 months shows what that costs. Several categories of problem have shown up repeatedly, and they're worth understanding because they tell you which questions actually matter.

Prompt injection and tool poisoning

An assistant reads tool descriptions and returned content as instructions it can act on. In April 2025, Invariant Labs showed that instructions hidden in a tool's description are visible to the model and invisible to the user. A month later, researchers demonstrated the same class of attack against GitHub’s own MCP server, where a malicious public issue persuaded an agent to copy private repository contents into a public pull request. Anything untrusted that reaches the assistant is a potential instruction.

Supply chain

Thousands of community MCP servers are a package install away, and some of them are hostile. In July 2025 JFrog disclosed CVE-2025-6514 in the widely used mcp-remote package, rated critical, which allowed a malicious server to run arbitrary commands on the connecting machine. In September 2025 a package impersonating a well-known email provider’s MCP server was found copying every processed message to an attacker's address.

Write access and blast radius

Many MCP servers let an assistant act, not only read. A website builder's server can publish a page. A ticketing server can close a ticket. That's useful, and it also means a successful injection attack doesn't just leak information, it does something. The narrower the published tool set, the smaller the consequence of everything above.

Tenant isolation

If a vendor runs one shared MCP server across all its customers, the separation between your information and someone else's is code. In June 2025 Asana disclosed a flaw in its MCP server that could expose one organization's projects, teams and tasks to another. The architecture question to ask is whether a server instance is dedicated to you, or shared and filtered.

Knowing who asked

Most MCP servers today see an authenticated request from an AI assistant rather than from an individual person, because connections are usually authorized once at team or organization level. That means the record of which person asked what generally lives with your AI vendor rather than with the system being queried.

Gartner's recommendation to I&O leaders on this is specific:

“Establish contextual data perimeters: Implement a governed enterprise context layer to authenticate data provenance, prevent memory poisoning and secure all Model Context Protocol connections.”

Gartner, The Agentic AI Governance Framework for Infrastructure and IT Operations, George Spafford, Chris Saunderson, Ted Ernst, Cameron Haight, Roger Williams, Ashish Banerjee, Daniel Betts, Joe Antelmi, Mark Margevicius, 20 May 2026

Reduced to practice, that's five questions you can put to any vendor offering you an MCP server.

Code connectors and intent-based servers

Here's where MCP servers stop being interchangeable. Almost all of them are code connectors. They expose the actions a system can perform, and leave it to you and the assistant to work out which actions to combine and in what order. For a website builder that's exactly right, because creating a heading is a simple, self-contained thing.

Infrastructure questions aren't like that. “Plan our exit from this data center” isn't one action. It's a sequence of judgments about what to look at first, what usually goes wrong, what has to move together and what order makes the plan survive contact with reality. A code connector hands all of that back to you, so you supply it in the prompt. Which is why the quality of the output tracks the experience of whoever wrote the prompt.

An intent-based server moves that knowledge to the other side of the connection. Alongside the schema, it publishes what the vendor knows about the problem itself: why organizations take it on, what typically gets in the way, which views to start from and how to sequence the result. Assistants are extremely good at matching a question to written knowledge like that. They just have to be given some.

The expertise either travels with the facts, or it has to be supplied by whoever happens to be typing.

What makes the Mugato MCP server different

Every change to your IT, planned or not, depends on knowing what you have and how it’s connected. Mugato observes how your IT actually runs and keeps the full history, so you can see what a change will touch before you make it. It groups servers automatically into the application services teams plan around, without installing anything on a single endpoint. The MCP server is how an AI assistant reaches it, and it’s available to every Mugato customer. The portal was never meant to be the only way in. The same meta-information already flows into ServiceNow, your EA tools and your own analytics stack, and the MCP server adds asking in plain language to that list. Provisioning is a request to your Customer Success contact and takes minutes.

It's intent-trained, not just connected

Mugato's server publishes its full schema, so the assistant understands every relevant field and data type. It also publishes the domain knowledge behind each infrastructure use case, written by people who have run these projects. For a data center exit that means the reasons organizations do it, the obstacles that recur, the views to begin with and the order the output should follow.

The difference is measurable. A code connector leaves the method to whoever writes the prompt, and for a job this size that is a lot of prompt: producing a full data center exit deliverable from the raw schema took one of our solution engineers three to four densely written pages. Against the intent-trained server, a single line returned an executive summary, a baseline, a wave sequence with per-wave commentary, cross-wave coupling warnings, target platform resizing with quantified reduction, a remediation backlog, a runbook and a decision list.

Whatever you ask, the server works straight from the schema, so a question outside the trained use cases still comes back with a real answer about your own environment. The trained ones add the sequencing on top, and we’re adding more of them continuously, based on how customers are actually using Mugato. Every answer draws on your model, so the further along your application service naming and environment tagging are, the more a single line can do.

It reads and never writes

The Mugato MCP server exposes meta-information for reading only. It never changes a configuration, runs a command or takes an action on your behalf. That's a design decision rather than a gap waiting to be filled. Mugato's job is to report accurately on what's really running. Deciding what to change, and making the change, stays with you and the platforms that manage it.

It also removes an entire category of risk. A read-only server has no action for an injection attack to trigger.

One server per environment, with nothing shared

Every Mugato customer runs a dedicated, fully isolated Azure backend. The MCP server runs inside it, reading the same views that power your portal and your SQL access. There's no shared service in the data path, so cross-customer exposure isn't a bug we're guarding against. It's an architecture we don't have.

If your organization keeps environments segregated and runs separate Mugato installations as a result, each one gets its own MCP server, and those servers can't talk to each other. For a view across them you connect several to the same assistant and the assistant does the combining, which keeps the cross-environment step on your side of the line.

There's no language model anywhere in it

Mugato uses machine learning in its behavioral analytics engine to build dependency maps. There's no large language model in the platform, and none in the MCP server. The server fetches facts. Your assistant does the reasoning and the writing.

One consequence is worth seeing in a demonstration. Asked once for vendor uptime figures, the server answered that Mugato holds no availability data, offered what it could derive instead and proceeded only once it was told the outage history could come from the assistant's own knowledge. A system that refuses to invent is more convincing than any assurance we could write here.

The quality of the answer is the quality of what's underneath

An MCP server can only return what the system behind it holds, which makes the interesting comparison the information rather than the protocol. Infrastructure records tend to sit in three layers.

Mugato's meta-information is measured rather than declared, continuously current rather than periodically refreshed, process-level rather than inventory-level, and it's temporal, so every answer can draw on everything observed since deployment. It's collected continuously, synchronized every 30 minutes, with a full inventory daily. The behavioral analytics engine reaches 97% confidence in its service boundaries after roughly two weeks, and flags the remainder for human verification rather than guessing.

That last property is the one that compounds. Ask the same question six months apart and the second answer is better, because there's more history behind it.

If you want to see what this looks like against a live environment, the Mugato MCP server capability page walks through the questions it answers, and there's a worked NIS2 audit you can click through. For the architecture and security detail your review board will want, the technical FAQ covers hosting, isolation, identity and logging in full.

Frequently asked questions about MCP servers

What does MCP stand for?

MCP stands for Model Context Protocol. It's an open standard that defines how AI assistants connect to external systems and tools. Anthropic published it in November 2024 and donated it to the Agentic AI Foundation under the Linux Foundation in December 2025.

What does an MCP server actually do?

It publishes a list of named actions, called tools, that an AI assistant can call. When your question needs information the assistant doesn't have, it calls one of those tools. The server runs that single action against the system behind it and returns the result, and the assistant turns the result into an answer.

Is an MCP server an AI?

No. An MCP server contains no language model. It doesn't reason, generate text or make decisions. It accepts a request, fetches something and returns it. The reasoning and the writing come from the AI assistant you already use.

Does connecting an MCP server give an AI vendor a copy of our information?

Connecting the server doesn't copy anything by itself. The server is an interface into an existing system, like a portal or an API. What travels to your AI vendor is the content of the answers your assistant receives, which is why read-only access and narrow tools matter. Whether the server keeps a store of its own depends on how it was built, so ask.

Do we need to install or host an MCP server ourselves?

It depends on the vendor. Local servers run on your own machine over standard input and output. Remote servers are hosted at the vendor's end and reached over HTTP, and for those there's nothing to install. Most enterprise vendors, Mugato included, run the remote kind, so your side of the work is authorizing the connection in your AI assistant.

Are MCP servers secure?

The protocol was built for interoperability first, and the public record includes prompt injection, tool poisoning, malicious packages and at least one cross-customer exposure. Security depends almost entirely on how a particular server is built. The questions that separate a safe one from a risky one are whether it can write or only read, whether your instance is dedicated or shared, whether it keeps a copy of anything, how identity is handled and whether there's a model inside it.

What is an intent-based MCP server?

Most MCP servers are code connectors that expose a schema and a set of actions, leaving the method to whoever writes the prompt. An intent-based server also publishes the domain knowledge behind each use case: why organizations take the problem on, what usually gets in the way, which views to start from and how to sequence the output. Because that knowledge travels with the facts, a one-line question can produce the kind of answer that would otherwise need pages of prompt engineering.

Can an MCP server change our infrastructure?

Only if its tools allow it. Many MCP servers do publish write actions, and those make an injection attack far more consequential. The Mugato MCP server is read-only by design. It exposes meta-information for reading and never changes a configuration, runs a command or takes an action on your behalf.

Which AI assistants work with an MCP server?

Any MCP-compatible assistant, including Claude, Microsoft Copilot, ChatGPT and Gemini, plus custom agents and workflows built on the open standard. That's the point of a shared protocol. A server built once works across all of them without a separate integration for each.

Is the Mugato MCP server available?

Yes. The Mugato MCP server is generally available to Mugato customers. It runs inside your own dedicated Mugato Azure backend, so there’s nothing to install and no new path into your network. Ask your Customer Success contact to provision it, which takes minutes. Each entity you want reachable has to be enabled, so name them when you ask.

Will using an MCP server increase our AI token costs?

For the Mugato MCP server we expect the opposite, though the exact effect depends on the use case. Without it, your assistant has to be fed large amounts of low-level material such as spreadsheets and exports, and do the processing itself. The Mugato MCP server returns meta-information that's already enriched, so there's considerably less for the assistant to work through before it can answer.