Wiznet makers

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:

// 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:

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

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.