OMNI-MQTT-MCP
[](https://mseep.ai/app/omniscience-labs-omni-mqtt-mcp)
# OMNI-MQTT-MCP
MQTT MCP Server with configurable transport options via CLI: **STDIO** (default), **Streamable HTTP** (recommended for web), and **SSE** (deprecated).
## ๐ Quick Start
```bash
# Install dependencies
pip install -r requirements.txt
# Run with STDIO (default - for local development)
python mqtt_mcp_server.py
# Run with Streamable HTTP (recommended for web)
python mqtt_mcp_server.py --transport streamable-http
# Run with SSE (deprecated)
python mqtt_mcp_server.py --transport sse
```
## ๐ Transport Options
Choose your transport with the `--transport` CLI argument:
### 1. **STDIO Transport** (Default) โ
```bash
python mqtt_mcp_server.py --transport stdio
# or simply:
python mqtt_mcp_server.py
```
- **Best for**: Local development, Claude Desktop integration
- **Pros**: Simple, secure, works with MCP clients like Claude Desktop
- **Cons**: Local only, no remote access
### 2. **Streamable HTTP** (Recommended for Web) ๐
```bash
python mqtt_mcp_server.py --transport streamable-http
python mqtt_mcp_server.py --transport streamable-http --host 0.0.0.0 --http-port 9000
```
- **Best for**: Web deployments, remote access, microservices
- **Default URL**: `http://127.0.0.1:8000/mcp`
- **Pros**: Modern, efficient, supports multiple clients, easy deployment
- **Cons**: Requires network setup, security considerations
### 3. **SSE (Server-Sent Events)** โ ๏ธ Deprecated
```bash
python mqtt_mcp_server.py --transport sse
```
- **Best for**: Legacy deployments (not recommended for new projects)
- **Default URL**: `http://127.0.0.1:8000/sse`
- **Status**: Being phased out in favor of Streamable HTTP
## ๐ Available Tools
- **`mqtt_publish`**: Publish messages to MQTT topics
- **`mqtt_subscribe`**: Subscribe to MQTT topics and receive messages
## โ๏ธ Configuration Options
### MQTT Configuration
```bash
python mqtt_mcp_server.py \
--broker localhost \
--port 1883 \
--client-id mcp-mqtt-client \
--username your_username \
--password your_password
```
### Transport Configuration
```bash
python mqtt_mcp_server.py \
--transport streamable-http \
--host 127.0.0.1 \
--http-port 8000 \
--path /mcp
```
### All Options
```bash
python mqtt_mcp_server.py --help
```
### Environment Variables
You can also use environment variables for MQTT settings:
```bash
export MQTT_BROKER_ADDRESS=localhost
export MQTT_PORT=1883
export MQTT_CLIENT_ID=mcp-mqtt-client
export MQTT_USERNAME=your_username
export MQTT_PASSWORD=your_password
python mqtt_mcp_server.py --transport streamable-http
```
## ๐งช Testing
### Test HTTP Server
```bash
# Terminal 1: Start server
python mqtt_mcp_server.py --transport streamable-http
# Terminal 2: Test it
python test_http_client.py
```
### Test with Claude Desktop
Add to your Claude Desktop MCP configuration:
```json
{
"mcpServers": {
"mqtt": {
"command": "python",
"args": ["/path/to/mqtt_mcp_server.py"],
"env": {
"MQTT_BROKER_ADDRESS": "localhost",
"MQTT_PORT": "1883"
}
}
}
}
```
## ๐ง Development
### Using the MCP CLI
```bash
# Run in development mode with MCP Inspector
mcp dev mqtt_mcp_server.py
# Run with specific transport via MCP CLI
mcp run mqtt_mcp_server.py -- --transport streamable-http --http-port 9000
```
## ๐ Examples
### Local Development
```bash
# Default STDIO for Claude Desktop
python mqtt_mcp_server.py
```
### Web Deployment
```bash
# HTTP server on port 8000
python mqtt_mcp_server.py --transport streamable-http
# HTTP server on custom port and host
python mqtt_mcp_server.py --transport streamable-http --host 0.0.0.0 --http-port 9000
# Custom path
python mqtt_mcp_server.py --transport streamable-http --path /api/mcp
```
### Production with Custom MQTT
```bash
python mqtt_mcp_server.py \
--transport streamable-http \
--broker mqtt.example.com \
--port 8883 \
--username prod_user \
--password secret123 \
--host 0.0.0.0 \
--http-port 80
```
## ๐ค Which Transport Should I Choose?
| Use Case | Command | Why? |
|----------|---------|------|
| **Local development** | `python mqtt_mcp_server.py` | Simple, secure, works with Claude Desktop |
| **Web deployment** | `python mqtt_mcp_server.py --transport streamable-http` | Modern, efficient, easy to deploy |
| **Remote AI agents** | `python mqtt_mcp_server.py --transport streamable-http --host 0.0.0.0` | Supports authentication, scalable |
| **Legacy systems** | `python mqtt_mcp_server.py --transport sse` | Only if you're already using SSE |
## ๐ณ Docker with Ngrok
Run the server inside Docker and automatically expose it with an ngrok tunnel.
### Build
```bash
docker build -t mqtt-mcp-ngrok .
```
### Run
```bash
docker run -d \
-p 8000:8000 \
-e NGROK_AUTHTOKEN=<YOUR_TOKEN> \
-e TRANSPORT=sse \
-e FASTMCP_PORT=8000 \
-e MQTT_BROKER_ADDRESS=mqtt.example.com \
-e MQTT_PORT=8883 \
-e MQTT_CLIENT_ID=my-client \
-e MQTT_USERNAME=prod_user \
-e MQTT_PASSWORD=secret123 \
mqtt-mcp-ngrok
```
The container exposes the MCP server via ngrok. Pass environment variables to
configure the MQTT broker and server transport. Check the container logs to
discover the public URL.
## ๐ Learn More
- [Model Context Protocol Specification](https://spec.modelcontextprotocol.io/)
- [MCP Python SDK](https://github.com/modelcontextprotocol/python-sdk)
- [FastMCP Documentation](https://gofastmcp.com/)
## ๐ Security Notes
- **STDIO**: Runs locally, inherently secure
- **HTTP/SSE**: Consider adding authentication for production deployments
- **MQTT**: Configure MQTT broker security (TLS, authentication)
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: mqtt_publish sends messages to a topic, while mqtt_subscribe receives messages from a topic. There is no overlap in functionality, and an agent can easily tell them apart based on their names and descriptions.
Both tools follow a consistent mqtt_verb pattern (mqtt_publish and mqtt_subscribe), which clearly indicates they belong to the MQTT domain. The naming is predictable and readable throughout the set.
With only 2 tools, the server feels thin for an MQTT domain, which typically involves operations like connect, disconnect, list topics, or manage brokers. While publish and subscribe are core, the lack of other essential functions limits its scope and utility.
The tool set is severely incomplete for MQTT operations. It lacks basic functionality such as connecting to/disconnecting from a broker, listing topics, or managing subscriptions beyond a single call. This will cause agent failures when trying to perform common MQTT workflows.