OrgLines

Automations: Get automation

automation_get

Read-only

One automation in full: settings (the action's parameters), schedule, next run (local time and UTC), the last run, the ledger of recent periods, and a live check of the upcoming period (or 'period'): whether it is already done or covered by something that exists (for a recurring invoice: any non-cancelled invoice to this customer for that service month, whatever its number — with its number and link), and otherwise what a run would create. With 'period' the full preview (for an invoice: the body). Answers «перевір щомісячний інвойс клієнта». Read-only; creates nothing.

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_get"
  }
}

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.3/5.0

Behavior4/5

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

The annotations already declare read-only, non-destructive, closed-world behavior, and the description reinforces that with 'Read-only; creates nothing.' It adds useful behavioral context beyond annotations: the live coverage check, the full period preview, and what a run would create. Authentication and error behavior are not covered, but the annotation baseline is already strong.

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?

It is front-loaded with 'One automation in full:' and the output list follows immediately. The two sentences are dense with nested parentheticals and a non-English example phrase, but each part carries relevant information rather than filler.

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?

With no output schema, the description usefully carries the return-value burden by naming the fields and explaining the period-check result. It leaves some edge cases unspecified, such as permissions and behavior across non-invoice automation types, but it is substantially complete for a read-only get tool.

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?

The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds meaning by explaining that 'period' changes the response from a basic coverage check to a full preview, which is not obvious from the schema alone.

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 states a specific resource and scope: 'One automation in full,' then enumerates exactly what is returned (settings, schedule, runs, ledger, live period check). This clearly distinguishes it from the sibling list-style tool without needing to name it.

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?

It supplies a concrete use case ('check the client's monthly invoice') and explains that passing 'period' yields a full preview. It does not explicitly name alternatives such as automation_list or automation_runs, and it gives no when-not-to-use guidance, so it falls short of top-tier routing guidance.

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?