Skip to main content
Glama

Cancel a renewal

defrr_cancel_renewal

Use when the latest renewal is cancelled and refunded in full. Returns the credit note, the reversal for closed months and the revenue month by month. Costs 2 credits (refunded if it fails).

Input Schema

NameRequiredDescriptionDefault
scheduleYesThe contract's terms. The first term needs a startDate; each later term (a renewal) starts the day after the previous one ends when endDateIncluded is true (the default), or on the day the previous one ends when it is false.
termIndexYesWhich term: 1 is the first renewal, 2 the second, and so on. Only the latest renewal can be corrected for now, so give the position of the last term.
lockedThroughNoThe latest month already closed for changes, as YYYY-MM. Revenue in that month and earlier cannot be changed, so the correction is posted in the next month. Leave out or null if no month is closed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / schedule / properties / terms / items / properties / price / description
      Previous value: -"The term's total price."New value: +"The term's total price: for all its units, not per unit."
    • addedInput schema / properties / schedule / properties / terms / items / properties / quantity
      Added value: +{
      +  "description": "Optional: how many units (seats) the term's total price covers, 1 if you leave it out. It doesn't change the schedule, which follows the total; it is recorded with the contract so its unit price can be seen.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / schedule / properties / currency
      Added value: +{
      +  "description": "Only for a contract priced in a foreign currency: its code, such as EUR. Every term's price is then in that currency, and each term needs an exchangeRate.",
      +  "pattern": "^[A-Za-z]{3}$",
      +  "type": "string"
      +}
    • addedInput schema / properties / schedule / properties / exchangeRate
      Added value: +{
      +  "description": "With currency: the rate for every term that has none of its own.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / schedule / properties / terms / items / properties / exchangeRate
      Added value: +{
      +  "description": "With currency: how much of your base currency ONE unit of the foreign currency was worth when this term was booked. Corrections use it, so they agree with what was billed.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / properties / schedule / description
      Previous value: -"The contract's terms. The first term needs a startDate; each later term (a renewal) starts the day after the previous one ends when endDateIncluded is true, or on the day the previous one ends when it is false."New value: +"The contract's terms. The first term needs a startDate; each later term (a renewal) starts the day after the previous one ends when endDateIncluded is true (the default), or on the day the previous one ends when it is false."
    • changedInput schema / properties / schedule / properties / endDateIncluded / description
      Previous value: -"True if a term's end date is its last day (a 1 Jan to 31 Dec term). False if the end date is the first day of the next term. Defaults to false, so for a new contract send true with the last day the customer is covered (a year from 1 Mar 2026 is endDate 2027-02-28)."New value: +"Always send it. True if a term's end date is its last day (a year from 1 Mar 2026 ends 2027-02-28): use true unless the user's own dates show otherwise. False if the end date is the first day of the next term, as when the user gives the same calendar day a whole number of months later (10 Feb 2027 to 10 Feb 2028, so the last covered day is 9 Feb 2028). Defaults to true if left out."
  4. Changed1 schema field changed
    • changedInput schema / properties / schedule / properties / endDateIncluded / description
      Previous value: -"True if a term's end date is its last day (a 1 Jan to 31 Dec term). False if the end date is the first day of the next term. Defaults to false."New value: +"True if a term's end date is its last day (a 1 Jan to 31 Dec term). False if the end date is the first day of the next term. Defaults to false, so for a new contract send true with the last day the customer is covered (a year from 1 Mar 2026 is endDate 2027-02-28)."
  5. First observed

TDQS

B3.3/5.0
Behavior4/5

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

The description adds meaningful behavior beyond the annotations: it says the tool returns the credit note, reversal for closed months, and month-by-month revenue, and that the operation costs 2 credits with refund on failure. It does not fully explain the mutation's side effects or permissions, but the cost/refund and return-content disclosures are valuable.

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?

The description is compact and front-loads the usage condition, then follows with return contents and cost. It earns its space, though the first sentence is awkwardly phrased and could more directly state the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation with nested contract terms and no output schema, the description helpfully explains what is returned and the credit cost. However, the ambiguity about whether the tool performs cancellation or reports an already-cancelled renewal leaves a notable contextual gap.

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 the nested schedule, termIndex, and lockedThrough parameters are already well documented in the schema. The description does not add parameter-specific semantics beyond the schema's own detail, which is appropriate baseline behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource ('the latest renewal') and refund scope, but its opening phrase 'Use when the latest renewal is cancelled...' sounds like a condition rather than clearly stating that this tool performs the cancellation. The name and title help, yet the description alone leaves the action somewhat ambiguous, especially versus a query or the sibling defrr_cancel_contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one usage trigger ('when the latest renewal is cancelled and refunded in full') and implies only the latest renewal is eligible, but it does not name alternatives such as defrr_cancel_contract or defrr_reprice_renewal, nor does it state when not to use this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.