mqtt-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool performs a distinct operation: listing topics, fetching last value, retrieving history, building a tree, finding silent topics, detecting gaps, checking status, and publishing. No two tools overlap in purpose, so an agent can easily select the right one.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (list_topics, get_history, get_tree, find_silent, get_gaps), but 'status' is a noun and 'publish' is a lone verb, deviating from the get_/list_ prefix style. The naming is still predictable and readable overall.
Tool Count5/5
With 8 tools, the server is well-scoped for an MQTT data inspection/control server. Each tool covers a necessary aspect of interacting with MQTT topics, without redundancy or bloat.
Completeness4/5
The tool set covers the core lifecycle: discover topics, read last values, query history, visualize hierarchy, identify silent devices, distinguish gaps, check server state, and publish. It lacks real-time subscription, but the data-centric focus makes this a minor gap.
Average 3.5/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the operation is read-only, or explain any side effects or restrictions. The analogy to MQTT Explorer hints at a non-destructive view but leaves uncertainty about behavior such as recursion depth, limits, or permission requirements.
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 concise sentence that is easy to read and front-loaded with the core concept. It avoids redundancy but is too terse to impart much guidance, making it efficient though not rich.
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 has three parameters and produces a tree structure, the description is inadequate. It does not describe the return format, how depth or limit affect results, or any ordering/pagination behavior, leaving many operational aspects ambiguous.
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 description only mentions 'Praefix' (prefix), which corresponds to one of the three parameters. It does not explain the semantics of 'limit' or 'tiefe' (depth), and the schema itself has zero descriptions, leaving these parameters insufficiently documented.
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 identifies the resource as a topic tree and the starting point (prefix). The MQTT Explorer analogy helps distinguish this as a hierarchical overview, differentiating from sibling tools like list_topics or get_last. However, it lacks an explicit verb, relying on the tool name for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an overview-like tree structure is needed ('der Ueberblick wie im MQTT Explorer'), but it does not provide explicit when-to-use vs alternatives or exclusions. No sibling tool is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses a specific behavioral nuance: setting 'mit_startschwall=False' filters out retained old stock that arrives after connection with misleading timestamps. This adds valuable context beyond the name, but it does not mention read-only nature, error conditions, or other side effects.
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 concise, with the main purpose stated in the first sentence. The second sentence explains a non-obvious parameter behavior in detail, which is necessary. It is not overlong and respects the front-loading principle.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 params, output schema present, no annotations), the description covers the core purpose and one important parameter behavior. However, it lacks usage guidelines and a fuller behavioral profile. The output schema likely documents return values, so that gap is acceptable. Still, the description feels incomplete for an agent to select and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 thoroughly explains the 'mit_startschwall' parameter and its effect, but the other three parameters (topic, limit, seit_stunden) are only implied by their names. The description adds meaning to one key param but leaves the rest to inference.
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 identifies the tool as 'Verlauf eines Topics mit Zeitstempeln' (history of a topic with timestamps), which clearly specifies the resource (topic) and the function (retrieving history with timestamps). It does not explicitly distinguish it from sibling tools like get_last or get_tree, but the noun phrase is specific enough.
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 such as get_last or get_tree. It only calls it the 'core function' of the server, which implies central usage but lacks explicit criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output scope (topics, counts, last message time) and filtering behavior (glob pattern, time window), implying a safe read operation. However, it does not mention permissions, pagination, limits, or error behavior, leaving some gaps.
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 short and includes the core information in two sentences, plus parameter examples. It is not highly structured but contains no fluff and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description is mostly adequate, but it omits the limit parameter and provides no usage guidance relative to sibling tools. It does not mention whether topics without messages are included or any performance implications, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 explains pattern with glob examples and seit_stunden as a time restriction, but does not mention limit at all. This is partial compensation for two of three parameters.
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: an inventory of topics with message counts and last activity. It uses a specific verb and resource ('Topic-Inventar') and implies a read-only overview, distinguishing it from siblings like get_history or get_last, though not explicitly.
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 on when to use this tool versus alternatives such as get_history or status. The description only gives parameter-level examples for pattern and seit_stunden, but does not state preferred use cases, exclusions, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 explains the kind of information returned (gaps in connectivity) and its interpretive value, but it does not disclose any behavioral details such as whether the results are sorted, limited, or include specific metadata. For a simple read-only tool this is adequate but not rich.
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 very concise, consisting of two short sentences. The first sentence immediately states what the tool returns, and the second adds crucial context. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and the output schema (signal present) covers return values. However, the complete lack of parameter documentation leaves a gap in understanding how to invoke the tool effectively. The conceptual context is well explained, but operational details are incomplete.
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 only parameter, 'seit_stunden', is not described anywhere in the tool description (schema coverage 0%). The description does not compensate by explaining how the time range affects the results or what values are expected. An agent cannot infer the meaning of this parameter from the description alone.
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 that the tool returns time periods when the collector was not connected to the broker, which is a specific and meaningful resource. It implicitly distinguishes itself from siblings like find_silent by explaining the difference between 'device is silent' and 'collector not listening', though it lacks a direct imperative verb like 'list' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to separate cases where a device is silent from cases where the collector was not listening. This provides a clear use-case and helps the agent choose it over alternatives like find_silent, even though no explicit alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool enforces write-mode and topic-lock constraints, and the warning about the blocklist being a brake, not a security boundary, adds nuanced behavioral context. However, it does not describe failure behavior, side effects, or the outcome of publishing, leaving significant gaps.
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 only two short sentences, wastes no words, and front-loads the core action ('Nachricht senden') followed by essential constraints. Every sentence contributes meaningful information.
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?
Although an output schema exists and the tool is conceptually simple, the description lacks parameter guidance and sufficient behavioral detail. With no annotations and no parameter descriptions, this sparse description is inadequate for an agent to ensure correct invocation, especially concerning optional parameters and error cases.
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 does not mention any parameter (topic, payload, qos, retain). The description provides no additional meaning beyond the raw parameter names, which is especially problematic for qos and retain that have domain-specific semantics.
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 states 'Nachricht senden' (send message), which is a specific verb and resource. This clearly distinguishes it from sibling tools like list_topics, get_last, and get_history, which are all read-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the conditions for use: 'Nur bei aktivem Schreibmodus und nicht auf gesperrte Topics' (Only with active write mode and not on locked topics). This gives clear context for when the tool can be used, though it does not explicitly mention alternatives or exclusions beyond these conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the content of the status (connection, data, write mode) but does not explicitly state that the operation is read-only, nor does it describe side effects, authentication needs, or latency. The provided aspects offer some transparency but not full behavioral clarity.
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 concise sentence that front-loads the tool's purpose and key output dimensions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with an output schema, the description sufficiently explains the tool's purpose and what it reports. It could add more nuance about typical use cases, but the simplicity of the tool and schema make the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to elaborate on parameter meaning. The schema coverage is trivially complete, earning the baseline score of 4.
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 tool reports server status (connection, data stock, write mode), providing a specific verb+resource. It distinguishes from siblings like list_topics or publish, which focus on topics and operations.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer when a status check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clarifies the read-only nature ('find') and the concept of 'silent', but it doesn't disclose any additional behavioral details such as pagination, sorting, or handling of topics with no data.
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 concise overall, with the core purpose in the first sentence. The second sentence's example is helpful but not strictly necessary, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, output schema present), the description is adequate. It explains the main concept and gives a use case, but could mention whether the tool considers only topics with a previous history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It explains still_seit_stunden ('X hours'), but does not describe the limit parameter. Thus, the description only partially compensates for the missing schema descriptions.
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 states the tool's function precisely: it finds topics that have not reported for X hours. This clearly distinguishes it from siblings like list_topics (all topics) and get_last (last reports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use-case example ('since when has this plug not reported?'), implying when to use the tool. It does not explicitly mention alternatives, but the example clarifies the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses the core non-blocking behavior and the use case. However, it does not mention what happens if no last known value exists, whether the value persists across restarts, or any error conditions. This leaves significant behavioral gaps.
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 two sentences long, front-loaded with the core purpose and a concrete example. Every word serves a purpose, and it efficiently communicates the value proposition without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description covers the primary behavior and use case. The presence of an output schema handles return value details. However, missing edge-case behavior (e.g., absent last value) and lack of annotations mean it is not fully complete, but it is adequate as a standalone description.
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?
With 0% schema description coverage for the single 'topic' parameter, the description must explain it. It only uses the word 'Topics' generically and does not specify the expected format, whether it supports MQTT wildcards, or whether the topic name is a filter or exact match. The schema provides only the name and type, so the description adds no value.
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 tool returns the last known value of a topic, with the key behavioral attribute of immediacy ('sofort, ohne auf die naechste Nachricht zu warten'). It distinguishes itself from typical MQTT subscribe semantics by highlighting it doesn't wait for the next message, and the noun phrase 'Letzter bekannter Wert eines Topics' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need the current cached value immediately without waiting for a new message, e.g., with sleeping battery sensors (Shelly H&T). It contrasts with ready-made MQTT servers but does not explicitly reference sibling tools like get_history or find_silent, so the guidance is contextual rather than comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mqtt-mcp-server MCP server](https://glama.ai/mcp/servers/Schimmilab/mqtt-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Schimmilab/mqtt-mcp-server)

Score Badge

Copy to your README.md:

[![mqtt-mcp-server MCP server](https://glama.ai/mcp/servers/Schimmilab/mqtt-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Schimmilab/mqtt-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Schimmilab/mqtt-mcp-server'

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