OrgLines

Automations: Update automation

automation_update

Destructive

Change an automation — only what the person asked: state 'active' or 'paused'; the schedule (day_of_month 1-28, run_time HH:MM, timezone, schedule_mode 'first_business_day' = that day rolled from Sat/Sun to Monday, or 'day_of_month'); or ONE period with period_action: 'plan' + planned_date (YYYY-MM-DD, today or later — that period runs on that date instead of the schedule), 'unplan', 'skip' (nothing for that period; optional note), 'covered' + ref (for an invoice: the number or id of the invoice to this customer that already covers that month), 'reset' (back to planned; a done period only after its result was undone, e.g. the invoice cancelled). Runs propose→confirm. 'action': 'archive' (retire it: never runs, hidden from the list, history kept), 'restore' (back from the archive, paused), 'delete' (only while it never produced a result — otherwise refused: archive it instead). CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "automation_update"
  }
}

Input Schema

Name	Required	Description
`ref`	No
`note`	No
`state`	No
`action`	No
`period`	No	The period, YYYY-MM. For a recurring invoice it is the SERVICE month (2026-10 = work done in October, invoiced in November).
`run_time`	No
`timezone`	No
`automation`	No	The automation's id (from automation_list) or a part of its name. May be omitted when the cabinet has exactly one automation.
`day_of_month`	No
`planned_date`	No
`period_action`	No
`schedule_mode`	No
`lead_business_days`	No	Generate this many business days (Mon–Fri) BEFORE the action date; the action (e.g. the invoice) stays dated on the scheduled day.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds substantially more: the propose→confirm protocol, the exact confirmation payload (status='confirmation_required', action_id, plan_token), the irreversibility profile of archive (history kept, hidden, never runs) vs delete (refused once a result exists), and restore landing in a paused state.

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-loaded with the core verb, and every clause carries operational meaning with no filler. The downside is density: it is one long run-on block with nested parentheticals, so the action table would be far more scannable as short structured lines.

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 a 13-parameter, zero-required, no-output-schema mutation tool, the description covers what an agent needs: which combinations are valid, what each destructive action does, and what the tool returns instead of performing the write. No output schema is needed because the confirmation contract is spelled out in prose.

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?

With only 23% schema description coverage across 13 parameters, the description carries most of the semantic load and does it well: it defines the schedule_mode roll behavior, planned_date's 'today or later' constraint, the five period_action values with their required companions (plan+planned_date, covered+ref, skip+optional note), and ref/note usage. It leaves automation and lead_business_days to the schema, which does describe them, so the gap is minor rather than material.

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?

Opens with a specific verb+resource ("Change an automation") and immediately enumerates the three disjoint change surfaces: state, schedule, or one period. It is clearly a mutation tool distinct from automation_get/list/execute, and it explicitly states that it only proposes while confirm_action performs the write.

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 routing for every action, including exclusions: delete only while the automation never produced a result, otherwise "archive it instead"; reset only after the period's result was undone; covered requires a ref to the covering invoice. It also names the required follow-up tool (confirm_action) and the status that triggers it.

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

All OrgLines tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?