Workspace369

Invoice a scheduled job

invoices_create_from_schedule

Destructive

Create an invoice for one scheduled job (calendar event); invoices_batch_from_schedules covers a date range. schedule_id comes from calendar_list_events. The invoice takes its client and line items from the schedule and its connected estimate/proposal when one exists (a declined optional add-on is left off); otherwise it starts empty and lines are added with invoices_update_draft. Dates, due date, payment term, notes and terms come from the workspace's Invoice Defaults (invoices_get_defaults). It is created as Pending with a public pay link, linked to the schedule and numbered from the workspace sequence; a schedule that already has an invoice is refused. mark_as_paid also records a payment for the full total using payment_type (Cash, Check, Credit Card, Bank Transfer or Other) and fires the invoice.* webhooks. Nothing is charged and nothing is sent to the client. A repeat idempotency_key returns the first invoice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "schedule_id": "<schedule_id>"
    },
    "name": "invoices_create_from_schedule"
  }
}

Input Schema

Name	Required	Description
`schedule_id`	Yes	Calendar event (schedule) to invoice, from calendar_list_events.
`mark_as_paid`	No	Also record a payment for the full total.
`payment_type`	No	Payment method recorded when mark_as_paid is true; default Other.
`idempotency_key`	No	Optional. Repeat a call with the same key to avoid doing it twice.

Output Schema

Name	Required	Description	Default
`deduped`	Yes
`invoice`	Yes
`marked_paid`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 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 destructive/openWorld hints: created as Pending with a public pay link, numbered from the workspace sequence, linked to the schedule, client and line items inherited from the schedule's connected estimate (declined add-ons excluded), and fires invoice.* webhooks. It also explicitly states 'nothing is charged and nothing is sent to the client', which is exactly the kind of scope limit an agent needs before a destructiveHint=true call. Slightly short of 5 only because the practical consequence of destructiveHint=true (i.e. how the pending invoice is later voided/removed) is left to siblings.

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 purpose then the sibling contrast, and every subsequent clause carries operational information (defaults source, refusal rule, side effects, idempotency). It is a dense single paragraph that could be split for scanability, but there is no filler.

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?

Despite an output schema existing, the description supplies the state semantics an agent needs — Pending status, pay link, workspace-defaults inheritance, numbering, duplicate refusal, and no-charge/no-send guarantee. Combined with full schema coverage and annotations, nothing material is missing for correct invocation.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: mark_as_paid 'also records a payment for the full total using payment_type', and a repeat idempotency_key 'returns the first invoice' rather than erroring. The schedule_id provenance is repeated from the schema but the coupling between mark_as_paid and payment_type is clarified in prose.

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 ('Create an invoice for one scheduled job (calendar event)') and immediately delineates scope against the sibling 'invoices_batch_from_schedules covers a date range'. An agent can distinguish single-schedule invoicing from batch invoicing without opening either schema.

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 the alternative (batch tool) and the condition that separates them, names the prerequisite source for the required id ('schedule_id comes from calendar_list_events'), and routes the empty-line-item case to invoices_update_draft. It also documents a refusal condition (a schedule that already has an invoice is refused) that governs whether to call at all.

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

All Workspace369 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.