Un servicio de Protocolo de Contexto de Modelo (MCP) para la gestión de dispositivos NodeMCU. Este servicio proporciona una interfaz API/WebSocket RESTful estándar e implementa el Protocolo de Contexto de Modelo para la integración con herramientas de IA como Claude Desktop.
NodeMCU MCP proporciona una solución de gestión para dispositivos IoT ESP8266/NodeMCU con estas capacidades clave:
Supervisar el estado del dispositivo y la telemetría
Enviar comandos a dispositivos de forma remota
Actualizar las configuraciones del dispositivo
Integración con asistentes de IA a través del protocolo MCP
Related MCP server: MCP Personal Assistant Agent
🔌 Administración de dispositivos : registre, monitoree y controle dispositivos NodeMCU
📊 Comunicación en tiempo real : Interfaz WebSocket para actualizaciones en tiempo real
⚙️ Gestión de configuración : actualice la configuración del dispositivo de forma remota
🔄 Ejecución de comandos : envía comandos de reinicio, actualización y estado de forma remota
📡 Recopilación de telemetría : recopile datos de sensores y métricas del dispositivo
🔐 Autenticación : Acceso seguro a la API con autenticación JWT
🧠 Integración de IA : trabaje con Claude Desktop y otras herramientas de IA compatibles con MCP
Node.js 16.x o superior
npm o hilo
Para el cliente NodeMCU: Arduino IDE con soporte ESP8266
Para instalar NodeMCU Manager para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @amanasmuei/nodemcu-mcp --client claude# Global installation (recommended for MCP integration)
npm install -g nodemcu-mcp
# Local installation
npm install nodemcu-mcp# Clone the repository
git clone https://github.com/amanasmuei/nodemcu-mcp.git
cd nodemcu-mcp
# Install dependencies
npm install
# Optional: Install globally for MCP integration
npm install -g .Cree un archivo .env basado en el ejemplo:
cp .env.example .envActualice el archivo .env con su configuración:
# Server Configuration
PORT=3000
HOST=localhost
# Security
JWT_SECRET=your_strong_random_secret_key
# Log Level (error, warn, info, debug)
LOG_LEVEL=infoModo de desarrollo con reinicio automático:
npm run devModo de producción:
npm startPara la integración con Claude Desktop u otros clientes MCP:
npm run mcpSi se instala globalmente:
nodemcu-mcp --mode=mcpUsage: nodemcu-mcp [options]
Options:
-m, --mode Run mode (mcp, api, both) [string] [default: "both"]
-p, --port Port for API server [number] [default: 3000]
-h, --help Show help [boolean]
--version Show version number [boolean]Este proyecto ahora utiliza el SDK oficial de TypeScript del Protocolo de contexto de modelo (MCP) para brindar integración con Claude for Desktop y otros clientes de MCP.
Las siguientes herramientas están disponibles a través de la interfaz MCP:
list-devices : enumera todos los dispositivos NodeMCU registrados y su estado
get-device : obtiene información detallada sobre un dispositivo NodeMCU específico
send-command : envía un comando a un dispositivo NodeMCU
update-config : actualiza la configuración de un dispositivo NodeMCU
Para utilizar este servidor con Claude for Desktop:
Instale Claude para escritorio desde https://claude.ai/desktop
Configure Claude para escritorio editando ~/Library/Application Support/Claude/claude_desktop_config.json :
{
"mcpServers": {
"nodemcu": {
"command": "node",
"args": [
"/ABSOLUTE/PATH/TO/YOUR/PROJECT/mcp_server_sdk.js"
]
}
}
}Reiniciar Claude para escritorio
Ahora debería ver las herramientas NodeMCU en la interfaz de Claude for Desktop
Para ejecutar el servidor MCP directamente:
npm run mcpO usando la CLI:
./bin/cli.js --mode=mcpPOST /api/auth/login - Iniciar sesión y obtener el token JWT
{
"username": "admin",
"password": "admin123"
}Respuesta:
{
"message": "Login successful",
"token": "your.jwt.token",
"user": {
"id": 1,
"username": "admin",
"role": "admin"
}
}POST /api/auth/validate - Validar el token JWT
{
"token": "your.jwt.token"
}Todos los puntos finales del dispositivo requieren autenticación con un token JWT:
Authorization: Bearer your.jwt.tokenGET /api/devicesRespuesta:
{
"count": 1,
"devices": [
{
"id": "nodemcu-001",
"name": "Living Room Sensor",
"type": "ESP8266",
"status": "online",
"ip": "192.168.1.100",
"firmware": "1.0.0",
"lastSeen": "2023-05-15T14:30:45.123Z"
}
]
}GET /api/devices/:idRespuesta:
{
"id": "nodemcu-001",
"name": "Living Room Sensor",
"type": "ESP8266",
"status": "online",
"ip": "192.168.1.100",
"firmware": "1.0.0",
"lastSeen": "2023-05-15T14:30:45.123Z",
"config": {
"reportInterval": 30,
"debugMode": false,
"ledEnabled": true
},
"lastTelemetry": {
"temperature": 23.5,
"humidity": 48.2,
"uptime": 3600,
"heap": 35280,
"rssi": -68
}
}POST /api/devices/:id/commandPedido:
{
"command": "restart",
"params": {}
}Respuesta:
{
"message": "Command sent to device",
"command": "restart",
"params": {},
"response": {
"success": true,
"message": "Device restarting"
}
}El servidor WebSocket está disponible en la ruta raíz: ws://your-server:3000/
Para obtener detalles sobre los mensajes del protocolo WebSocket, consulte el código o el directorio de ejemplos.
Consulte el boceto de Arduino en el directorio examples para obtener una implementación completa del cliente.
Instalar las bibliotecas necesarias en Arduino IDE:
ESP8266WiFi
Cliente WebSockets
ArduinoJson
Configura el boceto con tu configuración WiFi y del servidor:
// WiFi credentials
const char* ssid = "YOUR_WIFI_SSID";
const char* password = "YOUR_WIFI_PASSWORD";
// MCP Server settings
const char* mcpHost = "your-server-ip";
const int mcpPort = 3000;Sube el boceto a tu dispositivo NodeMCU
nodemcu-mcp/
├── assets/ # Logo and other static assets
├── bin/ # CLI scripts
├── examples/ # Example client code
├── middleware/ # Express middleware
├── routes/ # API routes
├── services/ # Business logic
├── .env.example # Environment variables example
├── index.js # API server entry point
├── mcp_server.js # MCP protocol implementation
├── mcp-manifest.json # MCP manifest
└── package.json # Project configuration¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Bifurcar el repositorio
Crea tu rama de funciones ( git checkout -b feature/amazing-feature )
Confirme sus cambios ( git commit -m 'Add some amazing feature' )
Empujar a la rama ( git push origin feature/amazing-feature )
Abrir una solicitud de extracción
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
La licencia MIT es una licencia permisiva que le permite:
Utilizar el software con fines comerciales
Modificar el software
Distribuir el software
Utilizar y modificar el software de forma privada
El único requisito es que la licencia y el aviso de derechos de autor deben incluirse junto con el software.
Protocolo de contexto del modelo para la especificación de integración
NodeMCU para la increíble plataforma IoT
Antrópico para Claude Desktop
| Name | Required | Description | Default |
|---|---|---|---|
| deviceId | Yes | The ID of the device to get information about |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to send (restart, update, status, etc.) | |
| deviceId | Yes | The ID of the device to send the command to | |
| params | No | Optional parameters for the command |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | Configuration parameters to update | |
| deviceId | Yes | The ID of the device to update configuration for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get-devicelist-devicessend-commandupdate-configScored across 4 tools
Each tool has a clearly distinct purpose: get-device retrieves a single device, list-devices lists multiple devices, send-command sends commands to devices, and update-config updates device configurations. There is no overlap or ambiguity between these functions.
All tool names follow a consistent verb-noun pattern with hyphen separation (e.g., get-device, list-devices, send-command, update-config). The naming is uniform and predictable across all tools.
With 4 tools, this server is well-scoped for managing NodeMCU devices. Each tool serves a distinct and essential function, and the count is appropriate for the apparent scope of device management.
The tools cover core CRUD-like operations for device management: listing, retrieving, commanding, and configuring. A minor gap might be the absence of a delete-device or create-device tool, but the existing set supports most common workflows.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for Studex tools, notifications, and profile integrations
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.