Skip to main content
Glama
Sign In

defrr

by com.defrr
OverviewDiscussionsAdmin

Cancel a contract

defrr_cancel_contract

Use when a whole contract is voided and refunded. Reverses everything recognised in closed months and removes the rest. 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.
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

A4/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the credit cost (2 credits, refunded on failure) and the concrete accounting effect: closed-month revenue is reversed, open periods are removed. The only tension is that 'removes the rest' reads destructive while destructiveHint=false; this is plausibly an accounting reversal rather than a hard delete, so it is not a clear contradiction but leaves some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: usage trigger first, then effect, then cost. Every sentence carries distinct information with no repetition of the title or schema.

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 two-parameter nested mutation with no output schema, the description covers trigger, reversibility scope and cost. It does not state what the call returns or how the closed-month correction appears afterwards, which is a minor remaining 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% and every parameter, including nested term fields and lockedThrough, is documented in the schema. The description adds no parameter-level detail beyond the schema, 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 action and scope: voiding and refunding a whole contract, reversing recognised revenue and removing the remainder. It implicitly separates itself from defrr_cancel_renewal by specifying 'whole contract', but never names that sibling, so the differentiation requires inference.

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?

'Use when a whole contract is voided and refunded' gives a clear triggering condition. However, it offers no explicit exclusion against defrr_cancel_renewal or defrr_reprice_contract, which are the closest alternatives an agent would weigh.

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

All defrr 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