esp32-mcp
Related Servers
Alternatives to esp32-mcp
No user-submitted related servers found.
Related Servers
- AlicenseAqualityDmaintenanceEnables registration, monitoring, and control of IoT devices via AI agents, with local storage and no cloud API key required.921 PyPIMIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents and humans to control various hardware boards (ESP32, Arduino, Raspberry Pi, etc.) through a unified API via MCP, with real-time dashboard support.MIT
- AlicenseNot gradedqualityAmaintenanceESP32-based Streamable HTTP MCP server with embedded Lua scripting engine. Bridges Claude AI to physical devices — telescopes (INDI protocol), sensors, BLE peripherals, and TCP devices. Flash-and-run binary distribution, no build required.13MIT
- AlicenseAqualityDmaintenanceMCP server that gives AI agents direct access to IoT devices via the jettyd platform, enabling control and monitoring of ESP32 devices through natural language.5129 npmMIT
- AlicenseNot gradedqualityDmaintenanceBridges the Model Context Protocol (MCP) with ESP32 devices running Tasmota firmware, enabling LLMs to send structured commands like toggling relays or reading sensors via HTTP.1ISC
- AlicenseAqualityDmaintenanceEnables AI agents to discover, monitor, and control industrial hardware like ESP32 machine controllers and inspection cameras through a standardized MCP interface.5MIT
TDQS
Scored across 5 tools
Each tool has a distinct action: health (board identity/diagnostics), read_sensors (sensor values), set_relay (relay control), gpio_read, gpio_write. The only mild overlap is that esp32_health also reports the relay table and health metrics while esp32_read_sensors reports chip temperature, but the descriptions make the boundary clear enough.
All tools share the esp32_ prefix and a consistent snake_case form. Minor deviation: read_sensors/set_relay use verb_noun ordering while gpio_read/gpio_write use noun_verb, though the gpio pair is internally consistent and readable.
Five tools is a tight, well-scoped surface for a microcontroller: one discovery, one sensor read, one relay control, and a GPIO read/write pair. Nothing feels redundant or padded.
Core lifecycle is covered: discovery, sensor reading, relay actuation, and GPIO read/write. Gaps exist for reset/reboot, OTA/firmware update, and analog/PWM output, but these are minor and can be worked around for typical use.