Skip to main content
Glama

Reprice the original term of a contract

defrr_reprice_contract

Use when the contract's ORIGINAL term (its first term, before any renewal) was priced too high and needs a credit. Renewals keep their own prices; to correct a renewal use defrr_reprice_renewal. Returns the credit note, the revenue to reverse for months already closed, and the corrected 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.
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.
correctedPriceYesWhat the original term should have cost, in the schedule's currency. Must be lower than its current price.

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. Changed4 schema fields changed
    • changedInput schema / properties / correctedPrice / description
      Previous value: -"What the original term should have cost. Must be lower than its current price."New value: +"What the original term should have cost, in the schedule's currency. Must be lower than its current price."
    • 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.4/5.0
Behavior4/5

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

Adds real context beyond the annotations: it discloses outputs (credit note, revenue to reverse for closed months, corrected revenue by month) and a cost model ('2 credits, refunded if it fails'). What it omits is that idempotentHint=false means repeat calls compound credits, and there is no statement about whether the credit can be undone.

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?

Four tight sentences with no filler: scope first, exclusion second, return values third, cost last. Every sentence carries information an agent needs before invoking.

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?

No output schema exists, but the description names what comes back, and it hints at the lockedThrough posting mechanism. The remaining gap is the non-idempotent mutation risk, which matters for a tool that issues credits.

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 all three parameters including the nested schedule are already fully documented, and the description adds only the framing that renewals carry their own prices. That is the baseline-3 case where the schema does the semantic work.

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 (reprice the contract's ORIGINAL term for a credit) and explicitly bounds the scope: renewals keep their own prices. An agent can distinguish it from defrr_reprice_renewal without opening either schema.

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

Usage Guidelines5/5

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

Gives both the when ('original term was priced too high and needs a credit') and the when-not with a named alternative ('to correct a renewal use defrr_reprice_renewal'). The routing is unambiguous.

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.