Skip to main content
Glama

subscriptions

Create a recurring invoice schedule

schedule_create

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 observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only state broad hints (all false), so the description carries the disclosure burden. It adds significant behavior beyond structured data: 'Nothing is invoiced until invoice_generate_due runs' and the return values (schedule id, summary, next dates). It doesn't cover permission requirements or immediate activation state, but it addresses the most surprising side-effect boundary.

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 sentences with no filler: the first states the action and scope, the second states the return values, the third states the critical caveat. Every sentence earns its place, and the most important differentiator ('nothing is invoiced until...') is placed at the end for emphasis.

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 create tool with 12 parameters but a fully descriptive schema, the description covers the essential behavioral contract: what is created, what is returned, and when side-effects occur (only via invoice_generate_due). No output schema exists, so the explicit return description is valuable. Nothing an agent needs to know before calling correctly is missing.

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%, and the schema itself contains rich parameter explanations (e.g., the 'every' field's day-of-month clamping behavior). The tool description only summarizes parameter categories ('a client, the line items, how often to bill') without adding new meaning, so the baseline of 3 applies.

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 uses a specific verb and resource ('Define a repeating invoice') and enumerates the core components (client, line items, frequency, start/end), making the tool's job unambiguous. It also states the return contract (schedule id, summary, next dates), and implicitly differentiates from siblings like schedule_update and schedule_delete by being the creation tool.

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?

The description provides clear context for when to use this tool: to set up a repeating invoice schedule. It does not explicitly name alternatives or exclusions (e.g., 'use schedule_update to modify'), but the title and sibling set make that distinction clear. The mention of invoice_generate_due as a downstream step rather than an alternative leaves the guidance slightly implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.