We’ve been automating infrastructure for a long time. We moved from scripts to APIs, Infrastructure as Code, and increasingly sophisticated automation platforms. Infrastructure has become much more programmable, but that doesn’t necessarily mean it has become simple.
To automate a system, you still need to understand how it works: which APIs to call, which objects to configure, their dependencies, and the required parameters.
Think about a user asking:
“Create a development environment for my application with the compute, storage, and connectivity it needs.”
The requested outcome is clear. But turning it into actual configuration is not. Someone, or something, still needs to determine which resources to create, how they should be configured, and how they fit together.
Traditionally, that translation has required someone who understands both what the user wants and how the underlying system needs to be configured.
This is where the Model Context Protocol (MCP) becomes interesting.
From intent to configuration
MCP provides a standard way for AI applications to interact with external systems and tools. An MCP server exposes capabilities that an AI application can discover and invoke.
At a high level, the interaction looks like this:
Of course, we already have APIs and automation frameworks for interacting with systems. MCP doesn’t replace them.
The difference is where the interaction starts. With traditional automation, we typically start from the system:
Which API should I call?
Which object should I create?
Which parameters should I provide?
With an AI-assisted interaction, we can start from the other direction:
What do I want to achieve?
The AI application can then use the capabilities exposed by the MCP server to translate that request into concrete operations.
Let’s go back to our development environment. The original request may not include everything needed to create it. The system might need to know where the application should run, what resources it requires, which existing resources should be reused, or other details.
Instead of requiring the user to first understand the underlying configuration model, the interaction can look more like:
The exact flow depends on the MCP server implementation. MCP provides the interface between the AI application and the external system. The MCP server determines which capabilities are exposed and what product-specific logic and controls sit behind them.
This is an important distinction. The value is not simply being able to use natural language instead of an API. The user no longer necessarily needs to start with the API or the product’s configuration model.
APIs aren’t going away
MCP isn’t a replacement for REST APIs, CLI interfaces, Infrastructure as Code, or existing automation frameworks.
In many cases, these will continue to do the actual work behind the scenes. MCP adds another way for AI applications to interact with the capabilities they expose.
One way to look at the evolution is:
GUI: Show me how to configure it.
CLI: Let me specify the configuration.
API: Let my software specify the configuration.
AI + MCP: Let me describe what I want to achieve.
The last model is particularly interesting for systems with complex or product-specific configuration models. For many infrastructure products, the challenge is no longer whether they can be automated. They already provide APIs and other automation interfaces. The challenge is knowing what to automate and how to translate the desired outcome into the right configuration. An MCP server can help bridge that gap.
The expertise doesn’t disappear
Product and infrastructure expertise is still required. The difference is where that expertise can reside.
Instead of requiring every user to understand every product-specific object and operation, some of that knowledge can be built into the tools, workflows, and logic exposed through the MCP server.
The same applies to operational controls. Authentication, authorization, validation, change control, and auditability remain important when an AI application has access to infrastructure operations. How these are implemented depends on the MCP server and the systems behind it.
The goal is therefore not to hand infrastructure control over to AI. It is to make infrastructure capabilities easier to consume while keeping the controls needed to operate them.
What does this mean for network infrastructure?
Network and application delivery infrastructure is a good example of where this model becomes particularly useful.
Consider an application owner asking:
“Expose my new application over HTTPS using these backend servers.”
From the application owner’s perspective, the requirement is straightforward.
From the infrastructure perspective, it may translate into multiple configuration elements: an application IP and port, backend servers, load-balancing behavior, health monitoring, TLS configuration, traffic policies, and possibly security services.
These elements don’t necessarily exist independently. There may be dependencies between them, existing configuration that should be reused, and product-specific rules about how they are created and connected.
The application owner understands what the application needs.
The ADC understands how to deliver it.
The challenge is translating between the two.
This is where an MCP server can provide a useful bridge. Instead of requiring the user to start with:
“Which ADC objects do I need to configure?”
the interaction can start with:
“What does my application need?”
That shift from configuration objects toward intent can make sophisticated network services easier to consume and automate, without hiding the fact that there is still a structured infrastructure configuration behind them.
In Part 2, we’ll look at how we applied this concept to Alteon MCP Server: where the product knowledge needed to translate application intent into supported Alteon configuration resides, and how the user stays in control of the actual change.