The Internet of Things on AWS – Official Blog
Deploying MCP servers with AWS IoT Greengrass for edge diagnostics
Deploying Model Context Protocol (MCP) servers with AWS IoT Greengrass brings autonomous network diagnostics to the edge, where connectivity failures happen and expertise is hard to find. Whether supporting large-scale military exercises, managing industrial infrastructure across remote locations, or operating maritime and energy networks, teams depend on senior engineers to diagnose and resolve complex network issues. But this approach has real limits:
- Latency in response – Engineers must be physically or remotely available to troubleshoot, creating delays when connectivity is unreliable.
- Scalability limits – As device fleets grow across distributed sites, manual diagnostics can’t keep pace.
- Knowledge silos – Institutional knowledge about device behavior and failure patterns stays locked in individual engineers rather than encoded in reusable systems.
- Inconsistent outcomes – Without standardized diagnostic workflows, troubleshooting quality varies across teams and shifts.
When dozens of teams converge for a field exercise, each with competing priorities and tight timelines, the network becomes the single point of failure. The few people who can fix it become the bottleneck. The alternative is to encode that expertise into an edge agent that operates independently of connectivity, executing predefined diagnostic workflows at scale without requiring an engineer to be present.
Instead of calling the expert, a team member could initiate a diagnostic workflow through the locally running agent, which follows structured troubleshooting procedures to diagnose and recommend remediation steps.
This is the first in a series of blog posts about Agentic AI at the Edge. In this post, we cover the why and provide an overview of the how. In future posts, we will dive deeper into deploying the solution using AWS tools, building the MCP server, and diagnostic workflows.
How an engineer troubleshoots today
To understand how to build an AI-powered diagnostic agent, it helps to first examine what a human expert does when troubleshooting a network issue:
| Step | What the Engineer Does | What They Use |
| Foundational knowledge | Draws on general understanding of networking concepts – how ARP works, how DNS resolves, how BGP sessions are established | Training and experience |
| Domain-specific expertise | Follows a structured diagnostic approach – a mental or written runbook for the specific problem class | Runbooks, standard operating procedures |
| System identification | Knows which systems to inspect – the management IP of the router, where relevant metrics are collected, which interfaces to check | Network documentation, asset inventories |
| Tool execution | Uses specific tools to gather data and take action – SSH to access a device, REST APIs to query dashboards, SNMP to collect metrics | SSH, web terminals, dashboards, CLI tools |
For example, a runbook might say: “If you see BGP session flapping, SSH into the router, check the BGP neighbor table, compare the hold timer with the interface error counters, and verify the upstream link status.”
Mapping this workflow onto an AI agent is exactly what the Model Context Protocol provides.
Mapping diagnostic workflows to Model Context Protocol (MCP)
MCP is an open standard that provides a unified way for AI applications to connect to external data sources, tools, and services. Rather than building custom integrations for every tool an AI agent needs to use, MCP defines a standardized interface between the agent’s orchestration layer and the capabilities it needs to access.
MCP defines three core primitives:
- Tools – Functions the AI agent can invoke to perform actions (for example, execute a ping, query SNMP OIDs, run CLI commands against a router, call a REST API).
- Resources – Data sources the agent can read for context (for example, device configuration files, network topology data, monitoring dashboards).
- Prompts – Reusable prompt templates that encode expert workflows (for example, a structured BGP troubleshooting procedure, a wireless connectivity diagnostic playbook).
Mapping the engineer’s workflow to MCP
The parallel between what a human expert does and what MCP provides is direct:
| Human Expert | MCP + AI Agent Equivalent |
| Foundational knowledge (networking, systems) | The small language model (SLM) has foundational knowledge. Ask it how ARP or DNS works, and it knows. Give it data to interpret, and it can. |
| Domain-specific expertise (runbooks, SOPs) | Prompts – expert-level context encoded as structured diagnostic workflows. These are the AI equivalent of runbooks. |
| System identification (IPs, endpoints, data sources) | Resources – the systems the agent needs to troubleshoot directly or obtain data from to diagnose issues. |
| Tool execution (SSH, REST, SNMP, CLI) | Tools – the actions the agent invokes to execute diagnostic tasks: SSH to access a device, REST to query APIs, SNMP to collect metrics. |
With this mapping, the foundation is in place to build agentic diagnostic systems that can scale, troubleshoot, and take corrective action on behalf of operators, without requiring a human expert for every issue.
In this post, we show how to package MCP servers as AWS IoT Greengrass components to deploy autonomous, AI agent-driven network diagnostics at the edge. This pattern encodes expert diagnostic knowledge into reusable, deployable components that operate independently even when disconnected from the cloud.
The solution: MCP servers as Greengrass components
AWS IoT Greengrass is an open source edge runtime and cloud service that extends AWS capabilities to edge devices, supporting local processing, messaging, and data caching with cloud synchronization. With this distributed computing framework, devices can operate autonomously even when disconnected from the cloud.
By packaging an MCP server as a Greengrass component, we bring this standardized AI-to-tool interface directly to the network edge. The architecture consists of three core elements:
- MCP server component: A custom Greengrass component that exposes network diagnostic tools (ping, traceroute, SNMP queries, CLI commands) as structured MCP tool definitions. The server runs locally on the edge device and communicates with network equipment over the local network. The MCP server uses the stdio transport to communicate with the agent component, keeping all diagnostic traffic local to the device.
- Edge ML component: A machine learning (ML) model deployed through Greengrass that provides diagnostic analysis capabilities, receives diagnostic requests, follows predefined decision trees to select appropriate MCP tools, processes structured responses, and applies pattern matching to identify potential root causes.
- Orchestration component: A lightweight agent built with Strands Agents (an open source SDK from AWS for building and orchestrating AI agents) that coordinates the diagnostic workflow, manages conversation context, and persists results locally. Strands Agents provides model-agnostic orchestration capabilities, so the agent can reason about which tools to call and in what sequence. The orchestration component communicates with the MCP server and SLM over Greengrass interprocess communication.
Architecture overview
The following architecture diagram shows the MCP server, SLM, and orchestration components running as Greengrass components on an edge device. The components have local network access to managed devices, with cloud synchronization through AWS IoT Core.
The architecture spans AWS Cloud and an AWS IoT Greengrass edge device.
On the edge, the S3FileDownloader component pulls model files from Amazon Simple Storage Service (Amazon S3) and delivers them to the local inference engine for processing.
The MCP server executes diagnostic tools (SSH, SNMP, REST) against local network devices.
The Strands Agents component (Agent Edge) orchestrates the workflow, coordinating between the MCP server for tool execution and the local inference engine for analysis.
In the cloud, AWS IoT Core synchronizes telemetry and results between edge and cloud.
A cloud-based Agent with Amazon DynamoDB persists unresolved diagnostics, while an Amazon Elastic Compute Cloud (Amazon EC2) instance hosts a cloud-side MCP server for escalation scenarios requiring additional compute.
Figure 1: Architecture
This figure shows the end-to-end architecture. Strands Agents running on AWS IoT Greengrass perform autonomous network diagnostics at the edge by using a local large language model (LLM). The cloud layer handles fleet-wide analysis, state management, and model deployment through Amazon S3.
Communication patterns
The diagnostic pipeline uses three Greengrass communication patterns:
- Interprocess communication (IPC): Component-to-component messaging within the Greengrass nucleus lets the SLM, MCP server, and orchestration components exchange structured data without external network dependencies. Greengrass IPC uses a local socket-based mechanism for low-latency messaging.
- Local MQTT: Device-to-device communication at the edge facilitates diagnostic data exchange with neighboring network equipment and local monitoring systems.
- AWS IoT Core Topics: When connectivity is available, diagnostic results, telemetry, and model performance metrics synchronize to cloud services for fleet-wide visibility.
During disconnected periods, the Greengrass stream manager and MQTT spooler temporarily buffer diagnostic results and telemetry locally. Storage is bound by configurable size limits (default 256 MB per stream), with overflow policies that discard the oldest data when capacity is reached. When connectivity is restored, the system automatically synchronizes this cached data with cloud services requiring no manual intervention.
How the diagnostic flow works
When a diagnostic request is initiated, either by a scheduled trigger, an alarm threshold, or a manual request, the following sequence executes entirely at the edge:
- The orchestration component receives the diagnostic intent (for example, “Investigate why Site-A router is dropping BGP sessions”).
- The edge machine learning (ML) component analyzes the request and determines an initial diagnostic plan.
- The ML component issues structured tool calls to the MCP server (for example,
check_bgp_neighbors,get_interface_status,ping_gateway). - The MCP server executes the corresponding commands against the target network device and returns structured results.
- The ML component processes the results, applies pattern recognition algorithms, and evaluates predefined decision criteria to determine whether additional diagnostic steps are needed.
- The system logs the unresolved diagnostic session to an Amazon DynamoDB table (including context, steps attempted, and confidence scores) and can be extended to trigger an alert to the designated human operator.
- Results are persisted locally and queued for cloud synchronization. They can be surfaced on the operator dashboard for real-time visibility, evaluated against severity thresholds for critical findings, and aggregated into periodic readiness reports. The human-in-the-loop retains final authority over disposition decisions. The system recommends, and the operator acts.
This diagnostic loop, where the ML processes results and executes the next diagnostic action based on predefined decision trees, transforms static runbooks into adaptive troubleshooting workflows.
Conclusion
Packaging MCP servers as AWS IoT Greengrass components brings standardized, AI agent-driven network diagnostics to the edge where connectivity is unreliable and manual intervention is impractical.
Instead of pulling senior experts off other critical tasks or waiting for a remote callback, teams can now query a local diagnostic agent that reasons through problems like an experienced engineer would.
By combining the MCP open standard with the modular component architecture of AWS IoT Greengrass, you gain autonomous diagnostic capabilities that:
- Operate independently during disconnected periods and synchronize automatically when connectivity returns.
- Encode diagnostic expertise in reusable, deployable components rather than relying on institutional knowledge.
- Scale across distributed device fleets with consistent, standardized troubleshooting workflows.
- Adapt dynamically, the agentic loop delivers context-aware diagnostics that go beyond static runbooks.
Whether you’re supporting tactical networks in defense, industrial infrastructure in manufacturing, or remote operations in energy and maritime sectors, this architecture provides a secure, extensible foundation for edge AI that adapts as network complexity grows.
To get started or learn more:
- AWS IoT Greengrass – Learn how Greengrass extends AWS capabilities to edge devices with local processing, messaging, and cloud synchronization.
- AWS IoT Greengrass documentation – Explore developer guides for building and deploying custom components.
- Deploying machine learning at the edge with AWS IoT Greengrass – Related reading on edge AI patterns with Greengrass.