Skip to main content
Glama
enesjakozh
Benniu

emqx-mcp-server

by Benniu
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

EMQX MCP Server

A Model Context Protocol (MCP) server implementation that provides EMQX MQTT broker interaction. Enabling MCP clients to interact with the MQTT clusters on EMQX Cloud or self-hosted clusters

Features

MQTT Client Management

  • Client Listing: View all connected MQTT clients with flexible filtering options

  • Client Information: Retrieve detailed information about specific clients

  • Connection Control: Disconnect problematic or stale clients from the broker

  • Flexible Filtering: Filter clients by node, username, client ID, connection state, and more

MQTT Message Publishing

  • Topic-based Publishing: Send messages to any MQTT topics

  • QoS Control: Select Quality of Service level (0, 1, or 2) for reliable delivery

  • Message Retention: Option to persist messages for new subscribers

  • Custom Payloads: Support for any message content format

MQTT Topic Subscription (SSE)

  • Real-time Subscription: Subscribe to MQTT topics via Server-Sent Events (SSE)

  • Duration Control: Configure how long to listen for messages (1-300 seconds)

  • Message Limiting: Set maximum number of messages to collect per subscription

  • Automatic Parsing: Messages are automatically parsed from SSE event stream

Related MCP server: MCP REST API Server

Tools

list_mqtt_clients

  • List MQTT clients connected to your EMQX Cluster

  • Inputs:

    • page (number, optional): Page number (default: 1)

    • limit (number, optional): Results per page (default: 100, max 10000)

    • node (string, optional): Filter by specific node name

    • clientid (string, optional): Filter by specific client ID

    • username (string, optional): Filter by specific username

    • ip_address (string, optional): Filter by client IP address

    • conn_state (string, optional): Filter by connection state

    • clean_start (boolean, optional): Filter by clean start flag

    • proto_ver (string, optional): Filter by protocol version

    • like_clientid (string, optional): Fuzzy search by client ID pattern

    • like_username (string, optional): Fuzzy search by username pattern

    • like_ip_address (string, optional): Fuzzy search by IP address pattern

get_mqtt_client

  • Get detailed information about a specific MQTT client by client ID

  • Inputs:

    • clientid (string, required): The unique identifier of the client to retrieve

kick_mqtt_client

  • Disconnect a client from the MQTT broker by client ID

  • Inputs:

    • clientid (string, required): The unique identifier of the client to disconnect

publish_mqtt_message

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

  • Inputs:

    • topic (string, required): MQTT topic to publish to

    • payload (string, required): Message content to publish

    • qos (number, optional): Quality of Service level (0, 1, or 2) (default: 0)

    • retain (boolean, optional): Whether to retain the message (default: false)

subscribe_mqtt_topic

  • Subscribe to an MQTT topic via SSE on EMQX Cloud and collect messages for a specified duration

  • Inputs:

    • topic (string, required): MQTT topic to subscribe to

    • duration (number, optional): How long to listen in seconds (1-300, default: 30)

    • max_messages (number, optional): Maximum messages to collect (1-1000, default: 100)

  • Returns: Object containing topic, message_count, and messages array

Setup EMQX Cluster

Before using the EMQX MCP Server tools, you need to set up an EMQX cluster with properly configured API Key and client authentication. There are several options:

  1. EMQX Cloud Serverless Deployment:

  • The easiest way to get started with.

  • Obtain a free serverless deployment from EMQX Cloud

  • Sign up at EMQX Cloud Serverless

  1. EMQX Cloud Dedicated Deployment:

  • Provides dedicated resources for production workloads

  • Offers enhanced performance, reliability, and customization options

  • Supports various cloud providers (AWS, GCP, Azure)

  • Includes professional SLA and support

  • Create a deployment at EMQX Cloud Dedicated

  1. Self-hosted EMQX Platform:

  • Download and deploy EMQX Platform locally

  • Follow installation instructions at EMQX Platform

Note: The subscribe_mqtt_topic tool uses the SSE (Server-Sent Events) endpoint, which is available on EMQX Cloud deployments. Not all self-hosted EMQX deployments support the SSE subscribe endpoint.

Running locally with the Claude Desktop App

Option 1: Installing via Smithery

To install emqx-mcp-server for Claude Desktop automatically via Smithery:

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

Option 2: Docker

  1. Install Claude Desktop App if you haven't done so yet.

  2. Pull the image:

    docker pull benniuji/emqx-mcp-server

  3. Add the following to your claude_desktop_config.json file:

    • On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json

    • On 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"
      ]
    }
  }
}

    Note: Update the env variables:EMQX_API_URL, EMQX_API_KEY, EMQX_API_SECRET

  4. Open or Restart Claude Desktop App

  5. Try asking Claude to do something with the MQTT broker (e.g. ask it to publish an MQTT message to a topic).

Option 3: Manual Installation

First, ensure you have the uv executable installed. If not, you can install it by following the instructions here.

  1. Install Claude Desktop App if you haven't done so yet.

  2. Clone this repository.

  3. Add the following to your claude_desktop_config.json file:

    • On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json

    • On Windows: %APPDATA%/Claude/claude_desktop_config.json

    {
  "mcpServers": {
    "EMQX_MCP_Server": {
      "command": "uv",
      "args": [
        "--directory",
        "path/to/repo/src/emqx_mcp_server",
        "run",
        "emqx-mcp-server"
      ],
      "env":{
        "EMQX_API_URL":"https://your-emqx-cloud-instance.com:8443/api/v5",
        "EMQX_API_KEY":"<YOUR-API-KEY>",
        "EMQX_API_SECRET":"<YOUR-API-SECRET>"
      }
    }
  }
}

    Note: Make sure to update path/to/repo/src/emqx_mcp_server to the actual path and modify the environment variables EMQX_API_URL, EMQX_API_KEY, and EMQX_API_SECRET to match your EMQX instance.

  4. Open or Restart Claude Desktop App

  5. Try asking Claude to do something with the MQTT broker (e.g. ask it to publish an MQTT message to a topic).

Example Prompts

User: 

Please list the clients connected to the MQTT broker.

LLM: 

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?

User: 

Yes, please provide the detail info of this client.

LLM: 

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?

User: 

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

LLM: 

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?

User:

Please subscribe to the topic 'sensor/temperature' for 10 seconds and show me the messages.

LLM:

I'll subscribe to the topic 'sensor/temperature' for 10 seconds to collect messages.
...
I received 3 messages from topic 'sensor/temperature' during the 10-second subscription:

1. {"temperature": 23.5, "unit": "celsius", "timestamp": "2025-03-02T10:00:01Z"}
2. {"temperature": 23.6, "unit": "celsius", "timestamp": "2025-03-02T10:00:04Z"}
3. {"temperature": 23.4, "unit": "celsius", "timestamp": "2025-03-02T10:00:07Z"}

Would you like to subscribe for a longer duration or take any other action?

User:

Please kick out the client mqttx_2232bdb1

LLM

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?

License

This project is licensed under the Apache License Version 2.0 - see the LICENSE file for details.

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Benniu/emqx-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server