Skip to main content
Glama
Sign In

defrr

by com.defrr
OverviewDiscussionsAdmin

Process renewals

defrr_process_renewal

Use when customers renew and you need the renewal worked out: send each contract's terms as they stand, and the renewal's end date and the price for the renewal term. Returns the renewal term and how its price compares with the term before it (in total and per month, since a renewal can be a different length), the billing entry to post, the revised month-by-month schedule, and the total to post by month. With the latest closed month, a renewal processed after it started has its billing and catch-up revenue posted in the first open month instead. The renewal is recognised on the contract's own basis: a different basis is a new contract (defrr_create_contract). Up to 50 renewals per call, each with your own id. Costs 1 credit per renewal (refunded if the call fails). Nothing you send is stored.

Input Schema

NameRequiredDescriptionDefault
renewalsYesThe renewals to process, up to 50. Each is charged 1 credit.
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 / renewals / items / 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 / renewals / items / 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. Changed4 schema fields changed
    • addedInput schema / properties / renewals / items / properties / renewal / properties / exchangeRate
      Added value: +{
+  "description": "Required when the schedule has a currency: how much of your base currency one unit of it is worth on the renewal's start date. priceForRenewalTerm is then in that currency.",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / renewals / items / 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 / renewals / items / 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 / renewals / items / 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 / renewals / items / 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 / renewals / items / 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 / renewals / items / 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. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing batch limits (50 per call), per-call credit cost with refund on failure, that supplied data is not retained, and the posting rule when lockedThrough is set (billing and catch-up revenue move to the first open month). These are non-obvious operational traits an agent cannot infer from readOnly/destructive/idempotent hints.

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-loaded with the trigger and the required inputs, then the return shape, then edge-case behavior — a sensible ordering with little waste. The return-value sentence is a long multi-clause run (price comparison total and per month, billing entry, schedule, monthly totals) that would read better as a list, but no sentence is filler.

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?

With no output schema and only two top-level parameters, the description carries the burden well: it enumerates what comes back (renewal term, price comparison total and per month, billing entry, revised schedule, monthly totals) and explains the locked-month posting rule. An agent has enough to call it and interpret the result without opening anything else.

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 coverage is 100% and the nested field descriptions (endDateIncluded, priceForRenewalTerm vs. term price, exchangeRate) are already detailed in the schema. The description restates the input contract at a high level ("send each contract's terms as they stand") without adding semantics beyond what the schema documents, so the baseline 3 applies. The lockedThrough behavior it describes is genuinely added value, but it is framed as posting behavior rather than parameter meaning.

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 up front ("Use when customers renew and you need the renewal worked out") and immediately names the inputs (contract terms, renewal end date, renewal price) and outputs. It also differentiates from a sibling by routing contracts on a different recognition basis to defrr_create_contract.

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?

Gives a clear activation trigger ("when customers renew and you need the renewal worked out") and an explicit exclusion with the alternative tool ("a different basis is a new contract (defrr_create_contract)"). It does not distinguish itself from defrr_reprice_renewal or defrr_cancel_renewal, which are the closest-sounding siblings an agent might confuse it with.

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