Skip to main content
Glama
enesjakozh
Benniu

emqx-mcp-server

by Benniu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

EMQX MCP 서버

대장간 배지

EMQX MQTT 브로커 상호작용을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버 구현입니다. MCP 클라이언트가 EMQX 클라우드 또는 자체 호스팅 클러스터의 MQTT 클러스터와 상호작용할 수 있도록 지원합니다.

특징

MQTT 클라이언트 관리

  • 클라이언트 목록: 유연한 필터링 옵션을 통해 연결된 모든 MQTT 클라이언트를 확인하세요.

  • 클라이언트 정보: 특정 클라이언트에 대한 자세한 정보를 검색합니다.

  • 연결 제어: 문제가 있거나 오래된 클라이언트를 브로커에서 연결 해제합니다.

  • 유연한 필터링: 노드, 사용자 이름, 클라이언트 ID, 연결 상태 등을 기준으로 클라이언트 필터링

MQTT 메시지 게시

  • 주제 기반 게시: 모든 MQTT 주제에 메시지 보내기

  • QoS 제어: 안정적인 전달을 위해 서비스 품질 수준(0, 1 또는 2)을 선택합니다.

  • 메시지 보존: 새 구독자에게 메시지를 보존하는 옵션

  • 사용자 정의 페이로드: 모든 메시지 콘텐츠 형식 지원

Related MCP server: MCP REST API Server

도구

리스트_mqtt_클라이언트

  • EMQX 클러스터에 연결된 MQTT 클라이언트 나열

  • 입력:

    • 페이지(번호, 선택 사항): 페이지 번호(기본값: 1)

    • limit(숫자, 선택 사항): 페이지당 결과(기본값: 100, 최대 10000)

    • node(문자열, 선택 사항): 특정 노드 이름으로 필터링

    • clientid(문자열, 선택 사항): 특정 클라이언트 ID로 필터링

    • 사용자 이름(문자열, 선택 사항): 특정 사용자 이름으로 필터링

    • ip_address(문자열, 선택 사항): 클라이언트 IP 주소로 필터링

    • conn_state(문자열, 선택 사항): 연결 상태로 필터링

    • clean_start(부울, 선택 사항): clean start 플래그로 필터링

    • proto_ver(문자열, 선택 사항): 프로토콜 버전으로 필터링

    • like_clientid(문자열, 선택 사항): 클라이언트 ID 패턴으로 퍼지 검색

    • like_username(문자열, 선택 사항): 사용자 이름 패턴으로 퍼지 검색

    • like_ip_address(문자열, 선택 사항): IP 주소 패턴으로 퍼지 검색

get_mqtt_client

  • 클라이언트 ID로 특정 MQTT 클라이언트에 대한 자세한 정보를 얻으세요

  • 입력:

    • clientid(문자열, 필수): 검색할 클라이언트의 고유 식별자

kick_mqtt_클라이언트

  • 클라이언트 ID로 MQTT 브로커에서 클라이언트 연결 해제

  • 입력:

    • clientid(문자열, 필수): 연결을 끊을 클라이언트의 고유 식별자

MQTT 메시지 게시

  • EMQX 클라우드 또는 자체 관리 배포에서 EMQX 클러스터에 MQTT 메시지 게시

  • 입력:

    • 주제(문자열, 필수): 게시할 MQTT 주제

    • payload(문자열, 필수): 게시할 메시지 내용

    • 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 Desktop App을 사용하여 로컬로 실행

옵션 1: Smithery를 통해 설치

Smithery를 통해 Claude Desktop에 emqx-mcp-server를 자동으로 설치하려면:

지엑스피1

옵션 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"
      ]
    }
  }
}

    참고: env 변수를 업데이트하세요: 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.

법학 석사(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?

사용자:

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?

사용자:

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?

사용자:

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