Groundbase

Manage invoices

invoices_manage

Destructive

Invoices. save_draft (create, or edit by id), issue (numbers it; final), send (emails it; confirm), void, public_link (a pay link; revoke), credit_note (amount + reason; final), send_credit_note / void_credit_note (creditNoteId), recurring (frequency + nextRunDate, autoSend emails each; stop). Confirm anything final or sent.

Input Schema

Name	Required	Description
`id`	No	Required for: issue, send, void, public_link, credit_note, recurring; optional for: save_draft. Edit this draft.
`to`	No	Default: profile billing email, then the contact's email.
`stop`	No	recurring: end the schedule.
`lines`	No	itemId (saved item) or name + unitPrice. Decimal strings. taxIds: which of the taxes apply (default all).
`notes`	No
`taxes`	No	[{id?,name,rate}], e.g. GST 5 + QST 9.975 (ids t1,t2…).
`terms`	No
`action`	Yes
`amount`	No	credit_note: before tax, e.g. "50.00".
`reason`	No	credit_note: printed on it.
`revoke`	No	public_link: turn the link off.
`charges`	No	Below the subtotal (shipping); negative for a discount or deposit.
`dueDate`	No	YYYY-MM-DD. Default from profile terms.
`endDate`	No	recurring: YYYY-MM-DD, or omit for no end.
`message`	No	A note above the invoice in the email.
`sendVia`	No	Default: their own mailbox, then Resend, then Groundbase's address.
`subject`	No	Default: the invoice settings subject.
`taxRate`	No	credit_note: percent, e.g. "13".
`autoSend`	No	recurring: email each copy to the customer. Confirm with the user.
`currency`	No	ISO 4217. Defaults from the billing profile.
`companyId`	No
`contactId`	No	Create: one of contactId/companyId.
`frequency`	No
`issueDate`	No	YYYY-MM-DD. Default today.
`nextRunDate`	No	recurring: YYYY-MM-DD, today or later.
`confirm_paid`	No	Void even though payments or credit notes are recorded on it. Only after the user has confirmed. Default false.
`creditNoteId`	No	Required for: send_credit_note, void_credit_note.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 18, 2026

changedInput schema / properties / charges / description

Previous value: -"Charges below the subtotal (shipping, rush fee); a negative amount for a deposit or discount."New value: +"Below the subtotal (shipping); negative for a discount or deposit."

removedInput schema / properties / charges / items / properties / amount / description
```
Removed value: -"Decimal string."
```

changedInput schema / properties / lines / description

Previous value: -"Line items: itemId (saved item, priced in this currency) or name + unitPrice for a one-off. Amounts are decimal strings."New value: +"itemId (saved item) or name + unitPrice. Decimal strings. taxIds: which of the taxes apply (default all)."

removedInput schema / properties / lines / items / properties / quantity / description
```
Removed value: -"e.g. \"1.5\"."
```

addedInput schema / properties / lines / items / properties / taxIds

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / lines / items / properties / taxRate / description
```
Removed value: -"Percent, e.g. \"17.5\". Defaults from the item."
```

addedInput schema / properties / taxes

Added value: +{
+  "description": "[{id?,name,rate}], e.g. GST 5 + QST 9.975 (ids t1,t2…).",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedOct 17, 2026

addedInput schema / properties / creditNoteId / description

Added value: +"Required for: send_credit_note, void_credit_note."

changedInput schema / properties / id / description

Previous value: -"Edit this draft. Omit to create."New value: +"Required for: issue, send, void, public_link, credit_note, recurring; optional for: save_draft. Edit this draft."

AddedOct 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is present. The description adds meaningful behavioral context: issue and credit_note are final, send emails the invoice, recurring auto-sends email copies, public_link can be revoked, and final or sent actions require confirmation. It does not explain void's downstream effects or return behavior, but the added confirmation/finality guidance is substantial.

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?

The description is extremely compact, front-loads the resource, and then lists each action with only the essential distinguishing note. Every phrase earns its place, even with nine actions and 27 parameters behind it.

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?

For a complex, destructive, nine-action tool, the description covers the full action surface and calls out confirmation for final or sent operations. The detailed param schema and annotations fill most remaining gaps, though the description does not explain return values or some void/send side effects. It is complete enough to call correctly, with minor room for richer context.

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 high at 81%, so the schema already carries most parameter meaning. The description consolidates action-to-parameter mappings such as credit_note using amount and reason, send_credit_note using creditNoteId, and recurring using frequency and nextRunDate, but those mappings are largely repeated from the parameter descriptions rather than adding new semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource and enumerates every action with a short verb-level gloss: save_draft creates or edits, issue finalizes, send emails, void, public_link, credit_note, recurring, and stop. This makes the tool's purpose unambiguous even without opening the schema. It does not explicitly distinguish itself from invoices_list, but the action set clearly signals mutation rather than listing.

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 parentheticals give clear action-selection context, such as save_draft for create/edit, issue for final numbering, send for emailing, revoke for public_link, and stop for recurring. The closing instruction 'Confirm anything final or sent' is an explicit operational guideline. It does not name sibling alternatives or say when not to use the tool, 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 Groundbase 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?