mcp-venus-os

by 4alvit

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct function: monitoring (battery, PV, grid, inverter), enumeration (list_devices), control (set_* tools), and MQTT lifecycle (connect/disconnect/subscribe). No two tools have overlapping purposes.
Naming Consistency5/5
All tools consistently follow a verb_noun pattern using snake_case, with clear prefixes: get_ for reads, set_ for writes, list_ for enumeration, and mqtt_ for MQTT operations. This makes names predictable and easy to understand.
Tool Count5/5
11 tools is well-scoped for a Victron energy system integration. It covers monitoring, control, and MQTT connectivity without unnecessary bloat, making the set feel appropriately sized.
Completeness4/5
Core monitoring and control operations are present, covering PV, grid, battery, and inverter. However, there is no way to read configured limits (e.g., SoC limit, charge current limit) and no explicit MQTT message polling tool despite subscription IDs being returned, which are minor gaps.
Average 3.2/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 38 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context. It does not disclose whether the operation is read-only, any side effects, error conditions, or data source specifics. The description simply restates the tool's function without adding transparency.
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 immediately states the core purpose. It is concise and front-loaded, though it could include more detail; however, for a simple getter, this level of brevity is acceptable and every word earns its place.
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?
While the tool is simple with one optional parameter and an output schema, the description leaves out critical context about the meaning of 'grid/AC status' and the 'instance' parameter. It also lacks usage guidance or potential caveats, making it incomplete for reliable agent invocation.
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, 'instance' (integer, default 0), but the description does not mention or explain it. With 0% schema description coverage, the description fails to clarify the parameter's meaning or usage, leaving the agent to infer from the schema 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 'Get grid/AC status' uses a specific verb ('Get') and resource ('grid/AC status'), clearly indicating the tool's primary function. It is distinguishable from sibling tools like get_battery_soc and get_pv_power by the resource type, though it does not explicitly elaborate on what 'status' encompasses.
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 usage guidance is provided. There is no mention of when to use this tool versus alternatives, prerequisites, or exclusions. The usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Get', implying a read-only operation, but does not mention any authentication requirements, error behavior, or side effects. No additional context is provided beyond the verb.
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 short sentence with no unnecessary words. It is front-loaded and gets straight to the point. However, it is so terse that it veers toward under-specification, though not enough to lower the score significantly.
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 simple tool with one parameter, the description is incomplete. It does not explain the purpose or possible values of the 'instance' parameter, nor does it provide context on when to use this tool among the sibling getters. The output schema exists but is not referenced in the description.
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 'instance' with no description, and the schema description coverage is 0%. The description does not mention the parameter at all, leaving the agent without any understanding of what 'instance' refers to or how to use it.
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 'Get battery state of charge' uses a specific verb ('Get') and resource ('battery state of charge'), clearly distinguishing it from siblings like get_pv_power and get_grid_status. It precisely identifies the tool's function.
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?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without mentioning context, prerequisites, or exclusions. It does not name any sibling tool or explain when this read is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only implies a safe read operation via 'Get', but does not disclose return format, units, refresh behavior, or any side effects. This is a significant gap for a data retrieval 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, front-loaded sentence that avoids fluff and clearly states the core purpose. While it is minimal, it is appropriately concise for the tool name and does not waste words.
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?
Despite having an output schema (which covers return values), the description lacks critical context: it does not explain the instance parameter, provide usage guidance, or mention any behavioral constraints. For a tool with one optional parameter and no annotations, this description is insufficiently complete.
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 the 'instance' parameter at all. The parameter name suggests selecting among PV instances, but no meaning is provided. Users cannot infer what values to pass or why the parameter exists.
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 uses a specific verb ('Get') and resource ('PV/solar charger power data'), clearly distinguishing it from sibling tools like get_battery_soc and get_grid_status. It unambiguously identifies the tool's function without ambiguity.
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 does not mention whether it should be used for live readings, historical data, or how it relates to other getter tools like get_inverter_status. There is no when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Connect to MQTT broker'. It does not clarify whether the connection is persistent, whether authentication is required, what side effects occur, or if there are any limitations. This is a significant gap for a connection-establishing operation.
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 effectively states the core action. It is front-loaded and avoids unnecessary detail, though it could provide more context without becoming verbose.
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 simplicity of the tool (0 params) and the presence of an output schema, the description is adequate for basic understanding, but it fails to explain important context such as the relationship to mqtt_subscribe and mqtt_disconnect. The lack of usage guidance and behavioral transparency makes it incomplete for the agent to select and invoke correctly in a sequence of operations.
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 input schema has zero parameters, so there is nothing for the description to clarify. The schema coverage is 100% vacuously, and per the baseline for 0 params, the description does not need to add parameter semantics. It correctly remains silent on 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 action ('Connect to MQTT broker') and purpose ('real-time data'), which distinguishes it from sibling tools like mqtt_disconnect and mqtt_subscribe. It is specific and unambiguous, though it does not elaborate on the scope beyond 'real-time data'.
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. It does not mention any prerequisites, alternatives, or that it should be called before mqtt_subscribe or after mqtt_disconnect. The agent is left without context for when this is appropriate relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full disclosure burden. It identifies the operation as a write requiring confirmation, which is useful, but it does not explain what happens when confirmation is missing, whether the change is reversible, or any system impact. Behavior is only partially disclosed.
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?
Two short sentences with no filler. The mode list is directly useful, and the confirmation note is a necessary constraint. It is appropriately sized for the information it conveys.
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, the description lacks essential context: no usage guidance, no parameter semantics for instance/confirmed, and no behavioral consequences beyond confirmation. For a mutation tool with no annotations, this is insufficient for an agent to reliably invoke it.
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 input schema has 0% description coverage, so the description must explain all parameters. It lists the mode values but does not define them. The 'instance' parameter is entirely absent, and 'confirmed' is only implied by 'Requires confirmation,' not clearly mapped to the parameter. Significant semantic gaps remain.
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 verb 'Set' and the resource 'inverter mode', and lists the accepted modes. This distinguishes it from sibling setters like set_charge_current_limit and set_soc_limit because the target parameter is explicitly named.
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. The only operational note, 'Requires confirmation for write operations', is a prerequisite rather than a usage condition, and it does not mention preconditions or alternative tools.
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?
The description discloses that the tool 'Requires confirmation for write operations,' which adds a key behavioral trait beyond the raw schema. However, it does not clarify how confirmation is provided (e.g., via the confirmed parameter), what happens if not confirmed, or any side effects. With no annotations, the description carries a heavier burden, but this is only partially fulfilled.
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 extremely concise: two sentences, front-loaded with the core purpose. Every sentence earns its place with no redundant or filler content.
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?
While an output schema exists (so return values are presumably covered), the tool has multiple parameters and a confirmation mechanism that is under-specified. The description lacks vital context about how to execute a write (setting confirmed=true?), value ranges for soc_limit, and differences from sibling set tools. This leaves the agent uncertain about safe and correct invocation.
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 explain the parameters. It implies that soc_limit is a percentage, but instance and confirmed are entirely undocumented. The confirmation requirement hints at the confirmed parameter's purpose, but the mechanism and constraints are not explained.
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 'Set battery SoC limit percentage' clearly identifies the action (set) and the resource (battery SoC limit), and it is distinct from sibling tools like get_battery_soc or set_charge_current_limit. The purpose is unambiguous and directly maps to the tool name.
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, or any prerequisites or exclusions beyond a vague confirmation requirement. It does not mention that this is for adjusting battery state-of-charge limits in contrast to other charge-related settings.
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 of disclosing behavior. The verb 'Get' indicates a read-only operation, which is the key behavioral trait. However, it omits details like whether it requires an active MQTT connection, how it handles invalid instances, or whether data is real-time or cached. This is adequate for a simple getter 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately states the tool's purpose. It is front-loaded and contains no filler. However, it is slightly too terse to be considered fully structured, as it omits any context about parameters or usage, but it earns its place for what it says.
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 getter with one optional parameter and an output schema, the description provides the core purpose but leaves gaps. The instance parameter is unexplained, and there is no guidance on when to use this tool versus the sibling set tools. The output schema covers return values, so completeness is adequate but not thorough.
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 schema has 0% description coverage, and the description does not explain the 'instance' parameter at all. Even though the parameter name is somewhat self-explanatory and has a default, the description fails to clarify what 'instance' refers to (e.g., which inverter). The description adds no semantic value beyond the schema, which is empty.
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 uses the specific verb 'Get' and clearly identifies the resource as 'inverter mode and state.' This distinguishes it from sibling tools like get_battery_soc, get_pv_power, and get_grid_status, which target different resources. The scope is precise 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 context is clear: this tool is for retrieving inverter status. While there is no explicit exclusion or alternative mentioned, the sibling tool names (e.g., set_inverter_mode, get_grid_status) imply when this tool should be used. It provides adequate context without explicit when-not guidance.
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 of explaining behavior. It discloses that the tool returns a subscription ID and that messages are retrieved via polling, which is valuable. Still, it omits important behavioral details such as whether the subscription persists, whether it must be cleaned up, or what happens if the connection is lost.
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 extremely concise, with exactly two sentences. It front-loads the action ('Subscribe to MQTT topic pattern') and then provides the key return value. Every word earns its place with no filler.
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 the tool is simple (one parameter) and an output schema exists, the description lacks essential context about prerequisites (e.g., connection requirement), lifecycle behavior, and how the returned ID should be used. The information gap is significant enough to limit correct invocation without prior knowledge of MQTT or the system.
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 one param (topic_pattern) with 0% description coverage, and the description does not explain what constitutes a valid topic pattern (e.g., wildcard syntax, MQTT topic rules). The param name is self-explanatory at a basic level, but the description fails to add the necessary detail for correct usage.
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 uses a specific verb ('Subscribe') and resource ('MQTT topic pattern'), making the action unambiguous. It also differentiates itself from siblings like mqtt_connect and mqtt_disconnect by clearly focusing on the subscription lifecycle rather than connection management.
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 by describing that it returns a subscription ID for polling messages, which suggests it should be used after establishing a connection. However, it does not explicitly state when to use it relative to mqtt_connect or whether an active connection is required, leaving the usage context mostly implied.
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 of disclosing behavior. It does state that the operation is a write that requires confirmation, which is important context. However, it does not explain what happens upon confirmation, whether the setting persists, any side effects, or potential errors. The behavioral disclosure is minimal beyond the confirmation note.
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 with no filler. The purpose is front-loaded in the first sentence, and the second sentence adds crucial operational guidance. Every word earns its place, making it highly concise and well-structured.
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 relatively simple, and an output schema exists, so return values are covered. However, the description lacks context around the 'instance' parameter and does not elaborate on when or how the tool should be used in a broader workflow. It is adequate but leaves notable gaps, especially given the confirmation semantics that could be more deeply explained.
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 explains that 'current' is the maximum charge current in Amps and indirectly explains 'confirmed' via the write-confirmation note. However, it completely omits the 'instance' parameter, leaving its meaning and role unclear. The description only partially clarifies the parameters and fails to cover all three.
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's action ('Set maximum charge current limit') with a specific resource and unit ('in Amps'), which unambiguously distinguishes it from sibling tools like set_soc_limit and set_inverter_mode. The verb-resource pairing is precise and self-contained.
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 mentions 'Requires confirmation for write operations,' which provides a prerequisite for using the tool. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide scenarios or exclusions. The guidance is limited to the confirmation requirement, so it is only partially helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action, not what happens if already disconnected, whether subscriptions are cleaned up, or any side effects. This is a significant gap.
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, focused sentence with no wasted words. It is appropriately sized for such a simple operation.
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 zero-parameter simplicity, the description is adequate but lacks context about prerequisites (e.g., an active connection being required). Sibling tools imply the need to connect first, but the description itself is minimal.
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 baseline is 4. The description does not need to explain parameter details, and the schema confirms no parameters exist.
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 action: 'Disconnect from MQTT broker.' It uses a specific verb and resource, and is distinct from sibling tools like mqtt_connect and mqtt_subscribe.
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 you want to end the MQTT connection) but provides no explicit when-to-use or alternatives. Sibling tools context helps, but the description itself offers no guidance.
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 of behavioral disclosure. It implies a read-only listing operation but does not explicitly state side effects, the nature of the returned devices, or whether the list is static or dynamic. Basic purpose is clear, but deeper behavioral context is missing.
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 immediately states the action and target. Every word is informative; there is no verbosity or filler. It is optimally structured for quick comprehension.
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 list operation with no parameters and an existing output schema, the description is nearly complete. It could have noted that this tool is a precursor for obtaining device identifiers used by sibling tools, but that omission is minor given the tool's straightforward nature.
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?
Schema has zero parameters, and the baseline for zero parameters is 4. The description adds no parameter details, but none are needed. It adequately conveys that no arguments are required, though it could have hinted at the output schema for device information.
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?
Description states a specific verb ('List') and resource ('all Victron devices on D-Bus'), clearly distinguishing it from sibling tools that query or control specific device properties. It is unambiguous and immediately conveys the tool's function.
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. There is no mention of using it for discovery before accessing specific device metrics, nor any exclusions or prerequisites. The intended usage must be inferred from context.
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:

[![mcp-venus-os MCP server](https://glama.ai/mcp/servers/4alvit/mcp-venus-os/badges/card.svg)](https://glama.ai/mcp/servers/4alvit/mcp-venus-os)

Score Badge

Copy to your README.md:

[![mcp-venus-os MCP server](https://glama.ai/mcp/servers/4alvit/mcp-venus-os/badges/score.svg)](https://glama.ai/mcp/servers/4alvit/mcp-venus-os)

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/4alvit/mcp-venus-os'

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