Skip to main content
Glama

DMD Costs legal costs tools

Part 36 calculator (CPR 36.17 consequences)

calculate_part_36_offer
Read-onlyIdempotent

Works out a Part 36 offer in England and Wales: when it was made (deemed service, CPR 6.26 and 36.7) and when its relevant period ends; whether an acceptance was in time (CPR 36.13); whether the judgment, or the detailed assessment, beat the offer (CPR 36.17(1)); and the consequences in money: the additional amount, enhanced interest of up to 10% above base rate, indemnity costs and interest on them, the 35% uplift in fixed costs claims (CPR 36.24), or the defendant's costs. Uses the Bank of England's base rate history. Give at least who made the offer, the amount and the date it was sent; add the outcome to see the consequences.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "offeror": "<offeror>",
      "offerAmount": "<offerAmount>",
      "offerSent": "<offerSent>"
    },
    "name": "calculate_part_36_offer"
  }
}

Input Schema

NameRequiredDescriptionDefault
upliftNoEnhanced interest: percentage points above base rate, up to 10 (default "10").
awardedNoWhere there was judgment: the damages awarded, excluding interest (in detailed assessment, the bill as assessed), in pounds (e.g. "12500.50").
offerorYesWho made the offer. In detailed assessment, claimant means the receiving party and defendant the paying party.
outcomeNo"open" (default), "accepted", or "judgment" (in detailed assessment, the end of the assessment).
fixedRateNoWhere enhancedBasis is "fixed": the annual rate in percent.
offerSentYesThe date the offer was sent.
trialDateNoThe trial date, or the detailed assessment hearing date, if one is fixed.
withdrawnNoThe offer was withdrawn (CPR 36.17(7)(a)).
costsUpliftNoInterest on those costs: percentage points above base rate, up to 10 (default "10").
offerAmountYesThe offer, in pounds (e.g. "12500.50").
offerMethodNoHow the offer was sent (default email).
proceedingsNo"claim" for a claim outside the fixed costs regimes (default), "fixed-costs" for a claim in Part 45 Sections VI to VIII, or "assessment" for an offer on the bill in detailed assessment (CPR 47.20).
interestFromNoWhere interestBasis is "rate": the date interest runs from.
interestRateNoWhere interestBasis is "rate": the annual rate in percent, e.g. "2".
judgmentDateNoWhere there was judgment: its date (in detailed assessment, the end of the assessment).
relevantDaysNoThe relevant period in days (default "21").
enhancedBasisNoEnhanced interest (CPR 36.17(4)(a)): "above-base" (default) or a "fixed" annual rate.
interestBasisNoInterest on the damages, for the comparison: "rate" (a simple rate from a date, the default), "figures" (amounts you give) or "none".
interestTotalNoWhere interestBasis is "figures": the interest awarded in total, in pounds (e.g. "12500.50").
acceptanceSentNoWhere accepted: the date the acceptance was sent.
postExpiryCostsNoCosts from the end of the relevant period, for interest on costs (CPR 36.17(4)(c)), in pounds (e.g. "12500.50").
acceptanceMethodNoWhere accepted: how the acceptance was sent (default email).
changedAndBeatenNoThe offer was changed to be less advantageous, and the result beat the changed terms (CPR 36.17(7)(b)).
interestToExpiryNoWhere interestBasis is "figures": the interest up to the end of the relevant period, in pounds (e.g. "12500.50").
offerAfterCutOffNoThe offer was sent at or after 4.30pm (for email, fax, delivery or personal service).
fixedCostsAtExpiryNoFixed costs claims: the fixed costs for the stage reached when the relevant period ended, in pounds (e.g. "12500.50").
fixedCostsAtJudgmentNoFixed costs claims: the fixed costs for the stage reached at judgment, in pounds (e.g. "12500.50").
acceptanceAfterCutOffNoWhere accepted: the acceptance was sent at or after 4.30pm.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • changedInput schema / properties / acceptanceSent / description
      Previous value: -"Where accepted: the date the acceptance was sent (YYYY-MM-DD)."New value: +"Where accepted: the date the acceptance was sent."
    • changedInput schema / properties / awarded / description
      Previous value: -"Where there was judgment: the damages awarded, excluding interest (in detailed assessment, the bill as assessed), in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"Where there was judgment: the damages awarded, excluding interest (in detailed assessment, the bill as assessed), in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / fixedCostsAtExpiry / description
      Previous value: -"Fixed costs claims: the fixed costs for the stage reached when the relevant period ended, in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"Fixed costs claims: the fixed costs for the stage reached when the relevant period ended, in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / fixedCostsAtJudgment / description
      Previous value: -"Fixed costs claims: the fixed costs for the stage reached at judgment, in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"Fixed costs claims: the fixed costs for the stage reached at judgment, in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / interestFrom / description
      Previous value: -"Where interestBasis is \"rate\": the date interest runs from (YYYY-MM-DD)."New value: +"Where interestBasis is \"rate\": the date interest runs from."
    • changedInput schema / properties / interestToExpiry / description
      Previous value: -"Where interestBasis is \"figures\": the interest up to the end of the relevant period, in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"Where interestBasis is \"figures\": the interest up to the end of the relevant period, in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / interestTotal / description
      Previous value: -"Where interestBasis is \"figures\": the interest awarded in total, in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"Where interestBasis is \"figures\": the interest awarded in total, in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / judgmentDate / description
      Previous value: -"Where there was judgment: its date (in detailed assessment, the end of the assessment) (YYYY-MM-DD)."New value: +"Where there was judgment: its date (in detailed assessment, the end of the assessment)."
    • changedInput schema / properties / offerAmount / description
      Previous value: -"The offer, in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"The offer, in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / offerSent / description
      Previous value: -"The date the offer was sent (YYYY-MM-DD)."New value: +"The date the offer was sent."
    • changedInput schema / properties / postExpiryCosts / description
      Previous value: -"Costs from the end of the relevant period, for interest on costs (CPR 36.17(4)(c)), in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"Costs from the end of the relevant period, for interest on costs (CPR 36.17(4)(c)), in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / trialDate / description
      Previous value: -"The trial date, or the detailed assessment hearing date, if one is fixed (YYYY-MM-DD)."New value: +"The trial date, or the detailed assessment hearing date, if one is fixed."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety bar is low. The description adds valuable behavioral context beyond annotations: it uses Bank of England base rate history and explains that the output is monetary consequences such as additional amount, enhanced interest and indemnity costs.

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 purpose and scope are front-loaded, and the dense statutory enumeration earns its place for a 28-parameter legal calculator. It is long but not padded, with no irrelevant sentences.

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?

There is no output schema, but the description lists the main monetary consequences the tool produces and the legal rules applied. For a read-only calculator with fully documented parameters this is nearly complete, though exact return values are only summarized conceptually.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries parameter meanings. The description still adds useful selection guidance by identifying the minimum required inputs and clarifying that the outcome parameter is what triggers the consequence calculations.

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?

The description names a specific legal resource and verb: working out a Part 36 offer under CPR 36.17 consequences. It enumerates the exact sub-calculations (deemed service, relevant period, acceptance timing, beating the offer, monetary consequences), making the tool's scope unmistakable versus sibling deadline or interest calculators.

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?

It gives clear minimum inputs ('Give at least who made the offer, the amount and the date it was sent') and explains that adding the outcome unlocks the consequences. It does not explicitly say when not to use it or name alternatives such as calculate_deemed_service, so it falls short of the top band.

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.

Resources