invoice_statusOne chased invoice in full: what was billed, what has been paid and what is still owed, every letter sent with its date, the escalation schedule with each stage's state, and what happens next and when.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | The date to judge lateness against, YYYY-MM-DD. Default today | |
| invoice | Yes | The chased invoice: its id (DUN-2026-0001) or its invoice reference |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the returned content in useful detail — payment state, each letter with its date, escalation stages and their individual states, and the next action with timing — which tells an agent what to expect from a read. It stops short of stating that the call is read-only or what happens for an unknown invoice reference.
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?
A single front-loaded sentence opens with the scope ('one chased invoice in full') and then enumerates the payload. It reads as a long run-on list, but every clause describes distinct returned content, so little is wasted.
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?
There is no output schema, so the description must convey the return shape, and it does so thoroughly (amounts, letters, escalation schedule, next action). With parameters fully documented in the schema and only two of them, the definition is nearly complete; only read-only status and error behavior are unstated.
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 both parameters carry their own format guidance (invoice id vs. reference, the 'on' date with default today), so the schema does the heavy lifting. The description adds nothing about parameters, which is the expected baseline when coverage is complete.
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 resource ('one chased invoice in full') and enumerates exactly what state it reports — billed, paid, owed, letters, escalation schedule. The word 'one' implicitly separates it from the list-oriented siblings (overdue_list, aging_summary, invoice_register), but no sibling is named, so it stops short of a 5.
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?
Usage is only implied: the phrase 'one chased invoice' signals a single-invoice lookup rather than an aggregate view, which is the natural alternative among the siblings. There is no explicit when-to-use, no named alternative, and no stated prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.