Decknote

Update billing profile

update_billing_profile

Destructive

Sets or changes the user's billing details: business name (required the first time), address, tax id, email, phone, currency, prefixes and next numbers of invoices and estimates, default tax (percentage and name), payment terms in days, payment instructions and default notes; null clears an optional text. New documents copy these; documents already issued keep what they had.

Input Schema

Name	Required	Description
`email`	No	Where clients reply to.
`phone`	No
`taxId`	No
`address`	No
`confirm`	No	true performs the action. Without it (or with any value other than the boolean true) nothing changes and the result is a preview of the effects.
`currency`	No	Three-letter code, e.g. USD.
`businessName`	No	Up to 120 characters.
`defaultNotes`	No	Printed on each new document as its notes.
`autoReminders`	No	Pro. When on, the client of every sent invoice that is past due and unpaid gets a reminder email 3, 7 and 14 days after the due date, in the user's daytime.
`invoicePrefix`	No	e.g. INV-
`estimatePrefix`	No	e.g. EST-
`defaultTaxLabel`	No	e.g. VAT. Up to 30 characters.
`paymentTermsDays`	No	Days from the issue date to the due date, 0 to 365.
`defaultTaxPercent`	No	e.g. 21 or "10,5".
`nextInvoiceNumber`	No
`nextEstimateNumber`	No
`paymentInstructions`	No	Printed on each new document as its terms.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedInput schema / properties / autoReminders

Added value: +{
+  "description": "Pro. When on, the client of every sent invoice that is past due and unpaid gets a reminder email 3, 7 and 14 days after the due date, in the user's daytime.",
+  "type": "boolean"
+}

addedInput schema / properties / confirm

Added value: +{
+  "description": "true performs the action. Without it (or with any value other than the boolean true) nothing changes and the result is a preview of the effects.",
+  "type": "boolean"
+}

AddedOct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds genuinely new behavioral context: nulls clear optional fields, and 'New documents copy these; documents already issued keep what they had' explains the blast radius of the change. It omits that without confirm nothing is written, though the schema documents that clearly.

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?

A single dense sentence front-loads purpose and then enumerates fields efficiently, with the consequence clause placed last. The field list largely mirrors the schema, so part of it is redundant, but there is no 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?

For a 17-parameter mutation with no output schema, the description supplies the key facts an agent needs: what it mutates, null semantics, first-time requiredness, and that issued documents are not retroactively changed. The preview/confirm safety gate is covered by the schema rather than the description, so this is close to complete.

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?

At 71% schema coverage the description adds real meaning beyond the schema: the null-clears convention for optional text fields, the first-time requiredness of businessName (despite required being empty), and the downstream effect of numbering/tax/terms fields. It does not cover confirm or autoReminders, leaving those to the schema.

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 opens with a specific verb+resource ('Sets or changes the user's billing details') and enumerates the concrete fields covered, so an agent can immediately tell this is the write counterpart to get_billing_profile. It stops short of naming that sibling explicitly, but the mutating verb makes the distinction unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'business name (required the first time)' and 'null clears an optional text' give conditional usage hints, but there is no explicit guidance on when to call this versus get_billing_profile or update_account, and no mention of the confirm/preview workflow. Usage is implied rather than stated.

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

All Decknote tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?