Skip to main content
Glama
Disane87

weishaupt-wem-mcp-server

wem_write_parameter

Set writable Weishaupt heating parameters, such as target temperature, on a specified device and module. Check parameter metadata for allowed ranges or enum options before writing.

Instructions

Set a parameter value (e.g., target temperature). Only works for writable parameters. Check wem_get_parameter_meta for min/max values and enum options first.

Input Schema

NameRequiredDescriptionDefault
deviceIdYesDevice ID (from wem_get_devices)
moduleTypeYesModule type
moduleIndexYesModule index
parameterIdYesParameter ID to write
stringValueNoString value (optional, for enum/text parameters)
numericValueYesNumeric value to set

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses the writable-only constraint and the need to pre-validate ranges/enums, which is meaningful. It says nothing about whether the write is immediate, persistent across reboots, what error surface appears for out-of-range values, or whether it is reversible.

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, zero filler, with the constraint and the prerequisite check front-loaded before any elaboration. Nothing is repeated from the schema.

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 5-required-parameter mutation tool with no annotations and no output schema, the description covers the essential guardrails (writable check, meta lookup) but leaves open units, what the call returns, and the stringValue/numericValue decision. Adequate, not complete.

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 100%, so the schema already documents all six parameters, giving a baseline of 3. The description adds no field-level meaning beyond the example value, and in particular never explains the numericValue vs. stringValue selection that an agent must decide for enum/text 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?

"Set a parameter value" names a specific verb and resource, with a concrete example (target temperature) that makes the abstraction tangible. It does not explicitly contrast itself with sibling read tools like wem_read_parameters, but the write/read split is inferable from the name and text.

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?

Gives a hard precondition ("Only works for writable parameters") and a sequencing instruction ("Check wem_get_parameter_meta for min/max values and enum options first"). That is real routing guidance, though it never names the alternative write path or says what to do if the parameter turns out non-writable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.