Automating Edge Orchestration using a MCP
Edge orchestration has always been a problem of scale and variety: hundreds or thousands of sites, heterogeneous hardware, intermittent connectivity, and applications that increasingly include AI models alongside traditional containers. Avassa was built to make that manageable through a declarative, API-first platform. The Model Context Protocol (MCP) adds a new way to work with that platform: instead of writing every specification and query by hand, developers and operators describe what they want to an AI assistant, which then uses the Avassa APIs to do the work.
This article looks at what that means in practice, where it helps, and what to consider before letting an AI agent work against your edge estate.
What is MCP?
MCP is an open standard for connecting AI assistants to external tools and data. An MCP server exposes a set of well-described tools, for example, “list sites” or “show application status”, and an MCP client such as Claude Code, Claude Desktop, or an IDE-based assistant discovers those tools and calls them on the user’s behalf. The model decides which tool to call based on the request; the server performs the actual operation against the underlying system and returns the result.
The practical difference is that the assistant stops working from whatever you paste into a chat and starts working from the live system. It can read current state, correlate information across several calls, and take actions, all within the permissions the server grants it.
Why MCP matters at the edge
Edge environments amplify two kinds of friction that MCP is well suited to reduce.
Operations perspective. Understanding the health of a fleet of sites, and troubleshooting when something goes wrong, means navigating a lot of state: site and host status, application health per site, alerts, and logs. At scale, the hard part is often finding and correlating the right information rather than fixing the issue itself. An MCP-connected assistant can gather that context across many sites and summarize it, turning a sequence of manual queries into a single question.
Development perspective. Building edge AI applications involves much more than the container image. Application specifications, deployment rules that target the right sites, configuration, secrets, and device or GPU access all have to line up, and iterating on that combination quickly is where teams lose time. With MCP, a developer can ask an assistant to draft or adjust the specifications, deploy to a test site, check the outcome, and iterate, all in the same session where they are writing the application code.
The avassa MCP server
Avassa’s MCP server connects MCP-capable AI assistants to the Avassa Control Tower. Through it, an assistant can work with the core objects you already manage through the Web UI, supctl, and the APIs: sites, applications, deployments, and their runtime status.
The assistant does not bypass the platform. Requests use the credentials you configure, and what the assistant can see and change is bounded by the permissions tied to those credentials. That makes access scoping the first design decision: a read-only identity for exploration and troubleshooting, and a more privileged one only where changes are intended.
The Avassa documentation walks through connecting the server to Claude Code, and the release notes summarize the capability:
https://docs.avassa.io/how-to/claude-code-mcp
https://avassa.io/feature-releases/march-2026-feature-releases-highlights/#MCP
The operations experience
For operations teams, the value is less about creating things and more about understanding them. A question like “which sites are running an outdated version of the inference service, and why did the last rollout stall?” normally involves several queries, filters, and log lookups. With MCP, the assistant makes those calls, correlates the results, and presents a concise answer together with the evidence behind it.
Because this kind of work is mostly read-only, it is also a natural, low-risk place to start with MCP in an existing environment.
First, I ask Claude to summarize my sites:
Claude returned a table covering all nine sites, with host count, site health and the health of each application. Five sites are healthy. Three sites, iot-site, my-site and robot-1, each have a host in distress while their applications keep running, and robot-4 has an application error. Claude called out that the robot-4 issue is new since the previous check: the robot-controller container is running, but its readiness check fails. What would normally mean opening each site in turn became one question and a short list of what needs attention.
I asked Claude to drill down on “my-site”:
It told me I need to
- first fix disk space on the host, Claude suggested running “df -h” and “du -xh” to find it.
- and make sure I have configured the logs volume correctly for applications. The logs volume is configured on the host but is down, and nothing uses it today, but it would block any application that needs it.
Turning to applications, I asked Claude to drill down into the failing application:
Claude identified the failing application as robot-controller at site robot-4, running on host robot-4-1. The container has been running since 21 Sep with no restarts, and both the startup check and the HTTP liveness check on port 10000 pass. Only the readiness check fails, with the message “Command sh failed with exit code: 1”, while the host itself shows no distress and is not in maintenance mode. In other words, the application is running, but Avassa considers it not ready, so it shows up as an error.
Claude then spelled out the impact. Because the readiness check fails, Avassa treats the instance as not ready, excludes it from service traffic, and flags the site with has-application-errors. The container is not restarted because only the liveness check triggers restarts, and that one passes. The distinction between an application that is dead and one that is alive but not ready is easy to miss when reading raw status output, and here it was explained alongside the evidence.
Summary of the operations scenario. In a handful of prompts, Claude went from a fleet-wide health overview to the likely cause of two separate problems, without changing anything in the estate. It found a host running out of disk space, together with a logs volume that is down but not yet used, and an application that is running but failing its readiness check. For each, it explained the operational impact and suggested next steps. The investigation was done through the Avassa MCP server with read-only questions; the operator decides how to act on the findings.
The developer experience
Where the operations scenario only reads state, development is about changing it. For developers, the MCP server shortens the loop between writing an edge application and seeing it run on real sites. Rather than switching between the code editor, specification files, the command line, and the Control Tower UI, the developer stays in one conversation: describe the application and where it should run, let the assistant produce the application and deployment specifications, and have it deploy and verify the result.
This is particularly useful for edge AI workloads, where getting model containers, configuration, secrets, and hardware access right often takes several iterations. The assistant handles the mechanics; the developer stays focused on intent and reviews the output.
As a developer, your overall task is to develop an application and deploy it to multiple sites. Claude can do that for you. In this scenario, we ask Claude to turn a Python program into an application and deploy it to a site called “robot-cluster”:
The request is written in plain language: “Create an application from run.py and launch it on the robot-cluster site.” Because Claude Code is connected to Control Tower through the Avassa MCP server, it can look up existing applications, sites, and the registry instead of guessing how the environment is set up.
Starting from a minimal Python skeleton, Claude performs all the steps for you:
- It generates the program and builds a corresponding container image.
- It finds the registry path in Control Tower and pushes the image.
- It generates an Avassa application specification and a deployment specification.
- Finally, it deploys the application and makes it run on the edge site.
An important property of the Avassa MCP server is that all configuration changes are staged. Nothing is applied until you tell it to:
Claude stages the changes and hands back two supctl commands: one to review what has been staged and one to apply it. The assistant prepares the work, but the developer decides when it takes effect.
Here we can see the application specification and the corresponding deployment specification that Claude staged:
Claude summarizes what it created: an application, run-py 1.0, that runs a single container, and a deployment that places version 1.0 on robot-cluster. It is also open about an assumption it made, referencing the image by its bare name as an existing application does, and explains what to change if the pull fails. The staged changes show the exact data for each object, and Claude points out that the image must be pushed with ./build-push.sh before the changes are applied.
After applying the staged changes, we ask Claude whether the application is up and running:
Claude answers by querying the live state in Control Tower through the MCP server, rather than relying on what it did earlier in the session:
The answer is backed by evidence from the running system: the image is in the Control Tower registry, version 1.0 was deployed to robot-cluster, the run-py-1 container is running and ready on host robot-1 with no restarts, and the logs show the program printing “I’m alive” every two seconds. One question replaces separate checks of the registry, deployment status, container state, and logs.
Summary of the developer scenario. With one plain-language prompt, Claude took a minimal Python skeleton all the way to a containerized application running on an edge site. It wrote the program, built and pushed the image, generated the application and deployment specifications, and staged them for review. Nothing changed in Control Tower until the developer applied the staged changes, and a single follow-up question confirmed that the application was deployed, running, and producing logs. Throughout, the developer stayed in one terminal session and focused on what the application should do and where it should run, while the assistant handled the Avassa mechanics.
Summary
MCP changes how people interact with an edge platform, not what the platform does. Avassa still provides the declarative model, site autonomy, and application lifecycle management; MCP gives developers and operators a conversational, context-aware way to use it. For operators that means faster answers across many sites, and for developers it means faster iteration on edge applications.
A few considerations help when deciding how to adopt it:
- Start read-only. Health and troubleshooting questions deliver value with minimal risk and build confidence in how the assistant behaves.
- Scope credentials deliberately. Give the assistant only the permissions each task needs, and keep test and production access separate.
- Keep a human in the loop for changes. Review generated specifications and approve deployments before they reach production sites.
- Treat generated artifacts as code. Store specifications in version control and run them through the same review and CI process as hand-written ones.
Used this way, MCP becomes a practical accelerator for edge orchestration rather than a new source of risk.