acinfinity-mcp

Overview Schema Source Related Servers Discussions Admin

Set port mode

set_port_mode

Idempotent

Switch a controller port's active mode to Off, On, Auto, Schedule, or other modes while retaining its current power, triggers, and timer settings.

Instructions

Switch the active mode of a port (e.g. Off, On, Auto, Schedule). The mode's parameters (power, triggers, timers) keep their current values — set them first with the other tools.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	1 Off, 2 On, 3 Auto, 4 Timer to On, 5 Timer to Off, 6 Cycle, 7 Schedule, 8 VPD, 9 CO2, 10 CO2 Fan, 11 Moisture, 12 Water Temp, 13 pH, 14 EC, 15 Water Detect.
`port`	Yes	Port number as printed on the controller (1-based).
`controller_id`	Yes	Controller id (`id` from list_controllers).
`user_authorized`	No	Must be true. Set only after the user explicitly approved this exact change.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	No
`port`	Yes
`changed`	Yes	API keys that were written, in API units.
`controller_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The description adds meaningful behavior beyond the annotations: mode parameters (power, triggers, timers) keep their current values, and parameter setup should happen before switching modes. This clarifies the operation's side-effect profile without contradicting the idempotentHint or destructiveHint annotations.

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 sentences with no filler: the first states the operation and examples, the second delivers the essential behavioral caveat about preserving parameter values. Everything included earns its place, and the most important usage guidance is front-loaded.

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?

The description is sufficient for a straightforward mode-switching tool, especially with a 100%-covered schema, output schema, and idempotent/destructive annotations. The only mild gap is not mentioning the user_authorized requirement in prose, but the schema already makes that mandatory explicit.

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%, and the schema already documents each parameter, including the mode enum mapping. The description adds little beyond the schema, though it does reference parameter categories (power, triggers, timers) that align with sibling tools. The required user_authorized approval flag is only explained in the schema.

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 and resource ('Switch the active mode of a port') and gives concrete examples (Off, On, Auto, Schedule). It clearly differentiates this tool from sibling set_port_power, set_port_timer, and set_port_schedule by stating that this tool only changes the mode while leaving parameters untouched.

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 conveys clear context: use this to switch mode, and configure the mode's parameters first with the other tools. It implies the division of labor between this and the parameter-setting siblings, though it does not explicitly name those alternatives or state when not to use this tool.

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

Deploy Server