Field Service Business Platform by Doing Work

invoices_send

Send an invoice (or the next part of it) and get a single-use pay link. Earlier pay links stop working. Refused with conflict on a Doing Work deposit invoice whose booking ended (shop cancel or no-show). payments_ready false means the shop has no active payments account yet (after a hand-off, connect one with payments.connectStart); the link shows payment isn't available until it does.

Input Schema

Name	Required	Description
`percent`	No	Progress billing: ask for this percent of the invoice total now (capped at the balance). Use instead of amount_minor.
`invoice_id`	Yes
`amount_minor`	No	Amount to ask for now. Defaults to the deposit on the first send, then the balance.
`email_customer`	No	Also email the customer a branded email with their own pay link, from the shop. Default false: you share pay_url yourself.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / email_customer

Added value: +{
+  "description": "Also email the customer a branded email with their own pay link, from the shop. Default false: you share pay_url yourself.",
+  "type": "boolean"
+}

First observedNov 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the invalidation side effect ('Earlier pay links stop working'), the conflict-refusal condition, and the payments-readiness gate. It omits idempotency/retry behavior and any permission requirements, so it is strong but not exhaustive.

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?

Four tight sentences, front-loaded with the action and its output, then edge cases. The parenthetical asides are dense but each carries operational 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 still names the key return artifacts (pay link, payments_ready) and explains the refusal case. A fuller picture of the response payload or what happens to the invoice status after sending is missing, but the essentials for a correct call are present.

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 75% and percent, amount_minor, and email_customer are already well documented in the schema. The description adds no parameter-level meaning, and invoice_id remains undocumented in both places, matching the baseline for high-coverage schemas.

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 ('Send an invoice') plus the outcome ('get a single-use pay link') and covers partial sends ('or the next part of it'). An agent can distinguish this from invoices_create, invoices_pdf, or invoices_markPaidOutside without opening the schema.

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?

Gives concrete conditions and recovery paths: progress sends are supported, a conflict is returned for Doing Work deposit invoices whose booking ended, and payments_ready=false routes to payments.connectStart. It does not explicitly name sibling alternatives (e.g., when to use invoices_pdf or markPaidOutside instead), so it stops short of a 5.

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

All Field Service Business Platform by Doing Work 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?