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 を自動的にインストールするには:
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 .例に基づいて.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]このプロジェクトでは、公式の Model Context Protocol (MCP) TypeScript SDK を使用して、Claude for Desktop およびその他の MCP クライアントとの統合を提供します。
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 for Desktop を構成します。
{
"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
WebSocketクライアント
ArduinoJson
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 ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
MIT ライセンスは、次のことを許可する許容ライセンスです。
ソフトウェアを商用利用する
ソフトウェアを変更する
ソフトウェアを配布する
ソフトウェアを個人的に使用および変更する
唯一の要件は、ライセンスと著作権表示がソフトウェアに含まれている必要があることです。
統合仕様のためのモデルコンテキストプロトコル
驚異的なIoTプラットフォームのためのNodeMCU
クロード・デスクトップのAnthropic
| 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.