Cloud infrastructure has become deeply programmable over the past decade.
Almost every platform exposes APIs that allow developers to build applications, provision databases, configure networking, and retrieve metrics.
This change enabled automation through code and CI/CD pipelines through infrastructure, allowing teams to manage systems through scripts rather than dashboards.
Now another layer of automation is emerging. AI agents are starting to directly participate in development workflows. These agents can read the codebase, execute, run terminal commands, and help debug systems. The next logical step is to allow them to communicate with the infrastructure.
Instead of manually inspecting dashboards or remembering complex command-line syntax, developers can ask an AI agent to check system health, deploy services, or retrieve metrics. The agent performs this task by interacting with cloud APIs on behalf of the user.
This capability opens the door to a new kind of workflow where infrastructure is interoperable, programmable, and deeply integrated into the development environment.
In this article, we’ll explore how AI agents can interact with cloud infrastructure through APIs, the challenges of exposing large APIs to AI systems, and how architectures like MCP make it possible for agents to securely discover and perform infrastructure operations. We’ll also see a practical example of connecting an AI agent to a cloud platform like Sevilla using a search-and-execute pattern.
Familiarity with cloud infrastructure concepts such as APIs, infrastructure as code, and effectively following CI/CD workflows is recommended. To fully understand the architectures discussed in this article you should also have a basic understanding of how AI agents or developer assistants interact with code and systems.
What we will cover
AI agents are becoming part of the development environment.
Modern developer tools increasingly embed AI assistants directly into the coding environment. Editors such as Cursor, Windsurf, and CloudCode allow developers to ask questions about their projects, generate new code, and execute commands without leaving the editor.
Instead of manually navigating documentation or writing boilerplate code, developers can simply specify what they want. AI interprets the request and takes necessary actions.
This approach is already common for tasks such as writing functions, refactoring code, or debugging errors. However, infrastructure management is still largely handled through dashboards, terminal commands, or external tooling.
If AI agents are going to effectively support developers, they need access to the same systems that developers interact with every day. This means accessing APIs that manage applications, databases, deployments, and other infrastructure resources.
The challenge is providing access to this in a systematic and scalable way.
Connecting AI agents to external systems
AI agents do not inherently know how to interact with external services. They need a framework that allows them to call tools and access data securely.
The Model Context Protocol, or MCP, provides one such framework. MCP is designed to allow AI assistants to connect to external tools in a standardized way.
An MCP server exposes tools that an AI agent can call when it needs information or wants to take action. These tools can retrieve data from databases, query logs, interact with APIs, or run commands on remote systems.
When the AI agent receives a request from the user, it determines which tool to call and executes that tool through the MCP server. The results are returned to the agent, which can then continue reasoning about the problem.
This architecture allows AI assistants to interact with complex systems while maintaining a clear boundary between the agent and the external environment.
The challenge of big cloud APIs
While MCP enables AI agents to connect to infrastructure systems, cloud platforms present an additional challenge.
Most cloud platforms expose large APIs with many endpoints. A common platform can include endpoints for managing applications, databases, storage, networking, domains, metrics, logs, and deployment pipelines.
If an MCP server exposes each endpoint as a separate tool, the number of tools can quickly grow into the hundreds.
This creates several problems. First, an AI agent must understand the purpose and parameters of each available tool before deciding which one to use. This increases the amount of context needed for the agent to function effectively.
Second, maintaining hundreds of tools becomes difficult for developers who build and maintain MCP servers.
Third, the system becomes rigid. Every time a new API endpoint is added, a new tool must also be created and documented.
For large APIs, this approach quickly becomes impractical.
A simplified model for API access
A different architecture solves this problem by dramatically reducing the number of tools the AI is exposed to.
Instead of providing a separate tool for each API endpoint, MCP Server exposes only two capabilities.
The first capability allows the agent to search for API details. It allows the agent to discover available endpoints, understand parameters, and inspect request or response schemes.
The second capability allows the agent to execute code that calls the API.
In this model, the AI agent dynamically generates the code needed to call the API. Because the agent can search the specification and write its own API calls, the MCP server does not need to define individual tools for each endpoint.
This pattern greatly reduces the complexity of integration while giving the agent full access to the underlying platform.
Why sandboxed code execution is important
Allowing AI agents to create and execute code raises important security considerations.
If the generated code runs without restrictions, it can potentially access sensitive parts of the system or perform unintended actions. To prevent this, the execution environment must be carefully controlled.
A common solution is running generated code inside a sandboxed environment. In this setup, code runs in an isolated runtime with limited permissions. Environments only expose specific functions that allow interaction with the platform’s API.
Since the code cannot directly access the host system, the risk of unintended behavior is greatly reduced. At the same time, the AI agent maintains the flexibility to generate custom API calls as needed.
This combination of dynamic code generation and sandboxed execution makes it possible for AI agents to securely interact with complex APIs.
Practical example with Sevalla
This architecture can be seen in practical implementation. Sevalla MCP Serverwhich exposes the cloud platform’s API to AI agents through search and action patterns.
Seoul is a PaaS provider designed for developers to deliver production applications. It offers app hosting, database, object storage, and static site hosting for your projects. We also have other options, such as AWS and Azure, that come with their own MCP tools.
Instead of registering hundreds of tools for each API endpoint, the server provides only two tools that allow the AI agent to explore and interact with the entire platform. Find out. Complete documentation Here for Sevalla’s MCP server.
The first device, searchallows the agent to query the platform’s OpenAPI specification. Through this interface the agent can discover available endpoints, understand parameters, and inspect response schemes.
Because the API specification is searchable, the agent does not need to know the structure of the platform’s API in advance. It can discover the API dynamically based on the task that needs to be performed.
For example, if a user asks an agent to list all the applications running in their account, the agent can start by looking up the API details.
const endpoints = await sevalla.search("list all applications")
The result returns the corresponding API definitions, including the correct path and parameters required by the request. Once the agent understands which endpoint to use, it can generate the necessary API calls.
second device, executeruns JavaScript within a sandboxed V8 environment. In this environment the agent can call the API using helper functions provided by the platform.
const apps = await sevalla.request({
method: "GET",
path: "/applications"
})
Because the code runs inside an isolated V8 sandbox, the generated script cannot access the host system. The only allowed interaction is through the API helper function. This ensures that the AI agent can safely perform infrastructure operations while maintaining the flexibility to generate dynamic API calls.
This approach allows an agent to explore and interact with many parts of the platform without requiring predefined tools for each capability. After discovering endpoints through the API specification, the agent can retrieve application data, inspect deployments, query metrics, or manage infrastructure resources through generated API calls.
The design also significantly reduces context usage. Traditional MCP integrations can require hundreds of tools to represent each endpoint of a large API. In contrast, the search and execution pattern allows access to the entire API level with just two tools.
For developers connecting AI assistants to infrastructure platforms, this architecture provides a practical way to expose large APIs while keeping integration simple and efficient.
What this means for developers.
Allowing AI agents to interact with infrastructure APIs changes the way developers manage systems.
Instead of manually navigating dashboards or writing long sequences of commands, developers can define what they want in natural language. The AI agent can interpret the request, discover the relevant API endpoints, and perform the required actions.
This approach also improves observation and debugging. When something goes wrong, the agent can query the log, inspect metrics, and recover the state of the system without requiring the developer to manually gather information.
Over time, this type of integration can significantly reduce the friction involved in managing complex cloud systems.
The next evolution of infrastructure automation
Infrastructure automation has evolved through several stages. Early cloud systems relied heavily on manual configuration via web interfaces. Code as infrastructure later allowed teams to define the infrastructure using scripts and configuration files.
CI/CD pipelines then automate the process of deploying and updating systems.
AI agents represent the next step in this development. By combining APIs, MCP integrations, and sandboxed execution environments, developers can allow intelligent systems to reason about and securely interact with the infrastructure.
Instead of static integration, agents can dynamically discover and call APIs as needed. This makes infrastructure management more flexible and accessible while maintaining the reliability of programmable systems.
As AI tools become more deeply embedded in development environments, the ability for agents to understand and control infrastructure will become a standard capability for modern platforms.
Hope you liked this article. Visit my blog. For more practical lessons.