Skip to main content
Glama

Simpler.Asia

invoice_debit_note

[REQUIRES APPROVAL] Issues a numbered debit note that raises what an issued ('sent' or 'paid') invoice is owed: an extra charge, or a price or tax correction. It is numbered from the debit note series and adds amount_cents (or a decimal STRING amount), tax at the invoice's rate inside, in its currency; a 'paid' invoice goes back to 'sent' until the rest is paid. Refuses a draft (change its lines instead), a cancelled invoice, an invoice with no lines, another currency, and a paid invoice with no payment recorded (record it first with invoice_payment_record); every refusal names the call to send. Never deleted: undo one with a credit_note. An agent's call parks for approval. Nothing is sent. NEXT: invoice_read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountNoThe amount as a decimal STRING ("25.00") instead of amount_cents — never convert units yourself.
reasonNoWhy the customer owes more, as the debit note prints it (max 500).
currencyNoMust be the invoice's own currency; omit it to use that currency.
debit_kindNoWhat the debit note is for. Omit it for additional_charge.
invoice_idNoThe invoice the debit note raises (invoice_list shows ids); its invoice_number works too.
occurred_atNoEpoch milliseconds the debit note takes effect. Omit it for now.
amount_centsNoThe amount the debit note adds, in integer CENTS.
invoice_numberNoAlias of invoice_id — the invoice's own number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare the generic non-read-only, non-destructive, non-idempotent profile; the description goes far beyond with approval gating ("An agent's call parks for approval"), number-series assignment, side effect on invoice status ('paid' reverts to 'sent'), non-deletability, and the fact that nothing is emailed. The only gap is the exact approval/queue mechanics and whether a parked call can be revoked.

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-loads the approval flag and the core action, then refusals, then the undo path and NEXT pointer. It is a dense single block that would scan better as sentences/bullets, but every clause carries information; nothing is 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?

For a mutation tool with 8 optional params, 100% schema coverage, and no output schema, the description covers preconditions, state transitions, refusals, undo, arithmetic/tax handling, and the natural next call (invoice_read). An agent can call it correctly without further discovery.

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 semantics beyond the schema: tax is computed at the invoice's own rate and included inside amount_cents, and the currency must equal the invoice's currency. It also clarifies the decimal-string vs. cents duality as a single logical amount rather than two separate fields.

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 ("Issues a numbered debit note") plus the exact semantic effect: raising what an issued invoice is owed, via extra charge or price/tax correction. It implicitly separates itself from credit_note (which reverses) and from line edits (invoice_item_update) by naming those as alternatives.

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?

Explicit when-to-use (invoice in 'sent' or 'paid' state) and a full when-not list with a named alternative for each: draft → change its lines; no payment recorded on a paid invoice → invoice_payment_record; undo → credit_note. Nothing is left for the agent to infer.

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.

Resources