UI, API and Now MCP: A New Way to Interact with Your GPU Cloud

We've been talking to software the same two ways for decades and we've gotten so used to it that we've stopped questioning whether those are the only two ways.

You either use a UI by clicking through menus, navigating dashboards or finding what you need by looking for it. Or you use an API by reading the documentation, structuring requests and writing the code that talks to the system on your behalf. That's it. That's been the whole menu.

Model Context Protocol or MCP is starting to open up a third option. And it's worth understanding what it actually is and why you should use it.

The Two Ways We've Always Done This

Think about the last time you onboarded onto a new cloud service. You probably started with the UI. You clicked around, got a feel for where things live and figured out what the service could do. The UI was designed for exactly that as it assumes you don't know what you're looking for yet and it tries to show you.

Then, if you needed to automate something at some point. You went to the API docs and found the right endpoints, figured out the authentication, wrote some code, tested it and fixed it. And once you had that working, it was great. We can say repeatable, scriptable and fast.

The Cost Nobody Talks About

Both of the above models work. They've powered everything we've built for the past years. But both also come with a cost that you've probably just absorbed without naming it. 

User Interface (UI)

With the UI, friction is often quiet. It is the feature you know exists but cannot find because it is buried under a menu you have not opened in months. This could be the moment you are staring at a dashboard trying to remember whether billing is under "Account" or "Settings" or somewhere else entirely. It is realising you need to already know roughly where something is before you can navigate to it. In GPU infrastructure, it is important to know where you're managing VMs, volumes, clusters, billing and utilisation across regions or this adds up to a lot of time spent just finding things.

Application Programming Interface (API)

With APIs, the friction is more visible. Before you can do anything useful, you need to read the documentation. Understand the auth model. Know the right endpoint. Structure a valid request. For services you use every day, this is second nature. But any time you touch something unfamiliar such as a new region, a new feature or a service a teammate set up, you have to do research again before you can actually operate it.

None of this is a design flaw. But just the inherent shape of each model. UIs optimise for discoverability. APIs optimise for precision. You pay for each in its own way.

What I would call it is an interface tax. You pay with the time between wanting to do something and actually being able to do it. And it compounds every time your infrastructure grows.

So What Would a Third Way Even Look Like?

Now here is the question MCP is trying to answer: what if you could just describe what you want and the system figured out how to do it?

Not in a vague way but in a concrete and operational way. This is where the intent you express gets translated into a real, validated action against real infrastructure.

That is the idea behind natural language as an interface. You do not need to navigate to the answer. You ask for it. You don't look up which endpoint lists your unattached volumes. You say, "Which of my volumes aren't attached to anything?" and you get the answer.

However, it is important to know that MCP is not replacing the UI or the API. Those are not going away and they should not. What MCP adds is a third mode of interaction for the moments that sit between automation: the ad-hoc queries, investigations and contextual decisions you make when something unexpected happens and you need to understand what is going on fast.

What This Looks Like for Cloud GPU Infrastructure

Say you are trying to do a cost hygiene check before your billing cycle closes. You want to find GPU instances that are not pulling their weight.

• Through a dashboard, that will be a multi-step process: navigate to the right panel, filter by utilisation, cross-reference across projects and maybe export something.

• Through an API, it is a script you probably have not written yet. Through MCP, you ask: "Show me underutilised GPU instances across projects."

With MCP

For instance, you need to spin up a new VM in the same region as one you launched a few weeks ago, but you cannot remember which region that was. Normally, you would open the VM list, find the old VM, note the region and then go back to VM creation and fill it in. With MCP: "Spin up an H100 in the same region as my last VM." The system handles the context lookup.

Or you want to replicate a staging environment for a new workload, just with more GPU capacity. Instead of pulling up the staging config, reading through it and manually reconstructing those parameters in a creation flow: "Create a new VM with the same configuration as staging but double the GPU count."

"Wait, Isn't This Just a Chatbot?"

It is a fair question and worth addressing because the doubt is legitimate.

LLMs hallucinate. It is just what they do when they do not have a grounded execution layer. They generate plausible responses. Sometimes those responses include API calls that don't exist, give wrong parameters or actions that sound right but are not. Connecting something like that to production infrastructure would be a bad idea.

MCP is not that.

The difference is in the architecture. With a general-purpose chatbot, the model generates output including any actions it decides to take based on what seems likely. There is no validation. No defined tool surface. No contract between the model's output and what the system will actually accept.

With MCP, the tools are explicitly defined. Inputs are validated before anything executes. Every action maps to a specific backend operation. The model is not inventing API calls but selecting from a known set of capabilities with known parameters. The execution is predictable.

So the surface is natural language. But below that is a structured, validated and grounded way of working. That is the difference that matters if you want to run this against the infrastructure you care about.

The Shift from Learning Tools to Using Them

Every new cloud service you adopt, every new region you expand into and every new GPU configuration that becomes available, all of this adds to a growing surface of things your team needs to learn before they can use them.

What MCP starts to change is the relationship between learning an interface and using it. If the interface is natural language, you do not need to internalise the dashboard layout or the API schema to be productive. Because with MCP:

• A new team member can query the system state on day one.

• An engineer who mostly works on model training can get billing context without mastering the billing API.

• A team expanding to a new region can assess resource availability before they've learned where that information lives.

The GPU infrastructure does not change. The automation you have built does not change. What changes is how your teams interact with systems in the gaps. MCP is an interface for those moments and it does not ask you to learn it before you can use it.

Experimenting with Hyperstack MCP Server

To see this in practice, you need an MCP-compatible endpoint connected to real infrastructure. That is why we offer the Hyperstack MCP Server.

It provides an MCP-compatible interface that exposes infrastructure capabilities such as:

• Virtual machine management
• Storage volume operations
• Cluster visibility
• Billing insights
• Resource availability

The goal here is not to replace existing workflows overnight but to allow teams to experiment with conversational infrastructure in a structured environment.

Deploy Your MCP Server

The Hyperstack MCP (Model Context Protocol) Server connects MCP-compatible AI clients directly to Hyperstack infrastructure. It enables you to manage cloud resources through natural language by translating structured MCP tool calls into authenticated Hyperstack Infrahub API requests.

Instead of writing API calls manually, you can describe what you want and the MCP Server securely executes the corresponding infrastructure operations.

One-Line Deployment

You can spin up your MCP endpoint instantly with Docker and connect it directly to your infrastructure:

docker run -e HYPERSTACK_API_KEY=your_key -p 8080:8080 hyperstack/mcp-server

Talk to Your Infrastructure

With the MCP Server running, you can interact with your infrastructure using natural language. The server translates AI-generated MCP tool calls into secure Hyperstack API actions.

You can:

• Create and manage Virtual Machines
• Provision and scale Kubernetes clusters
• Create, attach and manage Volumes
• Retrieve billing and usage information
• Manage environments and resources
• Execute multi-step infrastructure workflows

Works with MCP-Compatible AI Clients

The Hyperstack MCP Server integrates seamlessly with MCP-enabled AI clients such as Open WebUI and Claude Desktop, allowing you to manage infrastructure through a conversational interface without switching between dashboards, CLI tools or API scripts.

AI Studio Integration

You can connect seamlessly with Hyperstack AI Studio to bring infrastructure and inference into one intelligent workflow.

Not using AI Studio yet? Explore Hyperstack AI Studio and bring inference directly into your workflow.

FAQs