Simpler.Asia

invoice_promise_set

Records the date a client promised to pay an issued invoice that still has money owed: promised_payment_date 'YYYY-MM-DD', the business's own date, today or later. clear true removes it. invoice_read then shows promise_status: pending until that business day ends, kept when paid in full by then, broken after it. A broken promise makes promise_follow_up the default purpose of invoice_message_prepare. Each change is kept in the invoice's activity as promise_set. Refuses a draft, a cancelled invoice and one with nothing owed (CONFLICT), and a past or malformed date (VALIDATION_ERROR). Nothing is sent. NEXT: invoice_read.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "invoice_promise_set"
  }
}

Input Schema

Name	Required	Description
`id`	No	The invoice the client promised to pay (invoice_list shows ids); its invoice_number works too.
`note`	No	What the client said, kept in the invoice's activity (max 500).
`clear`	No	true removes the promised date instead of setting one.
`invoice_number`	No	Alias of id — the invoice's own number.
`expected_updated_at`	No	Optional compare-and-set guard: the updated_at you last read. A mismatch returns CONFLICT and changes nothing.
`promised_payment_date`	No	The business-local date the client promised to pay by, YYYY-MM-DD, today or later. Leave it out with clear true.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that each change is logged as 'promise_set' in the invoice activity, that nothing is sent, the exact error codes returned (CONFLICT, VALIDATION_ERROR), and the downstream state machine (pending → kept / broken). This is precisely the mutation/audit context the hints (readOnlyHint=false, destructiveHint=false) cannot convey.

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 purpose, then semantics, then side effects, then failure modes, then the next step — a sensible order with no filler. It is dense and slightly run-on in the middle (promise_status lifecycle packed into one sentence), but every clause carries information an agent needs.

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 no output schema, the description supplies everything needed: input semantics, rejection cases with error codes, observable effects (activity entry, promise_status lifecycle), and the follow-up call. Nothing material is missing.

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; the description earns above baseline by restating the two decision-critical parameters in operational terms: promised_payment_date must be the business's own local date, today or later, and 'clear true removes it instead of setting one'. It does not mention note or expected_updated_at, which remain schema-only.

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 ('Records the date a client promised to pay an issued invoice that still has money owed'), and immediately covers the inverse operation ('clear true removes it'). The scope qualifiers (issued, still owes money) distinguish it from payment-recording siblings like invoice_payment_record.

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?

Explicitly names the conditions under which it applies (issued invoice with an outstanding balance) and the conditions it rejects (draft, cancelled, nothing owed, past/malformed date). It routes forward with 'NEXT: invoice_read' and explains the downstream consequence on invoice_message_prepare.

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

All Simpler.Asia 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?