iaqualink-mcp

iaqualink_edit_schedule

Idempotent

Modify an existing Jandy AquaLink RS schedule by changing its start time, stop time, or run days, with a before-and-after preview and confirmation before applying.

Instructions

Change the start time, stop time and/or run days of one existing program in a Jandy AquaLink RS panel’s schedule (iAqua systems), through WebTouch. Identify the program exactly as iaqualink_list_schedules listed it (page, row, circuit, start, stop, days) — if the panel no longer shows that, nothing is pressed. The circuit itself cannot be changed (delete and add instead). The preview shows the list before and after; the result re-reads it. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "serial": "<serial>",
      "row": "<row>",
      "circuit": "<circuit>",
      "start": "<start>",
      "stop": "<stop>",
      "days": "<days>"
    },
    "name": "iaqualink_edit_schedule"
  }
}

Input Schema

Name	Required	Description
`row`	Yes	Its row on that page (1–7)
`days`	Yes	Its current run days, as listed
`page`	No	The page the schedule was listed on (from iaqualink_list_schedules)
`stop`	Yes	Its current stop time, HH:MM as listed
`start`	Yes	Its current start time, HH:MM as listed
`serial`	Yes	System serial number, from iaqualink_list_systems
`circuit`	Yes	Its circuit, as listed
`newDays`	No	New run days
`newStop`	No	New stop time, 24-hour HH:MM
`newStart`	No	New start time, 24-hour HH:MM
`confirmToken`	No	ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 11, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare non-read-only, idempotent, non-destructive, open-world behavior, and the description adds real value on top: a match-or-abort identity check that prevents blind edits, a before/after preview, a post-write re-read of the list, and the two-phase confirmToken fallback tied to MCP_CONFIRM_MODE. It does not state what the re-read result actually contains or how a mismatch failure is reported, so it stops short of full behavior disclosure.

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?

Front-loads the mutation scope, then the identity-matching rule, then the exclusion, then the confirmation mechanics — a sensible order with no filler. It is dense and clause-heavy, and the confirmation sentence packs three distinct rules (elicitation prompt, preview plus token, env-var reference) that an agent must parse carefully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, 6-required mutation with no output schema, it covers the pieces an agent needs to act safely: identity-matching precondition, immutable field, confirmation protocol, and both the preview and post-write re-read. Nothing essential is left open.

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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the field docs: the circuit/start/stop/days parameters form an identity tuple that must match the listed program exactly rather than being freely editable values, and circuit is explicitly non-mutable. The confirmToken lifecycle is largely restated from the schema, which keeps this from a 5.

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?

States a specific verb and resource ('Change the start time, stop time and/or run days of one existing program in a Jandy AquaLink RS panel's schedule'), names the transport (WebTouch), and explicitly bounds scope ('one existing program') plus a hard exclusion ('The circuit itself cannot be changed (delete and add instead)') that separates it from iaqualink_add_schedule and iaqualink_delete_schedule.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use and when-not-to conditions: identify the program exactly as iaqualink_list_schedules listed it, and 'if the panel no longer shows that, nothing is pressed'; for circuit changes it redirects to delete plus add. It also prescribes the confirmation prerequisite before any call proceeds, leaving nothing for the agent to infer.

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