Pause an active recurring invoice schedule to stop future invoices from being issued, while leaving already issued invoices unchanged.
Stop a schedule issuing invoices, for now.
Only an active schedule can be paused; anything else is refused with 409.
Nothing already issued changes. Restart it with resume_recurring_invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| recurring_id | Yes |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does much of it: state prerequisite, HTTP 409 refusal for non-active schedules, and the side-effect scope ("Nothing already issued changes"). What remains undisclosed is the response payload and any permission requirements, which matters for a mutation tool.
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, zero filler, with the core action first and the constraint and reversal path after it. Every sentence adds information an agent would otherwise have to guess.
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 one-parameter mutation with no annotations and no output schema, the definition covers precondition, error behavior, side effects, and the recovery path. Only the identifier's provenance and the success response shape are absent, which are minor for a tool this narrow.
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 0% and the single parameter `recurring_id` is never mentioned in the description, so its format, where it comes from (presumably recurring_list/recurring_create), and whether it accepts an external reference are unstated. The parameter is self-evidently an identifier on a one-param tool, which keeps this at minimum-viable rather than failing.
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?
Opens with a specific verb+object ("Stop a schedule issuing invoices") plus the crucial temporal qualifier "for now", which distinguishes it from recurring_cancel without naming that sibling. It also points at the inverse operation, resume_recurring_invoice, so an agent can place the tool in the lifecycle immediately.
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?
"Only an `active` schedule can be paused; anything else is refused with 409" gives an explicit precondition and failure mode, and "Restart it with `resume_recurring_invoice`" names the alternative. It stops short of saying when to choose pause over recurring_cancel, leaving the temporary-vs-permanent distinction to be inferred from "for now".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.