OrgLines

Automations: Run automation

automation_execute

Destructive

Run an automation now for one period (default: the period a run today acts for — for a recurring invoice the previous month). Allowed periods = automation_get's runnable_periods (the next period plus up to 4 earlier ones not yet closed, never before the automation started). The call itself does NOTHING: it returns a confirmation whose description is the server's preview — for an invoice the number, invoice and due dates, total, and the duplicate check (if any non-cancelled invoice to this customer already covers that month, nothing will be created). Show it verbatim; the action runs only after confirm_action. A period already done, covered or skipped is refused with «вже є: …». A recurring invoice is created as Open and its PDF goes to the owner's Telegram; nothing is sent to the client and no status is changed. 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_execute"
  }
}

Input Schema

Name	Required	Description	Default
`period`	No	The period, YYYY-MM. For a recurring invoice it is the SERVICE month (2026-10 = work done in October, invoiced in November).
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations (destructiveHint=true) by disclosing the exact side effects: an invoice is created as Open, its PDF goes to the owner's Telegram, nothing is sent to the client and no status changes, plus a duplicate-suppression rule. It also explains that the call itself performs no write and returns a preview that must be shown verbatim, and gives the literal refusal marker 'вже є: …'. The only minor gap is that it does not say how long the plan_token/action_id stays valid.

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 action and period scope, then the preview/refusal behavior, then the confirmation contract. Slightly over-long: 'The call itself does NOTHING' and the CONFIRMATION paragraph make largely the same point about the two-phase flow, and the recurring-invoice details are densely packed into single sentences.

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?

For a destructive, two-phase mutation with no output schema, the description covers prerequisites, legal inputs, refusals, side effects, and the confirmation handshake — enough to call it correctly. It leaves only the confirmation-window lifetime and what action_id/plan_token look like to the sibling confirm_action definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description still adds information the schema lacks: the default value of `period`, the closed set of allowed periods, and how `automation` may be omitted when only one automation exists. This is meaning beyond the schema, not a restatement of it.

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 and resource: 'Run an automation now for one period', and immediately bounds scope with the default period. It is clearly distinguishable from confirm_action, which it names as the step that actually 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?

States exactly when to call (to act now for one period), where the legal period set comes from (automation_get's runnable_periods, next period plus up to 4 earlier unclosed ones), and what the outcome is when the period is not eligible. The alternative path — that the real write requires confirm_action — is spelled out rather than implied.

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?