Skip to main content
Glama
Sign In

GetAccountED

by za.co.getaccounted
OverviewDiscussionsAdmin

Send an invoice reminder (preview, then confirm)

accounting_send_invoice_reminder

Email GetAccountED's standard branded payment reminder (with pay-online link and the invoice PDF) for one unpaid invoice to the customer's email on file. TWO STEPS: first call shows who it goes to + confirm_token; the email is only sent on the second call with confirm_token. Changes the user's real books — only after they have seen the preview and agreed. Needs the user's GetAccountED sign-in (they are asked to sign in the first time).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "invoice_number": "<invoice_number>"
    },
    "name": "accounting_send_invoice_reminder"
  }
}

Input Schema

NameRequiredDescriptionDefault
business_idNoAccounting practices only: which client's books (an id from accounting_list_my_businesses). Leave out to use the books chosen at sign-in.
confirm_tokenNoSecond step only: the token from the preview
invoice_numberYesThe invoice to remind the customer about (from accounting_list_invoices)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / confirm_token / description
      Previous value: -"Second step only"New value: +"Second step only: the token from the preview"
    • addedInput schema / properties / invoice_number / description
      Added value: +"The invoice to remind the customer about (from accounting_list_invoices)"
  2. Added

TDQS

A3.6/5.0
Behavior3/5

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

Annotations cover the safety profile: readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds genuine context beyond that: the email is only sent on the second call with confirm_token, it changes the user's real books, and it requires the user's GetAccountED sign-in — which explains the openWorldHint/non-read-only annotations rather than repeating them. It doesn't say what happens if the confirm_token is stale or the email bounces.

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 what gets sent and to whom, then the two-step flow, then the safety and auth caveats — a sensible order with no wasted clauses. Slightly dense, with the two-step mechanic repeated in both prose and the confirm_token context.

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 non-idempotent, outward-facing email tool with no output schema, the description covers what is sent, to whom, the two-step confirmation, the books-mutation consequence, and the auth requirement — enough to call it correctly. The main omission is how to pick between this and accounting_debtor_reminder, plus what the preview reveals.

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 100%, so all three parameters are already documented, including business_id for accounting practices and confirm_token as the second-step token. The description echoes the confirm_token flow but adds no syntax, format, or edge-case meaning beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource: emails a branded payment reminder with pay-online link and invoice PDF, for exactly one unpaid invoice, to the customer email on file. Scope is unambiguous, but the description never mentions the sibling accounting_debtor_reminder, which an agent could reasonably confuse with a per-invoice reminder.

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 an explicit precondition — only after the user has seen the preview and agreed — plus the required two-call sequence, which is real when-to-use guidance. It stops short of naming alternatives or telling the agent what to do when the invoice is already paid or the user declines.

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

All GetAccountED toolsInspect
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