Skip to main content
Glama
enesjakozh
Benniu

emqx-mcp-server

by Benniu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Servidor MCP EMQX

insignia de herrería

Una implementación de servidor del Protocolo de Contexto de Modelo (MCP) que permite la interacción con el agente MQTT de EMQX. Permite a los clientes MCP interactuar con los clústeres MQTT en EMQX Cloud o en clústeres alojados por ellos mismos.

Características

Gestión de clientes MQTT

  • Listado de clientes: vea todos los clientes MQTT conectados con opciones de filtrado flexibles

  • Información del cliente: recupera información detallada sobre clientes específicos

  • Control de conexión: desconecte del bróker a los clientes problemáticos o inactivos

  • Filtrado flexible: filtre clientes por nodo, nombre de usuario, ID de cliente, estado de conexión y más

Publicación de mensajes MQTT

  • Publicación basada en temas: envía mensajes a cualquier tema MQTT

  • Control de QoS: seleccione el nivel de calidad de servicio (0, 1 o 2) para una entrega confiable

  • Retención de mensajes: opción para conservar los mensajes para los nuevos suscriptores

  • Cargas útiles personalizadas: compatibilidad con cualquier formato de contenido de mensajes

Related MCP server: MCP REST API Server

Herramientas

lista_clientes_mqtt

  • Enumere los clientes MQTT conectados a su clúster EMQX

  • Entradas:

    • página (número, opcional): Número de página (predeterminado: 1)

    • límite (número, opcional): Resultados por página (predeterminado: 100, máximo 10000)

    • nodo (cadena, opcional): filtrar por nombre de nodo específico

    • clientid (cadena, opcional): Filtrar por ID de cliente específico

    • nombre de usuario (cadena, opcional): filtrar por nombre de usuario específico

    • ip_address (cadena, opcional): Filtrar por dirección IP del cliente

    • conn_state (cadena, opcional): Filtrar por estado de conexión

    • clean_start (booleano, opcional): Filtrar por indicador de inicio limpio

    • proto_ver (cadena, opcional): Filtrar por versión del protocolo

    • like_clientid (cadena, opcional): Búsqueda difusa por patrón de ID de cliente

    • like_username (cadena, opcional): búsqueda difusa por patrón de nombre de usuario

    • like_ip_address (cadena, opcional): Búsqueda difusa por patrón de dirección IP

obtener_cliente_mqtt

  • Obtenga información detallada sobre un cliente MQTT específico por ID de cliente

  • Entradas:

    • clientid (cadena, obligatoria): el identificador único del cliente a recuperar

cliente kick_mqtt

  • Desconectar un cliente del agente MQTT por ID de cliente

  • Entradas:

    • clientid (cadena, obligatoria): el identificador único del cliente que se desconectará

publicar_mensaje_mqtt

  • Publicar un mensaje MQTT en su clúster EMQX en EMQX Cloud o en una implementación autoadministrada

  • Entradas:

    • tema (cadena, obligatorio): tema MQTT en el que publicar

    • carga útil (cadena, obligatoria): contenido del mensaje a publicar

    • qos (número, opcional): nivel de calidad de servicio (0, 1 o 2) (valor predeterminado: 0)

    • retener (booleano, opcional): si se debe conservar el mensaje (valor predeterminado: falso)

Configurar el clúster EMQX

Antes de usar las herramientas del servidor EMQX MCP, debe configurar un clúster EMQX con la clave API y la autenticación de cliente correctamente configuradas. Existen varias opciones:

  1. Implementación sin servidor en la nube de EMQX:

  • La forma más fácil de empezar.

  • Obtenga una implementación sin servidor gratuita de EMQX Cloud

  • Regístrese en EMQX Cloud Serverless

  1. Implementación dedicada en la nube de EMQX:

  • Proporciona recursos dedicados para cargas de trabajo de producción

  • Ofrece un rendimiento mejorado, confiabilidad y opciones de personalización.

  • Admite varios proveedores de nube (AWS, GCP, Azure)

  • Incluye SLA y soporte profesional

  • Crear una implementación en EMQX Cloud Dedicated

  1. Plataforma EMQX autohospedada:

  • Descargue e implemente la plataforma EMQX localmente

  • Siga las instrucciones de instalación en la Plataforma EMQX

Ejecutándose localmente con la aplicación de escritorio Claude

Opción 1: Instalación mediante herrería

Para instalar emqx-mcp-server para Claude Desktop automáticamente a través de Smithery :

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

Opción 2: Docker

  1. Instale la aplicación de escritorio Claude si aún no lo ha hecho.

  2. Tire de la imagen:

    docker pull benniuji/emqx-mcp-server

  3. Agregue lo siguiente a su archivo claude_desktop_config.json :

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

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

    Nota: Actualice las variables de entorno: EMQX_API_URL , EMQX_API_KEY , EMQX_API_SECRET

  4. Abrir o reiniciar la aplicación Claude Desktop

  5. Intenta pedirle a Claude que haga algo con el agente MQTT (por ejemplo, pedirle que publique un mensaje MQTT en un tema).

Opción 3: Instalación manual

Primero, asegúrate de tener instalado el ejecutable uv . De lo contrario, puedes instalarlo siguiendo las instrucciones aquí .

  1. Instale la aplicación de escritorio Claude si aún no lo ha hecho.

  2. Clonar este repositorio.

  3. Agregue lo siguiente a su archivo claude_desktop_config.json :

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

    • En Windows: %APPDATA%/Claude/claude_desktop_config.json GXP4

    Nota: asegúrese de actualizar path/to/repo/src/emqx_mcp_server a la ruta real y modificar las variables de entorno EMQX_API_URL , EMQX_API_KEY y EMQX_API_SECRET para que coincidan con su instancia de EMQX.

  4. Abrir o reiniciar la aplicación Claude Desktop

  5. Intenta pedirle a Claude que haga algo con el agente MQTT (por ejemplo, pedirle que publique un mensaje MQTT en un tema).

Ejemplos de indicaciones

Usuario:

Please list the clients connected to the MQTT broker.

Maestría en Derecho:

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?

Usuario:

Yes, please provide the detail info of this client.

Maestría en Derecho:

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?

Usuario:

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

Maestría en Derecho:

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?

Usuario:

Please kick out the client mqttx_2232bdb1

Maestría en Derecho

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?

Licencia

Este proyecto está licenciado bajo la licencia Apache versión 2.0: consulte el archivo de LICENCIA para obtener más detalles.

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