This server lets AI agents query and interact with an MQTT broker's recorded history, live state, and multi-broker topology.
List topic inventory with message counts and last-seen times (list_topics)
Get the last known value of a topic instantly, without waiting for the next message (get_last)
Retrieve timestamped historical messages, optionally excluding the retained-message startup burst (get_history)
Explore the topic tree by prefix and depth (get_tree)
Find topics that have stopped reporting, while warning about collector disconnects (find_silent)
Detect when the collector itself was disconnected from the broker (get_gaps)
Detect topics fed by more than one broker and classify them as bridged/migrated/independent (broker_konflikte)
Check server status: connection, data volume, write mode (status)
Publish messages to MQTT topics, only when write mode is enabled and the topic is not blocked (publish)
Retain old messages in SQLite with automatic retention cleanup, so past data is available for diagnosis
Provides tools for interacting with MQTT brokers, enabling AI agents to subscribe to topics, store messages with timestamps, query historical data, detect silent topics, monitor connection gaps, and optionally publish messages.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mqtt-mcp-server What is the last value of topic 'home/bedroom/temperature'?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for MQTT that remembers. It subscribes to a broker, stores every message with a timestamp in SQLite, and lets an AI agent ask questions about the past — not just about the next message that happens to arrive.
The existing ones answer "wait for the next message on this topic". That is the wrong question for diagnosing home automation:
A battery-powered sensor (Shelly H&T) sleeps for hours. Waiting for its next message means waiting for hours.
A broken device sends nothing at all. Waiting tells you nothing — you need to know when it last spoke.
"No data" is ambiguous. Was the device silent, or was the collector not listening? Without a record of connection state, both look identical.
This server answers all three.
Related MCP server: SQLite MCP Server
Tool | Purpose |
| Topic inventory — what exists, how many messages, last seen |
| Last known value immediately, no waiting |
| Timestamped history — the core feature |
| Topic tree, like MQTT Explorer |
| Topics that stopped reporting |
| When was the collector disconnected? |
| Which topics are fed by more than one broker — and is that a bridge or two writers? |
| Connection, data volume, write mode |
| Send a message — disabled by default |
find_silent and get_gaps belong togetherfind_silent deliberately warns you when connection gaps exist in the queried
period. A topic can look "silent" simply because nobody was listening. The server
refuses to let you confuse the two.
git clone https://github.com/Schimmilab/mqtt-mcp-server.git
cd mqtt-mcp-server
python3 -m venv .venv
.venv/bin/pip install -e .Register with Claude Code:
claude mcp add mqtt --scope user \
--env MQTT_MCP_HOST=192.168.1.10 \
-- /ABSOLUTE/PATH/TO/mqtt-mcp-server/.venv/bin/mqtt-mcp-serverA newly registered server is only picked up by a new session — MCP connections are fixed at session start.
Variable | Default | |
|
| broker host |
|
| |
| — | optional auth |
|
| comma-separated subscription filters |
|
| one file per broker — see below |
| all other | databases to compare against |
|
| delete messages older than this |
|
| hard cap, triggers oldest-first deletion |
|
| write mode |
| see | never published to, even in write mode |
Migrating a home automation system rarely happens in one jump. While the old and the new broker run in parallel, the same topic exists on both — and a value without a recorded origin is not wrong, it is unattributable. That is the worse kind of error, because it still looks like a measurement.
Two things make this visible:
Every row carries a broker column (host:port). Rows written before
this existed stay NULL — deliberately. Backfilling them with the current
broker would be an invented origin.
Give each broker its own database file (MQTT_MCP_DB). The origin is
then guaranteed structurally, not merely by a column somebody has to fill
correctly. broker_konflikte() attaches all of them read-only and answers
the one question that matters: which topics are fed by more than one
broker?
The result carries a messbar ("measurable") field, and it is the point of
the whole tool: an empty conflict list is only an all-clear when
messbar is true. If a peer database could not be read, or if most rows
predate the broker column, you get "teilweise" plus a warning — because
"no conflicts found" is exactly the answer you were hoping for, and that is
precisely when a broken measurement does the most damage.
If a bridge runs between the brokers, both carry the same topics — that is the normal state, not the anomaly. The first real run reported 129 of 147 topics, none of which needed action. A tool that flags 88 % gets ignored by the third time, so every doubled topic is classified:
| bridge proven — for each message, the nearest message on the other broker carries an identical payload |
| same pattern, but too few pairs to call it proven |
| the two rarely send at the same time — that is a migration, not double control |
| the real finding: overlapping in time, different payloads |
| not decidable — reported as such rather than guessed |
Two details decide whether the classification is honest rather than merely confident:
Nearest partner per message, not all pairs in the window. The naive version is a cross join and lies badly on high-frequency topics.
No partner ≠ different payload. Dividing hits by all messages turns absence into "0 % identical", which reads as "two writers". It isn't.
nur_verdaechtige=True (default) lists only what is not cleared, and counts
the rest in entwarnt_nicht_gelistet.
Verify the canary itself. A canary that finds nothing is indistinguishable
from a broken one, so tools/canary-doppelbesitz.py publishes two test topics:
one written independently by both brokers (must be reported as unabhaengig)
and one written identically by both (must be cleared). Run it, then call
broker_konflikte(seit_stunden=0.1) and check that exactly the first one shows
up. Without the second topic the first proves nothing — a canary that flags
everything would pass it too.
publish requires two conditions: write mode enabled and the topic not on the
block list. The default block list covers power switches and device restarts.
⚠️ The block list is a guard rail, not a security boundary. Anyone with access to the server can change it. Real enforcement requires a broker-side ACL.
The default exists because of a real incident: a switched socket in front of two servers failed and took the whole home automation down for nine days, costing seven weeks of measurement data. Measuring is safe; switching is not.
On connect, a broker delivers its entire retained backlog at once — potentially tens of thousands of messages with old content but a fresh arrival time. Storing those naively corrupts every history from the first second.
This server stores them, but flags them: aus_startschwall: true. get_last uses
them (that is how a sleeping sensor still has a value); get_history can exclude
them.
Broker authentication is implemented but untested against a real broker.
MQTT_MCP_USERNAME / MQTT_MCP_PASSWORD are passed to username_pw_set(), and
unit tests verify they reach the client — but no authenticating broker was
available during development. If you use auth, verify it works before relying on it.
Two behaviours are only covered by unit tests, not by integration tests:
connection loss (get_gaps) and devices going quiet (find_silent). Both are hard
to trigger on demand without a controllable broker. A built-in traffic simulator is
the obvious fix and is planned.
History only covers times when the server was running. It is a debugging tool started on demand, not a 24/7 collector. If something breaks while you are away and no session is open, nothing is recorded.
Runs at startup and hourly: delete older than N days, then — if still over the size cap — delete oldest-first. Every cleanup reports what it removed to stderr, including the oldest remaining timestamp. Silent deletion would quietly destroy the answer to "since when has this device been quiet?".
MIT
Topics, die seit X Stunden NICHT mehr gemeldet haben.
Die Frage vom 2026-08-01: 'seit wann meldet dieser Stecker nichts mehr?' (sonoff-4854 war seit dem 02.06. still — ein defekter Zwischenstecker).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| still_seit_stunden | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Zeitraeume, in denen der Sammler NICHT mit dem Broker verbunden war.
Trennt 'Geraet ist still' von 'ich habe nicht zugehoert'. Ohne diese Auskunft sehen beide Faelle in den Daten identisch aus.
| Name | Required | Description | Default |
|---|---|---|---|
| seit_stunden | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Verlauf eines Topics mit Zeitstempeln — die Kernfunktion dieses Servers.
mit_startschwall=False blendet den retained-Altbestand aus, der direkt nach dem Verbinden ankommt und einen irrefuehrend frischen Zeitstempel traegt.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes | ||
| seit_stunden | No | ||
| mit_startschwall | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Letzter bekannter Wert eines Topics — sofort, ohne auf die naechste Nachricht zu warten.
Genau das, was fertige MQTT-MCP-Server nicht koennen: bei einem schlafenden Batteriesensor (Shelly H&T) kaeme die naechste Nachricht erst in Stunden.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Topic-Baum ab einem Praefix — der Ueberblick wie im MQTT Explorer.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tiefe | No | ||
| prefix | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Topic-Inventar: welche Topics gibt es, wie viele Nachrichten, wann zuletzt.
pattern: Glob wie 'tele/*' oder '*SENSOR'. seit_stunden schraenkt auf den juengeren Zeitraum ein.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| pattern | No | ||
| seit_stunden | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Nachricht senden. Nur bei aktivem Schreibmodus und nicht auf gesperrte Topics.
⚠️ Die Sperrliste ist eine Bremse gegen Fehlgriffe, keine Sicherheitsgrenze.
| Name | Required | Description | Default |
|---|---|---|---|
| qos | No | ||
| topic | Yes | ||
| retain | No | ||
| payload | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Zustand des Servers: Verbindung, Datenbestand, Schreibmodus.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_silentget_gapsget_historyget_lastget_treelist_topicspublishstatusScored across 8 tools
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
