Skip to main content
Glama
Omniscience-Labs

OMNI-MQTT-MCP

by Omniscience-Labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MQTT_PORTNoThe MQTT broker port1883
MQTT_PASSWORDNoThe MQTT password for authentication
MQTT_USERNAMENoThe MQTT username for authentication
MQTT_CLIENT_IDNoThe MQTT client IDmcp-mqtt-client
MQTT_BROKER_ADDRESSNoThe MQTT broker addresslocalhost

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Server capabilities have not been inspected yet.

Tools

Functions exposed to the LLM to take actions

NameDescription
mqtt_publishB
Publishes a message to a specific MQTT topic.

Args:
    topic: The MQTT topic to publish to.
    message: The message payload to send.
    qos: The Quality of Service level (0, 1, or 2). Defaults to 0.
    retain: Whether the message should be retained by the broker. Defaults to False.

Returns:
    A confirmation message string.
mqtt_subscribeA
Subscribes to an MQTT topic and receives a specified number of messages or waits for a timeout.

Args:
    topic: The MQTT topic to subscribe to (can include wildcards like + or #).
    num_messages: The maximum number of messages to receive. Defaults to 1.
    timeout: The maximum time (in seconds) to wait for messages. Defaults to 10.

Returns:
    A list of dictionaries, where each dictionary represents a received message
    with 'topic' and 'payload' keys.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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.4/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources