---
title: "How to Add W5500 Ethernet to mcpd on ESP32 or RP2040?"
url: "https://maker.wiznet.io/viktor/projects/mcpd/"
markdown_url: "https://maker.wiznet.io/viktor/projects/mcpd/md"
type: "UCC: User Created Content"
author: "Nicola Spieser Buiss"
author_url: "https://github.com/redbasecap-buiss/mcpd"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Nicola Spieser Buiss"
original_url: "https://github.com/redbasecap-buiss/mcpd"
published: "2026-02-19"
language: "en"
likes: 0
views: 346
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# How to Add W5500 Ethernet to mcpd on ESP32 or RP2040?

> mcpd is an embedded Model Context Protocol server SDK that lets a microcontroller expose hardware functions as MCP tools for clients such as Claude Desktop

Original author: Nicola Spieser Buiss (source: https://github.com/redbasecap-buiss/mcpd)

## Article

## Summary

`mcpd` is an embedded Model Context Protocol server SDK that lets a microcontroller expose hardware functions as MCP tools for clients such as Claude Desktop. In the current repository, WIZnet’s **W5500** fits as a wired Ethernet transport option through the new `MCPEthernetTool`, while `mcpd` continues to handle JSON-RPC dispatch, tool registration, HTTP/SSE transport behavior, discovery, and host bridging. The important nuance is that upstream now names W5500 explicitly, but the current Ethernet implementation is still partly scaffolded rather than a full production-grade W5500 bring-up.

## What the Project Does

`mcpd` is designed to run on the MCU itself and expose board functions as MCP tools and resources. The repository presents it as an MCP Server SDK for microcontrollers, with support for ESP32, RP2040, and STM32 in its package metadata, and the README highlights built-in tools spanning GPIO, I2C, SPI, ADC, UART, CAN, Modbus, filesystems, timers, and more. The examples list shows the intended deployment range clearly: `basic_server`, `sensor_hub`, `home_automation`, `weather_station`, `mqtt_bridge`, and `robot_arm`.

Architecturally, `mcpd` is not just a firmware library with a few helpers. Its README shows a split system where an MCP client talks over stdio to a Python host bridge, and that bridge forwards requests to the MCU over network transport. The bridge code documents this directly as an HTTP transport path that sends HTTP POST requests to the MCU, while the MCP transport spec defines Streamable HTTP as POST and GET with optional SSE for streaming. That makes `mcpd` a protocol-facing edge runtime rather than a one-off REST sketch.

The firmware side is deliberately simple. In `examples/basic_server/basic_server.ino`, the example connects to Wi-Fi, registers a tool, starts the MCP server with `mcp.begin()`, and services requests in `mcp.loop()`. That matters because it shows where a W5500 port belongs: below the server logic, in the network bring-up and transport path, not in the MCP method layer itself.

## Where WIZnet Fits

WIZnet now has a real place in this repository. The changelog for version `0.22.0` records the addition of an **Ethernet Tool** at `tools/MCPEthernetTool.h`, described as wired network management for **W5500, ENC28J60, LAN8720, and DM9051**, with four MCP tools: `ethernet_config`, `ethernet_status`, `ethernet_ping`, and `ethernet_dns_lookup`. So unlike a purely hypothetical port, upstream `mcpd` now exposes a W5500-facing control surface inside its built-in tool set.

For this project, the exact WIZnet product is the **W5500**. Official WIZnet documentation describes it as a hardwired TCP/IP Ethernet controller with integrated 10/100 MAC and PHY, SPI connectivity to an external MCU, **8 independent sockets**, and **32 KB of internal memory**. In `mcpd`, that makes W5500 a transport component, not an application component: it would carry the MCU’s network-facing HTTP/SSE endpoint while `mcpd` continues to own tool dispatch, sessions, and MCP semantics.

This is a technically good fit for boards that do not have native Ethernet or where wired deployment is preferable to Wi-Fi. The README still describes the beginner path around Wi-Fi and lists `RP2040 (Pico W)` as HAL-ready while `STM32 + Ethernet` remains marked as planned, so the repository is still Wi-Fi-led at the documentation level. But the Ethernet tool’s own header describes it as useful for installations where Wi-Fi is not desirable, which is exactly the deployment case where W5500 makes sense.

## Implementation Notes

The strongest evidence is in `src/tools/MCPEthernetTool.h`. The tool schema explicitly includes W5500 in the chip list:

```plaintext
// src/tools/MCPEthernetTool.h
"enum":["w5500","enc28j60","lan8720","dm9051"]
```

That line matters because it shows W5500 is not an external note or a roadmap item; it is already part of the MCP-facing Ethernet configuration API that upstream ships today. The same schema also requires `cs_pin`, which confirms the intended hardware model is an SPI-attached controller rather than an on-chip Ethernet MAC.

The second important signal is that the current implementation is still incomplete as a real network stack binding:

```plaintext
// src/tools/MCPEthernetTool.h
// For now, simulate initialization
```

That comment appears directly next to the path that marks Ethernet as initialized and link-up. The same file also labels ping as simulated and returns a DNS note saying resolution requires a network stack. In other words, the repository already defines the MCP tool interface for W5500-class Ethernet control, but it has not yet completed the low-level integration needed for real hardware network operations.

The rest of the codebase shows why this boundary is clean. The host bridge sends HTTP POST requests to the MCU and advertises discovery through `_mcp._tcp.local.`, while the basic server example starts from a Wi-Fi transport path. That means a production W5500 integration does not need to redesign `mcpd`; it needs to replace the network substrate under the existing server lifecycle and discovery model.

## Practical Tips / Pitfalls

- Treat W5500 support in `mcpd` as **real API surface, incomplete hardware runtime**. The MCP tools are present upstream, but initialization, ping, and DNS are still partly simulated in the current header.

- Budget around W5500’s **8 sockets** before enabling long-lived features such as SSE streams, control traffic, OTA, and metrics on the same device.

- Discovery is not free. The bridge looks for `_mcp._tcp.local.`, so a wired W5500 deployment needs either working mDNS advertisement or a deliberate fallback to static host and port configuration.

- Keep transport and MCP logic separate during debugging. First prove SPI wiring, reset, IP assignment, and HTTP reachability; only then debug MCP methods and tool responses. The current basic example already reflects that layering.

- For fixed installations, W5500 is often a better operational fit than Wi-Fi. `mcpd` already describes Ethernet as useful where Wi-Fi is undesirable, and W5500’s offloaded socket model maps well to a small MCU serving HTTP-based MCP traffic.

## FAQ

**Q: Why use W5500 for this project instead of staying with the default Wi-Fi path?**
A: Because `mcpd` itself is protocol- and tool-oriented, not Wi-Fi-specific. W5500 gives a wired TCP/IP path over SPI with integrated MAC/PHY and hardware sockets, which is useful when installation stability, cabling discipline, or RF restrictions matter more than wireless convenience. The repo’s own Ethernet tool description frames this for reliability-oriented deployments where Wi-Fi is not desirable.

**Q: How does W5500 connect to the platform here?**
A: As an SPI-based Ethernet controller. `MCPEthernetTool.h` requires a `chip` selection and a `cs_pin`, and also allows interrupt and reset pins, which matches the expected external-controller wiring model for W5500. On the firmware side, the MCU still runs `mcpd`; W5500 only supplies the Ethernet transport path.

**Q: What role does W5500 play in this specific **`**mcpd**`** project?**
A: It plays the role of a wired network backend exposed through MCP tools. The project now includes `ethernet_config`, `ethernet_status`, `ethernet_ping`, and `ethernet_dns_lookup`, so W5500 is being treated as a manageable Ethernet subsystem inside the MCP tool model rather than as a hidden board-specific driver.

**Q: Can beginners follow this today?**
A: Only up to a point. A beginner can use `mcpd`’s Wi-Fi examples to understand the server lifecycle, but a real W5500 deployment is still an intermediate embedded task because the present Ethernet code is not a finished hardware bring-up. You need to be comfortable with SPI wiring, controller reset, IP configuration, and HTTP serving before the MCP layer becomes the easy part.

**Q: How does W5500 compare with the built-in Wi-Fi approach for this repository?**
A: Wi-Fi is the better-documented path today because the quick start and `basic_server` example already use it directly. W5500 is the better fit when you want wired Ethernet, simpler network provisioning, and a hardware-offloaded socket path, but today it still requires additional implementation work because the Ethernet tool interface is ahead of the finished runtime backend.

---

Source: https://maker.wiznet.io/viktor/projects/mcpd/