Skip to main content
Glama
misterboe

acinfinity-mcp

by misterboe

Set port timer

set_port_timer
Idempotent

Configure a countdown timer for a controller port to automatically switch on or off after a set number of minutes.

Instructions

Configure a countdown timer: the port turns on (to_on) or off (to_off) after minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
portYesPort number as printed on the controller (1-based).
minutesYesDuration in minutes (0-1440).
activateNoAlso switch the port into the matching timer mode.
directionYes'to_on' or 'to_off'.
controller_idYesController id (`id` from list_controllers).
user_authorizedNoMust be true. Set only after the user explicitly approved this exact change.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
portYes
changedYesAPI keys that were written, in API units.
controller_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations by specifying that the port transitions to to_on or to_off after the timer expires. It does not explain whether an existing timer is replaced, but idempotentHint=true already covers safe retries and destructiveHint=false covers risk.

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 filler. The core behavior is front-loaded and every word contributes to understanding what the tool does.

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?

Together with the fully described schema, annotations, and output schema, the description gives an agent enough to call the tool correctly. It lacks only an explicit note about replacing existing timers or the default activation behavior, but these are not critical given the schema and idempotentHint.

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?

The input schema has 100% description coverage, so the baseline is 3. The description adds a helpful link between minutes and the direction parameter but does not elaborate on activate or user_authorized, which are already adequately described 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 clearly states a specific action (configure a countdown timer) and the concrete effect (the port turns on or off after the given minutes). The phrase "countdown timer" distinguishes it from sibling tools like set_port_schedule or set_port_cycle.

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?

Usage is implied by the "countdown timer" wording, but the description does not explicitly say when to prefer this tool over alternatives such as set_port_schedule or set_port_cycle. There are no when-to-use or when-not-to-use statements.

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