Skip to main content
Glama
enesjakozh
Benniu

emqx-mcp-server

by Benniu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

EMQX MCP サーバー

鍛冶屋のバッジ

EMQX MQTTブローカーとの連携を可能にするモデルコンテキストプロトコル（MCP）サーバー実装。MCPクライアントがEMQX Cloudまたはセルフホスト型クラスター上のMQTTクラスターと連携できるようにします。

特徴

MQTTクライアント管理

  • クライアントリスト: 柔軟なフィルタリングオプションを使用して、接続されているすべての MQTT クライアントを表示します。

  • クライアント情報: 特定のクライアントに関する詳細情報を取得します

  • 接続制御: 問題のあるクライアントや古いクライアントをブローカーから切断します

  • 柔軟なフィルタリング: ノード、ユーザー名、クライアント ID、接続状態などでクライアントをフィルタリングします。

MQTT メッセージパブリッシング

  • トピックベースのパブリッシング:任意のMQTTトピックにメッセージを送信します

  • QoS制御: 信頼性の高い配信のためにサービス品質レベル（0、1、または2）を選択します。

  • メッセージの保持: 新規購読者へのメッセージを保持するオプション

  • カスタムペイロード: あらゆるメッセージコンテンツ形式をサポート

Related MCP server: MCP REST API Server

ツール

リスト_mqtt_クライアント

  • EMQX クラスターに接続されている MQTT クライアントを一覧表示します

  • 入力:

    • ページ（数値、オプション）：ページ番号（デフォルト：1）

    • 制限（数値、オプション）：1ページあたりの結果数（デフォルト：100、最大10000）

    • node (文字列、オプション): 特定のノード名でフィルタリング

    • clientid (文字列、オプション): 特定のクライアントIDでフィルタリング

    • ユーザー名（文字列、オプション）：特定のユーザー名でフィルタリング

    • ip_address (文字列、オプション): クライアントのIPアドレスでフィルタリング

    • conn_state (文字列、オプション): 接続状態でフィルタリングする

    • clean_start (ブール値、オプション): クリーンスタートフラグでフィルタリング

    • proto_ver (文字列、オプション): プロトコルバージョンでフィルタリング

    • like_clientid (文字列、オプション): クライアントIDパターンによるあいまい検索

    • like_username (文字列、オプション): ユーザー名パターンによるあいまい検索

    • like_ip_address (文字列、オプション): IPアドレスパターンによるあいまい検索

get_mqtt_client

  • クライアントIDで特定のMQTTクライアントの詳細情報を取得します

  • 入力:

    • clientid (文字列、必須): 取得するクライアントの一意の識別子

kick_mqtt_client

  • クライアントIDでMQTTブローカーからクライアントを切断する

  • 入力:

    • clientid (文字列、必須): 切断するクライアントの一意の識別子

publish_mqtt_メッセージ

  • EMQX クラウドまたはセルフマネージド デプロイメント上の EMQX クラスターに MQTT メッセージをパブリッシュする

  • 入力:

    • topic (文字列、必須): 公開先のMQTTトピック

    • ペイロード（文字列、必須）: 公開するメッセージの内容

    • qos (数値、オプション): サービス品質レベル (0、1、または 2) (デフォルト: 0)

    • retain（ブール値、オプション）：メッセージを保持するかどうか（デフォルト：false）

EMQXクラスターのセットアップ

EMQX MCPサーバーツールを使用する前に、APIキーとクライアント認証を適切に設定したEMQXクラスターをセットアップする必要があります。いくつかのオプションがあります。

  1. EMQX クラウド サーバーレス デプロイメント:

  • 始めるのに最も簡単な方法。

  • EMQX Cloudから無料のサーバーレスデプロイメントを入手する

  • EMQX Cloud Serverlessにサインアップ

  1. EMQX クラウド専用展開:

  • 本番環境のワークロードに専用のリソースを提供する

  • 強化されたパフォーマンス、信頼性、カスタマイズオプションを提供

  • さまざまなクラウドプロバイダー（AWS、GCP、Azure）をサポート

  • プロフェッショナルなSLAとサポートが含まれています

  • EMQX Cloud Dedicatedでデプロイメントを作成する

  1. セルフホスト型 EMQX プラットフォーム:

  • EMQXプラットフォームをローカルにダウンロードして展開する

  • EMQXプラットフォームのインストール手順に従ってください。

Claudeデスクトップアプリでローカルで実行する

オプション1: Smithery経由でインストールする

Smithery経由で Claude Desktop 用の emqx-mcp-server を自動的にインストールするには:

npx -y @smithery/cli install @Benniu/emqx-mcp-server --client claude

オプション2: Docker

  1. Claude デスクトップ アプリをまだインストールしていない場合はインストールしてください。

  2. イメージをプルします:

    docker pull benniuji/emqx-mcp-server

  3. claude_desktop_config.jsonファイルに次の内容を追加します。

    • MacOSの場合: ~/Library/Application\ Support/Claude/claude_desktop_config.json

    • Windows の場合: %APPDATA%/Claude/claude_desktop_config.json

    {
  "mcpServers": {
    "EMQX_MCP_Server": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e", "EMQX_API_URL=https://your-emqx-cloud-instance.com:8443/api/v5",
        "-e", "EMQX_API_KEY=<YOUR-API-KEY>",
        "-e", "EMQX_API_SECRET=<YOUR-API-SECRET>",
        "benniuji/emqx-mcp-server"
      ]
    }
  }
}

    注: 環境変数EMQX_API_URL 、 EMQX_API_KEY 、 EMQX_API_SECRETを更新してください。

  4. Claudeデスクトップアプリを開くか再起動する

  5. Claude に MQTT ブローカーで何かを実行するように依頼してみてください (たとえば、トピックに MQTT メッセージを公開するように依頼します)。

オプション3: 手動インストール

まず、 uv実行ファイルがインストールされていることを確認してください。まだインストールされていない場合は、こちらの手順に従ってインストールできます。

  1. Claude デスクトップ アプリをまだインストールしていない場合はインストールしてください。

  2. このリポジトリをクローンします。

  3. claude_desktop_config.jsonファイルに次の内容を追加します。

    • MacOSの場合: ~/Library/Application\ Support/Claude/claude_desktop_config.json

    • Windowsの場合: %APPDATA%/Claude/claude_desktop_config.json GXP4

    注意: path/to/repo/src/emqx_mcp_server実際のパスに更新し、環境変数EMQX_API_URL 、 EMQX_API_KEY 、およびEMQX_API_SECRETを EMQX インスタンスに合わせて変更してください。

  4. Claudeデスクトップアプリを開くか再起動する

  5. Claude に MQTT ブローカーで何かを実行するように依頼してみてください (たとえば、トピックに MQTT メッセージを公開するように依頼します)。

プロンプトの例

ユーザー：

Please list the clients connected to the MQTT broker.

法学修士:

Here are the clients currently connected to your MQTT broker:
Connected Client:
  - Client ID: mqttx_2232bdb1
  - Username: test
  - Protocol: MQTT v5
  ...
There is currently 1 client connected to your MQTT broker. Would you like more detailed information about this specific client or would you like to perform another action with your MQTT broker?

ユーザー：

Yes, please provide the detail info of this client.

法学修士:

I'll retrieve the detailed information for this client for you.
...
Here's the detailed information for client "mqttx_2232bdb1":

**Basic Information:**
-   **Client ID:** mqttx_2232bdb1
-   **Username:** test
...
**Connection Details:**
-   **Connected:** Yes
-   **Created At:** 2025-03-02T05:29:51.103+00:00
...
Would you like to perform any actions with this client, such as publishing a message to a topic or disconnecting the client?

ユーザー：

Please write a poem and send it to the topic '/poem' with QoS 1.

法学修士:

I'll create a poem and publish it to the topic '/poem' with QoS 1. Let me do that for you.
...
I've successfully published the poem to the topic '/poem' with QoS 1. The message has been delivered with ID: 00062F55A1EFB1156ABC481240B30000.

The poem I sent was:

- Signals in the ether,
- Invisible threads that bind,
- Devices speak in whispers,
- Across the digital divide.
- Messages like leaves falling,
- From cloud to waiting ground,
- Connected yet untethered,
- Where silence makes no sound.
- Brokers of the modern age,
- Routing dreams from here to there,
- In this web of connections,
- We find ourselves everywhere.
- Like stars in constellation,
- Each point of light has worth,
- The language of machines,
- Redefining our Earth.

Is there anything else you'd like to do with your MQTT broker?

ユーザー：

Please kick out the client mqttx_2232bdb1

法学修士

I'll disconnect the client from the MQTT broker for you.
...
The client has been successfully disconnected. The system returned:
> Client mqttx_2232bdb1 has been disconnected
The MQTT client with ID "mqttx_2232bdb1" is now disconnected from your broker. Is there anything else you would like to do with your MQTT broker?

ライセンス

このプロジェクトは、Apache License バージョン 2.0 に基づいてライセンスされています。詳細については、 LICENSEファイルを参照してください。

Available Tools

4 tools
get_mqtt_clientC

Get detailed information about a specific MQTT client by client ID

ParametersJSON Schema
NameRequiredDescriptionDefault
requestYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get detailed information'), which implies it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what 'detailed information' includes (e.g., connection status, subscriptions). This is a significant gap for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a read operation with 1 parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' returns, error handling, or parameter details, leaving the agent with insufficient context to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 1 parameter ('request') with 0% description coverage, and the description doesn't add any parameter-specific information. It mentions 'by client ID', which hints that the parameter might be a client ID, but doesn't clarify the parameter name, format, or constraints, failing to compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get detailed information') and resource ('about a specific MQTT client by client ID'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_mqtt_clients' (which likely lists multiple clients vs. getting details for one), so it misses the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'list_mqtt_clients' or 'kick_mqtt_client'. It mentions 'by client ID' but doesn't specify prerequisites or contexts, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kick_mqtt_clientC

Disconnect a client from the MQTT broker by client ID

ParametersJSON Schema
NameRequiredDescriptionDefault
requestYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is destructive (likely yes), requires specific permissions, has side effects (e.g., message loss), rate limits, or error conditions (e.g., invalid client ID).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive action, 1 parameter), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It fails to address key aspects like parameter meaning, behavioral traits, or expected outcomes, leaving significant gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no parameter semantics beyond the schema. It mentions 'by client ID' but doesn't clarify that the 'request' parameter is the client ID, its format, or constraints, leaving the single required parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Disconnect') and target resource ('a client from the MQTT broker by client ID'). It distinguishes from siblings like 'get_mqtt_client' (retrieve) and 'list_mqtt_clients' (enumerate) by focusing on termination of connections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., client must be connected), exclusions, or compare with sibling tools like 'publish_mqtt_message' for messaging versus disconnection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_mqtt_clientsC

List MQTT clients connected to your EMQX Cluster

ParametersJSON Schema
NameRequiredDescriptionDefault
requestYes

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists clients but doesn't describe how it behaves—e.g., whether it returns all clients or paginated results, if it requires authentication, what the output format is, or any rate limits. This leaves significant gaps for an agent to understand the tool's operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse, though its brevity contributes to gaps in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a listing operation with one undocumented parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter usage, behavioral details, or output expectations, making it insufficient for an agent to effectively invoke the tool without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter ('request') with 0% description coverage, and the tool description provides no information about parameters. It doesn't explain what 'request' should contain (e.g., filtering criteria, pagination options) or its format, leaving the parameter entirely undocumented and unusable without external knowledge.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('MQTT clients connected to your EMQX Cluster'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_mqtt_client' (which likely retrieves a single client) or mention the scope of listing (e.g., all clients vs. filtered).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'list_mqtt_clients' over 'get_mqtt_client' (e.g., for bulk retrieval vs. single client details) or 'kick_mqtt_client' (for management actions). There's also no context on prerequisites or limitations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

publish_mqtt_messageC

Publish an MQTT Message to Your EMQX Cluster on EMQX Cloud or Self-Managed Deployment

ParametersJSON Schema
NameRequiredDescriptionDefault
requestYes

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the action ('Publish') which implies a write operation, but doesn't disclose behavioral traits like whether this requires authentication, what happens on failure, rate limits, or if messages are persistent. The description is minimal and lacks crucial operational context for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with critical usage information. No wasted verbiage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what the 'request' parameter should contain, what happens after publishing, potential error conditions, or return values. The agent lacks sufficient context to use this tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions publishing a message but provides no information about the 'request' parameter - what format it should be in (JSON, string), what content it should contain, or examples. The description adds minimal value beyond the schema's structural definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Publish') and resource ('MQTT Message') with specific deployment targets ('EMQX Cluster on EMQX Cloud or Self-Managed Deployment'). However, it doesn't explicitly distinguish this tool from its siblings (get_mqtt_client, kick_mqtt_client, list_mqtt_clients), which all operate on MQTT clients rather than messages. The purpose is clear but lacks sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active MQTT connection), exclusions, or how it relates to the sibling tools. The deployment context is stated but doesn't help the agent decide when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • First observedget_mqtt_client
    • First observedkick_mqtt_client
    • First observedlist_mqtt_clients
    • First observedpublish_mqtt_message
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting different aspects of MQTT client and message management. get_mqtt_client retrieves details, kick_mqtt_client disconnects, list_mqtt_clients enumerates connections, and publish_mqtt_message sends messages, with no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, using clear verbs like get, kick, list, and publish paired with descriptive nouns (mqtt_client, mqtt_message). This makes the tool set predictable and easy to understand.

Tool Count4/5

Four tools are reasonable for an MQTT management server, covering core operations like client monitoring and message publishing. However, the count feels slightly thin, as it lacks tools for broader broker management (e.g., topic subscriptions or configuration), but it's well-scoped for its purpose.

Completeness3/5

The tools cover client management (list, get, kick) and message publishing, but there are notable gaps in the MQTT domain. Missing operations include subscribing to topics, managing topics, or handling broker settings, which could limit agent workflows for comprehensive MQTT interactions.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • MCP REST API Server

    vinaykp
    F
    license
    Not graded
    quality
    D
    maintenance
    A server implementation of the Model Context Protocol (MCP) that provides REST API endpoints for managing and interacting with MCP resources.
    -

  • MCP Server

    stelang
    A
    license
    Not graded
    quality
    D
    maintenance
    An implementation of the Model Context Protocol (MCP) server that enables multiple clients to connect simultaneously and handles basic context management and messaging with an extendable architecture.
    MIT

  • mcp2mqtt

    swesmith-repos
    A
    license
    B
    quality
    Not graded
    maintenance
    An MCP server that bridges the physical world and AI models by enabling natural language control of IoT hardware via the MQTT protocol. It supports real-time device monitoring, command publishing, and response handling for seamless integration between AI clients and physical devices.
    3
    MIT

Appeared in Searches