Skip to main content
Glama

Create a recurring invoice schedule

schedule_create

Create a recurring invoice schedule with client, line items, frequency, and start/end dates. Returns schedule ID and next dates; invoices are generated only when invoice_generate_due runs.

Instructions

Define a repeating invoice: a client, the line items, how often to bill, and when it starts and ends. Returns the schedule id, a summary and its next dates. Nothing is invoiced until invoice_generate_due runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
everyYesHow often to bill: "weekly", "monthly", "quarterly", "yearly", or {days: 10}. Month steps keep the start date's day of month and clamp it to shorter months, so a schedule starting on the 31st bills on the 28th/29th in February and back on the 31st in March
itemsYesThe line items billed every period
notesNoFree text printed under the totals of every generated invoice
clientYesClient name or id, as in the invoice server. Unknown names are created on the first generated invoice
currencyNoDefaults to your business default currency
due_daysNoDays until each invoice is due, defaults to your payment terms
end_dateNoYYYY-MM-DD, INCLUSIVE: an occurrence landing exactly on it is still generated
tax_noteNoWhy this schedule bills the tax it bills, e.g. 'Reverse charge: VAT accounted for by the recipient, art. 196 Directive 2006/112/EC'. It is printed under the totals of EVERY invoice this schedule generates, so a 0% retainer carries its reason on the document instead of only in the chat
anchor_dayNoPro: bill on this day of month instead of the start date's day. 31 means the last day of every month
start_dateYesYYYY-MM-DD. The first invoice falls on this date, and for weekly/monthly/quarterly/yearly steps its day of month is the billing day for every later period
end_of_monthNoPro: always bill on the last day of the month
auto_generateNoMarks the schedule for the monthly_billing_run prompt. Default false. Nothing runs in the background either way: invoices are created only when invoice_generate_due is called

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses the key non-obvious trait that nothing is invoiced immediately, and states what the call returns (schedule id, summary, next dates). It could mention persistence or duplicate behavior, but the most important side-effect timing is covered.

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?

Three short sentences deliver purpose, return value, and behavioral caveat with no filler. The most important distinction—no invoicing happens here—is front-loaded near the end without bloating the definition.

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?

Given no output schema, the description usefully states the return shape. Given no annotations, it also flags deferred invoicing. The rich 12-parameter schema covers the rest; the only real gap is the lack of explicit routing to one-off invoicing alternatives.

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?

Schema description coverage is 100%, so every parameter is already documented clearly. The description only summarizes the input categories at a high level and does not add new parameter-specific semantics beyond the schema, matching the baseline for high schema coverage.

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 ('Define a repeating invoice') and enumerates its core inputs: client, line items, billing interval, start/end. The final sentence differentiates it from invoice_generate_due by clarifying that no invoice is created here, so an agent can distinguish it from invoicing siblings.

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?

Provides clear workflow context: the schedule is created now, but invoices are only produced later when invoice_generate_due runs. It does not explicitly name a one-off alternative such as invoice_create, so it stops short of a full when-not-to-use statement.

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

Install Server

Other Tools