Create PDF invoices from your AI chat: clients, numbering, VAT, overdue reports. All data is local.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
Each tool targets a distinct resource and action: business profile, client CRUD, invoice lifecycle (create, get, list, mark paid, PDF), licensing, and reporting. Even invoice_create vs invoice_from_hours are clearly separated by purpose (generic vs hourly shortcut), with descriptions clarifying their use.
Most tools follow verb_noun (business_set, client_add, client_delete, client_list, invoice_create, invoice_get, invoice_list, invoice_mark_paid, license_activate). A few deviate (invoice_pdf uses a noun as the action, license_status is noun_noun), but the pattern is largely predictable and readable.
13 tools is well-scoped for an invoicing suite, covering core client management, invoice operations, payments, PDF generation, and licensing. Each tool has a clear role without bloat.
Core workflows are covered: client management, invoice creation, retrieval, listing, payment marking, PDF export, and overdue reporting. However, there are notable gaps: no tool to create credit notes (though they are referenced in invoice_get/invoice_list), no invoice update/edit, and no way to cancel/void an invoice. Also, mentions of quotes, purchase orders, deposits, etc., imply a broader document suite that is not exposed here.
The ONE business profile for the whole suite: name, address, VAT id, bank details and defaults (currency, tax rate, terms, prefix, timezone). Saved to the shared profile every other server reads. Call it once, first.
| Name | Required | Description | Default |
|---|---|---|---|
| vat | No | Alias for default_tax_rate | |
| bank | No | Bank name / BIC | |
| iban | No | IBAN or account number for payment | |
| name | Yes | Your business or freelancer name | |
| No | Your own email address. Leave it out unless the user gave it: no server ever fills an email from anything but this profile or an explicit argument | ||
| phone | No | Your own phone number. Same rule as email: only if the user gave it | |
| vat_id | No | VAT / tax registration id | |
| address | No | Postal address, newlines allowed | |
| tax_rate | No | Alias for default_tax_rate | |
| timezone | No | IANA zone you work in, e.g. Europe/Warsaw. Shared with time-tracker (entries are stamped in it) and timezone (your home zone) | |
| vat_rate | No | Alias for default_tax_rate | |
| logo_path | No | Path to a PNG or JPG logo (Pro) | |
| invoice_prefix | No | Invoice number prefix, default INV (custom prefix is Pro) | |
| default_currency | No | ISO code, e.g. EUR, USD, JPY. Default EUR | |
| default_tax_rate | No | Default VAT percent applied to items without their own rate | |
| payment_terms_days | No | Default days until due. Default 14 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by revealing the persistence and shared side effect: the saved profile is read by every other server. It also warns about usage frequency with 'Call it once, first,' which is meaningful given idempotentHint is false. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver the resource scope, the shared-profile side effect, and the sequencing rule. There is no filler, and the most decision-relevant fact ('call it once, first') is front-loaded at the end of a concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter mutation tool, the schema fully documents parameters, and the description adds the critical context: shared persistence, broad impact, and call ordering. With no output schema, a return-value description is not necessary for correct invocation. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description, so the baseline is 3. The description enumerates categories of fields but adds no parameter-level meaning beyond the schema, which carries the full semantic load here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and resource ('business profile'), plus the fields it covers: name, address, VAT id, bank details, and defaults. 'The ONE business profile for the whole suite' clearly distinguishes it from the client and invoice sibling tools, which work on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Call it once, first.' It also explains why sequencing matters by stating that the profile is 'Saved to the shared profile every other server reads,' so an agent knows this should precede dependent operations. No alternatives are needed because no sibling tool covers business profile setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a client so invoice_create can refer to them by name. Re-adding the same name updates the stored address, email and VAT id; a record identical to a stored one is refused, naming the id that already holds it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| No | |||
| vat_id | No | Client VAT id, printed for reverse-charge invoices | |
| address | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses substantial behavior beyond the sparse annotations: re-adding the same name updates stored address, email, and VAT id, while an identical record is refused with the existing record's id. This gives the agent a precise mental model of the upsert and duplicate-handling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with the primary purpose first and the behavioral edge cases second. Every clause contributes new information, with no filler or repetition of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers purpose, usage, update semantics, and duplicate-conflict response, which is substantial for a tool with no output schema and sparse annotations. The agent has enough information to invoke it correctly and anticipate key edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description compensates by explaining that name is the identity key and address/email/vat_id are the updateable fields. It does not provide format or validation details, but it adds meaningful semantic context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Store a client', a specific verb and resource, and immediately adds the purpose: so invoice_create can refer to them by name. This clearly distinguishes client_add from read-only siblings like client_list or invoice tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by tying the tool to invoice creation and explaining that re-adding the same name updates an existing client. It does not explicitly name alternatives or state when not to use it, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one stored client that nothing refers to. A client named on any invoice, quote, credit note, purchase order, deposit, statement or schedule is refused with those documents listed.
| Name | Required | Description | Default |
|---|---|---|---|
| client | Yes | Client name or id, exactly as client_list shows it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructive hint annotation already flags mutation, but the description adds valuable behavioral detail: deletion is conditional on absence of references, and refused deletions list the offending documents. This goes beyond the annotation and helps an agent predict failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full meaning: the first states the operation and precondition, the second states the failure behavior. There is no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with annotations and full schema coverage, the description is complete: it defines the valid target, the constraint, and the refusal response. No output schema is needed to make correct use unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the client parameter already specifies 'Client name or id, exactly as client_list shows it'. The description adds no parameter-specific information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete one stored client', and adds a distinguishing scope condition ('that nothing refers to'). This separates it clearly from sibling tools like client_add and client_list, and the reference-refusal behavior adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the condition under which the tool is appropriate: only clients with no references can be deleted, and it explicitly describes the refusal case when the client appears on any listed document. It does not name alternative sibling tools explicitly, but the condition is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every stored client with id, address, email and VAT id. No arguments, and it writes nothing. With none stored it says so: invoice_create also creates a client from the name you pass.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds useful behavioral context beyond annotations: it states the empty-list behavior ('With none stored it says so') and notes that invoice_create can create a client, which helps interpret an empty result. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The final note about invoice_create is slightly tangential but still adds context about empty results; overall it earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool without an output schema, the description is complete: it names the result fields, states the empty-case behavior, and confirms no side effects. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object with 100% coverage, so there is essentially no parameter semantics to add. The description explicitly confirms 'No arguments,' which is sufficient and aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('every stored client') plus the exact fields returned (id, address, email, VAT id). It is immediately distinguishable from siblings such as client_add and client_delete, and even clarifies the no-argument nature of the call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to call this tool (need to see all stored clients) and explicitly notes it takes no arguments and writes nothing, signaling it is a safe read-only list operation. It does not explicitly enumerate when not to use it, but the purpose is self-evident among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an invoice from line items and return the record with its next, never-reused number. unit_price is in MAJOR units; lines are rounded then summed. One currency per invoice. Free: 3 a month.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Line items. Amounts are held as integer minor units and every line is rounded first, then summed, so the printed lines can never disagree with the total. A line may carry its own currency | |
| notes | No | Free text printed under the totals | |
| client | Yes | Client name or id. Unknown names are added automatically | |
| currency | No | Invoice currency, 3-letter ISO code. Defaults to the one currency every item agrees on, else your business default. Every line on one invoice must agree with it; a mix is refused with the exact conversion argument to pass rather than billed as if it were one currency | |
| due_days | No | Days until due, defaults to your payment terms | |
| issue_date | No | YYYY-MM-DD, defaults to today | |
| discount_percent | No | Discount percent applied to every line before tax, 0-100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, etc.), the description discloses meaningful behaviors: the invoice number is next and never-reused, unit prices are in major units, lines are rounded then summed, and only one currency is allowed per invoice. It also mentions the free-tier limit of 3 per month, which is useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences long and every sentence earns its place: the first defines the action and return value, the second clarifies unit and rounding semantics, the third states a key constraint, and the fourth gives the free-tier quota. Information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is fully self-describing, and the description adds the key behavioral facts an agent needs: the returned record includes a never-reused number, unit prices are major units, and rounding/currency rules. It doesn't mention sibling alternatives or idempotency, but for a write tool with a rich schema this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3, but the tool description adds global semantics not obvious from the schema: unit_price is in MAJOR units, lines are rounded individually before summing, and one currency per invoice is enforced. These invariants clarify how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Create') and resource ('invoice') and defines the input as line items, making the core purpose unmistakable. It doesn't explicitly distinguish itself from the sibling 'invoice_from_hours', but 'from line items' implies that alternative path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings such as invoice_from_hours or invoice_mark_paid. No when-to-use, when-not-to-use, or alternative tool is mentioned, so an agent must infer usage from the tool name and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shortcut for the common case: bill one client for N hours at an hourly rate. Creates and returns a single-line invoice, converting the rate into target_currency when you supply fx_rates, and echoing back any entry_ids.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | Yes | Hourly rate in major units, expressed in currency (or the business default currency) | |
| hours | Yes | ||
| notes | No | ||
| client | Yes | ||
| currency | No | Currency the rate is in. Without target_currency this is also the invoice currency | |
| due_days | No | ||
| fx_rates | No | Conversion rates, the same pair expense_to_invoice takes: fx_rates maps the RATE's currency to the number of target units one of it buys, meaning 1 unit of that currency = X units of target_currency, e.g. {"EUR": 1.1578} with target_currency "USD". You supply the rate; nothing here fetches or guesses one | |
| tax_rate | No | ||
| entry_ids | No | Time-tracker entry ids these hours came from (the entry_ids invoice_summary returns). Echoed back with the new invoice number so you can call entry_mark_billed | |
| issue_date | No | ||
| description | No | Line description, default 'Consulting services' | |
| round_total | No | D-R46: when converting with fx_rates, round the line's TOTAL to the exact converted amount instead of rounding the hourly rate to cents first. Default false keeps the D-R24 basis (unit price x hours always equals the printed line, so a rounding_note explains any drift from the exact conversion); true removes the drift but unit_price x hours may then be a cent or two off the printed total. | |
| target_currency | No | Issue the invoice in this currency instead, converting the rate. Needs fx_rates for the rate currency | |
| discount_percent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide false hints, so the description carries the burden. It discloses the create side effect and adds useful behavioral details: rate conversion when fx_rates is supplied and echoing back entry_ids. However, it omits broader side effects, return shape specifics, or prerequisites beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the core purpose and then add the most important behavioral nuances. No filler or redundant restatement of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, nested objects, no output schema, and sparse annotations, the description provides only a minimal working picture. It covers the common-case invocation and key conversion/echo behavior, but an agent lacks guidance on return format and the many optional parameters that affect invoice output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description compensates partially by explaining the roles of target_currency, fx_rates, and entry_ids. It also implies the required client/hours/rate relationship. But many optional parameters (tax_rate, due_days, discount_percent, notes, etc.) receive no semantic guidance here or in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Creates'), the resource (a single-line invoice), and the exact business scenario (billing one client for N hours at an hourly rate). It is more specific than the generic sibling invoice_create, though it does not explicitly name that sibling as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Shortcut for the common case' establishes a clear usage context: use this when a simple time-based invoice is needed. It does not state exclusions or explicitly compare against invoice_create, but the common-case framing is enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full stored record for one invoice number, including every line, tax breakdown, and the balance still open after any credit note issued against it (see credited_minor).
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context about the return content: every line, tax breakdown, and the open balance after credit notes. The parenthetical 'see credited_minor' is somewhat cryptic but does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core action and return contents efficiently. The parenthetical 'see credited_minor' is slightly ambiguous, but it does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple single-parameter read operation, the description covers the most important contextual aspects: what is returned, the scope, and the credit-note balance nuance. There is no output schema, so describing the return contents is valuable. The description is sufficient for an agent to select and invoke the tool correctly in most cases, though it omits error behavior for missing invoices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a required 'number' parameter with zero description coverage. The description adds the key semantic that this is an invoice number, which is essential. However, it does not specify expected format, examples, or edge cases, and with 0% schema coverage a stronger parameter explanation would have been helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return'), a specific resource ('the full stored record for one invoice number'), and the exact scope (one invoice). It clearly distinguishes itself from invoice_list by focusing on a single full record and from invoice_pdf by returning the stored record rather than a generated document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool when you need the complete stored record for one invoice number. However, it does not explicitly specify when not to use it or name alternatives such as invoice_list for summaries or invoice_pdf for a document. The contrast with list-like siblings is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List invoices by number: client, dates, currency, subtotal, discount, tax lines, total, status, paid, credited and the balance still due after any credit note. Filter by status, client and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD inclusive | |
| from | No | YYYY-MM-DD inclusive | |
| client | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful output detail, including credited amounts and balance due, but does not mention pagination, ordering, or whether the result is limited in any way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the main action front-loaded and no filler. The list of returned fields is compact. The phrase 'by number' adds minor ambiguity but does not significantly hurt comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with four optional filters and no output schema, the description covers the core return fields and available filters. It lacks pagination/ordering details, but annotations cover the safety profile and the schema covers date formats, making this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, covering from/to but not client or status. The description names status, client, and date range as filters, adding some meaning beyond the schema, but it does not clarify the client parameter's format or semantics beyond the field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('invoices'), and enumerates the fields returned (client, dates, currency, totals, status, balance due). It is clear what the tool does, though it does not explicitly differentiate itself from siblings like invoice_get or invoice_pdf, and the phrase 'by number' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the filtering dimensions: status, client, and date range, which implies when to use this tool. However, it does not explicitly contrast it with invoice_get for single-invoice lookup or overdue_report for overdue-focused reporting, so usage guidance relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a payment on one invoice. amount is in MAJOR units and ADDS to what is paid, never replaces it; omit it to settle the rest. An overpayment is refused, naming the open balance.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Amount received in major units, ADDED to what is already paid on this invoice. Omit to pay off the remaining balance in full | |
| method | No | How it was paid, e.g. bank transfer, card. Stored on this payment's row | |
| number | Yes | ||
| paid_date | No | YYYY-MM-DD, defaults to today | |
| reference | No | Bank reference or transaction id for this payment. Stored on this payment's row |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavior: amount is in MAJOR units, it ADDS to existing paid balance rather than replacing it, omitting it settles the remainder, and overpayments are refused with the open balance named. This matches the non-idempotent annotation by warning that each call likely adds another payment record. It could add what the response contains or whether the action is reversible, but it is already strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no fluff, and the most critical constraint (MAJOR units + additive behavior) is front-loaded. Every sentence carries behavioral or usage value. It is efficiently scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers the main invocation-relevant behaviors: amount semantics, default settlement, and error case. The only mildly missing piece is what a successful call returns (e.g., updated invoice, payment record) and whether multiple partial payments are intended to accumulate. These are minor since the core call semantics are fully stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents amount, method, paid_date, and reference. The description repeats the amount semantics in clearer emphasis (MAJOR units, ADDS, omit to settle) but does not explain the 'number' parameter, which has no schema description. This is adequate but not additive enough to rise above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Record a payment on one invoice,' a specific verb and resource that clearly differentiates this from invoice_create, invoice_list, and invoice_pdf. The additive payment semantics further pin down the exact operation. No other sibling tool performs payment recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: when a payment needs to be recorded against a single invoice, this is the tool. It does not explicitly name alternatives or exclusion conditions, but the use case is unambiguous given the sibling tool names. A dedicated when-not-to-use note would improve it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool to write one stored invoice as an A4 PDF and return the path: issuer, BILL TO, dates, items, taxes and totals. Free stamps a credit line and no logo; Pro renders it unbranded with your logo.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Invoice number to render, as returned by invoice_create | |
| out_path | No | Where to write the PDF; defaults to <data dir>/pdf/<number>.pdf. The page carries the issuer block, the BILL TO client block, dates, an item table with wrapped descriptions, subtotal, discount, one tax line per rate, the total, payment details and notes, and every money value on it carries its currency code. Use a .pdf path: the bytes written are always PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it writes a file to a path, returns the path, includes specific content blocks, and notes that Free vs Pro affects branding and logo. It also warns that the bytes written are always PDF, which is a useful edge-case disclosure. It doesn't mention potential errors or side effects, but the annotations cover the main safety concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and output, and every clause adds useful information. The first sentence states the purpose and the second explains the Free/Pro difference. No filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is quite complete. It explains what the PDF contains, the default output path, and the branding difference. It doesn't describe the return value format (e.g., whether it returns just a path or a JSON object), but since there is no output schema, a brief note on the return shape would have been helpful. Still, the description is strong for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the output path default and the content of the PDF, which helps the agent understand what 'out_path' means and what the result will look like. It doesn't add much about the 'number' parameter beyond what the schema says, but the schema already says it's the invoice number returned by invoice_create. Overall, the description complements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('write'), a specific resource ('one stored invoice'), and the output format ('A4 PDF'), and it distinguishes itself from sibling tools by focusing on rendering an existing invoice to PDF rather than creating or listing invoices. It also clarifies the difference between Free and Pro branding, which is unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this tool to write one stored invoice as an A4 PDF', which gives clear context for when to use it. It does not explicitly name alternatives or exclusions, but the sibling list and the focus on rendering an existing invoice make the usage context clear enough. A small gap is that it doesn't explicitly say 'use invoice_create first' or 'use invoice_get to view instead', but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every invoice not paid in full whose due date has passed, worst first, with days overdue and the amount, then a total per currency. Free. Use invoice_list for everything still open.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | YYYY-MM-DD, defaults to today |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is known. The description adds useful behavioral context beyond annotations: sorting ('worst first'), computed fields ('days overdue and the amount'), and currency grouping/totals. It does not detail as_of edge-case handling, but that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core behavior is front-loaded in a single tight sentence, and the sibling routing is clear. The standalone 'Free.' contributes little to an agent's selection or invocation decision, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter read-only report, the description is nearly complete: it explains what is returned, how results are sorted and grouped, and when to prefer invoice_list. It does not enumerate exact response fields, but the text sufficiently describes the report content given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one optional parameter and the schema already documents its format ('YYYY-MM-DD') and default ('defaults to today'), giving 100% schema description coverage. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('invoices'), the exact filter ('not paid in full whose due date has passed'), and the output shape ('days overdue and the amount, then a total per currency'). It also distinguishes itself from invoice_list by saying that invoice_list covers everything still open.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent to the sibling tool when appropriate: 'Use invoice_list for everything still open.' This is a clear when-not/alternative statement, and the first sentence makes the intended use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
business_setclient_addclient_deleteclient_listinvoice_createinvoice_from_hoursinvoice_getinvoice_listinvoice_mark_paidinvoice_pdflicense_activatelicense_statusoverdue_reportCreate PDF invoices from your AI chat: clients, numbering, VAT, overdue reports. All data is local.
Create PDF invoices from your AI chat: clients, numbering, VAT, overdue reports. All data is local.
Send invoices from Claude and ChatGPT. One sentence becomes a PDF with a Stripe payment link.
Compliant invoicing for freelancers: create, issue and track invoices from your AI agent.
Add one secure layer between your agents and this server.
