NodeMCU 장치를 관리하기 위한 모델 컨텍스트 프로토콜(MCP) 서비스입니다. 이 서비스는 표준 RESTful API/WebSocket 인터페이스를 제공하고 Claude Desktop과 같은 AI 도구와의 통합을 위해 모델 컨텍스트 프로토콜을 구현합니다.
NodeMCU MCP는 다음과 같은 주요 기능을 갖춘 ESP8266/NodeMCU IoT 장치를 위한 관리 솔루션을 제공합니다.
장치 상태 및 원격 측정 모니터링
원격으로 장치에 명령 보내기
장치 구성 업데이트
MCP 프로토콜을 통한 AI 어시스턴트와의 통합
Related MCP server: MCP Personal Assistant Agent
🔌 장치 관리 : NodeMCU 장치를 등록, 모니터링 및 제어합니다.
📊 실시간 통신 : 실시간 업데이트를 위한 WebSocket 인터페이스
⚙️ 구성 관리 : 원격으로 장치 설정 업데이트
🔄 명령 실행 : 재시작, 업데이트, 상태 명령을 원격으로 전송합니다.
📡 원격 측정 수집 : 센서 데이터 및 장치 메트릭 수집
🔐 인증 : JWT 인증을 통한 안전한 API 접근
🧠 AI 통합 : Claude Desktop 및 기타 MCP 호환 AI 도구와 함께 작동
Node.js 16.x 이상
npm 또는 yarn
NodeMCU 클라이언트의 경우: ESP8266을 지원하는 Arduino IDE
Smithery 를 통해 Claude Desktop용 NodeMCU Manager를 자동으로 설치하려면:
지엑스피1
# 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 .다음 예를 기반으로 .env 파일을 만듭니다.
cp .env.example .env.env 파일을 설정으로 업데이트하세요.
# Server Configuration
PORT=3000
HOST=localhost
# Security
JWT_SECRET=your_strong_random_secret_key
# Log Level (error, warn, info, debug)
LOG_LEVEL=info자동 재시작 기능이 있는 개발 모드:
npm run dev생산 모드:
npm startClaude Desktop 또는 다른 MCP 클라이언트와 통합하려면:
npm run mcp전역적으로 설치된 경우:
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]이 프로젝트는 이제 Claude for Desktop 및 기타 MCP 클라이언트와의 통합을 제공하기 위해 공식 Model Context Protocol(MCP) TypeScript SDK를 사용합니다.
다음 도구는 MCP 인터페이스를 통해 사용할 수 있습니다.
list-devices : 등록된 모든 NodeMCU 장치와 해당 상태를 나열합니다.
get-device : 특정 NodeMCU 장치에 대한 자세한 정보를 가져옵니다.
send-command : NodeMCU 장치에 명령을 보냅니다.
update-config : NodeMCU 장치의 구성을 업데이트합니다.
Claude for Desktop과 함께 이 서버를 사용하려면:
https://claude.ai/desktop 에서 Claude for Desktop을 설치하세요.
~/Library/Application Support/Claude/claude_desktop_config.json 편집하여 데스크톱용 Claude를 구성합니다.
{
"mcpServers": {
"nodemcu": {
"command": "node",
"args": [
"/ABSOLUTE/PATH/TO/YOUR/PROJECT/mcp_server_sdk.js"
]
}
}
}데스크톱용 Claude를 다시 시작하세요
이제 Claude for Desktop 인터페이스에서 NodeMCU 도구를 볼 수 있습니다.
MCP 서버를 직접 실행하려면:
npm run mcp또는 CLI를 사용합니다.
./bin/cli.js --mode=mcpPOST /api/auth/login - 로그인하고 JWT 토큰을 받으세요
{
"username": "admin",
"password": "admin123"
}응답:
{
"message": "Login successful",
"token": "your.jwt.token",
"user": {
"id": 1,
"username": "admin",
"role": "admin"
}
}POST /api/auth/validate - JWT 토큰 검증
{
"token": "your.jwt.token"
}모든 장치 엔드포인트에는 JWT 토큰을 통한 인증이 필요합니다.
Authorization: Bearer your.jwt.tokenGET /api/devices응답:
{
"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/:id응답:
{
"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/command요구:
{
"command": "restart",
"params": {}
}응답:
{
"message": "Command sent to device",
"command": "restart",
"params": {},
"response": {
"success": true,
"message": "Device restarting"
}
}WebSocket 서버는 루트 경로 ws://your-server:3000/ 에서 사용할 수 있습니다.
WebSocket 프로토콜 메시지에 대한 자세한 내용은 코드나 예제 디렉토리를 참조하세요.
완전한 클라이언트 구현을 보려면 examples 디렉토리의 Arduino 스케치를 참조하세요.
Arduino IDE에 필요한 라이브러리를 설치하세요:
ESP8266WiFi
웹소켓클라이언트
아두이노Json
WiFi 및 서버 설정으로 스케치를 구성하세요.
// 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;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기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
저장소를 포크하세요
기능 브랜치를 생성합니다( git checkout -b feature/amazing-feature )
변경 사항을 커밋하세요( git commit -m 'Add some amazing feature' )
브랜치에 푸시( git push origin feature/amazing-feature )
풀 리퀘스트 열기
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
MIT 라이선스는 다음 작업을 허용하는 허용적 라이선스입니다.
소프트웨어를 상업적으로 사용하세요
소프트웨어 수정
소프트웨어 배포
소프트웨어를 개인적으로 사용하고 수정합니다.
유일한 요구 사항은 소프트웨어에 라이센스와 저작권 고지가 포함되어야 한다는 것입니다.
통합 사양을 위한 모델 컨텍스트 프로토콜
놀라운 IoT 플랫폼을 위한 NodeMCU
클로드 데스크탑을 위한 인류학
| 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. Dates show when Glama detected each change.
v1.0.0get-devicelist-devicessend-commandupdate-configEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Model Context Protocol server for Studex tools, notifications, and profile integrations
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/amanasmuei/mcp-server-nodemcu'
If you have feedback or need assistance with the MCP directory API, please join our Discord server