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 客户端

  • 输入：

    • page（数字，可选）：页码（默认值：1）

    • limit（数字，可选）：每页结果数（默认值：100，最大 10000）

    • 节点（字符串，可选）：按特定节点名称过滤

    • clientid（字符串，可选）：按特定客户端 ID 进行过滤

    • 用户名（字符串，可选）：按特定用户名过滤

    • ip_address（字符串，可选）：按客户端 IP 地址过滤

    • conn_state（字符串，可选）：按连接状态过滤

    • clean_start（布尔值，可选）：按干净启动标志过滤

    • proto_ver（字符串，可选）：按协议版本过滤

    • like_clientid (string，可选)：按客户端 ID 模式进行模糊搜索

    • like_username（字符串，可选）：按用户名模式模糊搜索

    • like_ip_address（字符串，可选）：按 IP 地址模式进行模糊搜索

获取mqtt客户端

  • 通过客户端 ID 获取特定 MQTT 客户端的详细信息

  • 输入：

    • clientid（字符串，必需）：要检索的客户端的唯一标识符

kick_mqtt_客户端

  • 根据客户端 ID 断开客户端与 MQTT 代理的连接

  • 输入：

    • clientid（字符串，必需）：要断开连接的客户端的唯一标识符

发布_mqtt_消息

  • 在 EMQX 云或自管理部署上向 EMQX 集群发布 MQTT 消息

  • 输入：

    • topic（字符串，必需）：要发布的 MQTT 主题

    • 有效载荷（字符串，必需）：要发布的消息内容

    • qos（数字，可选）：服务质量级别（0、1 或 2）（默认值：0）

    • retain（布尔值，可选）：是否保留消息（默认值：false）

设置 EMQX 集群

在使用 EMQX MCP 服务器工具之前，您需要搭建一个 EMQX 集群，并正确配置 API 密钥和客户端身份验证。有以下几种选择：

  1. EMQX Cloud 无服务器部署：

  • 最简单的入门方法。

  • 从 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 许可证版本 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