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.

Input Schema

TableJSON Schema

Name	Required	Description
`uplift`	No	Enhanced interest: percentage points above base rate, up to 10 (default "10").
`awarded`	No	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".
`offeror`	Yes	Who made the offer. In detailed assessment, claimant means the receiving party and defendant the paying party.
`outcome`	No	"open" (default), "accepted", or "judgment" (in detailed assessment, the end of the assessment).
`fixedRate`	No	Where enhancedBasis is "fixed": the annual rate in percent.
`offerSent`	Yes	The date the offer was sent (YYYY-MM-DD).
`trialDate`	No	The trial date, or the detailed assessment hearing date, if one is fixed (YYYY-MM-DD).
`withdrawn`	No	The offer was withdrawn (CPR 36.17(7)(a)).
`costsUplift`	No	Interest on those costs: percentage points above base rate, up to 10 (default "10").
`offerAmount`	Yes	The offer, in pounds, e.g. "12500" or "12,500.50".
`offerMethod`	No	How the offer was sent (default email).
`proceedings`	No	"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).
`interestFrom`	No	Where interestBasis is "rate": the date interest runs from (YYYY-MM-DD).
`interestRate`	No	Where interestBasis is "rate": the annual rate in percent, e.g. "2".
`judgmentDate`	No	Where there was judgment: its date (in detailed assessment, the end of the assessment) (YYYY-MM-DD).
`relevantDays`	No	The relevant period in days (default "21").
`enhancedBasis`	No	Enhanced interest (CPR 36.17(4)(a)): "above-base" (default) or a "fixed" annual rate.
`interestBasis`	No	Interest on the damages, for the comparison: "rate" (a simple rate from a date, the default), "figures" (amounts you give) or "none".
`interestTotal`	No	Where interestBasis is "figures": the interest awarded in total, in pounds, e.g. "12500" or "12,500.50".
`acceptanceSent`	No	Where accepted: the date the acceptance was sent (YYYY-MM-DD).
`postExpiryCosts`	No	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".
`acceptanceMethod`	No	Where accepted: how the acceptance was sent (default email).
`changedAndBeaten`	No	The offer was changed to be less advantageous, and the result beat the changed terms (CPR 36.17(7)(b)).
`interestToExpiry`	No	Where interestBasis is "figures": the interest up to the end of the relevant period, in pounds, e.g. "12500" or "12,500.50".
`offerAfterCutOff`	No	The offer was sent at or after 4.30pm (for email, fax, delivery or personal service).
`fixedCostsAtExpiry`	No	Fixed costs claims: the fixed costs for the stage reached when the relevant period ended, in pounds, e.g. "12500" or "12,500.50".
`fixedCostsAtJudgment`	No	Fixed costs claims: the fixed costs for the stage reached at judgment, in pounds, e.g. "12500" or "12,500.50".
`acceptanceAfterCutOff`	No	Where accepted: the acceptance was sent at or after 4.30pm.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context — the Bank of England base rate history dependency and the minimum required inputs — but does not disclose output shape, rounding, or how missing optional inputs (e.g. trialDate, awarded) affect the result. Adequate, not rich.

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 in the first clause, followed by the enumerated outputs and then the input hint. The middle section is a long run-on list, but every clause maps to a distinct computed outcome (additional amount, enhanced interest, indemnity costs, 35% uplift, defendant's costs), so it is dense rather than padded.

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 28-parameter calculator with no output schema, the description compensates reasonably by naming the monetary consequences it returns and the CPR provisions that drive them, and by stating the minimum inputs. Remaining gap is the absence of any statement about the response structure or what is returned when the offer is not beaten.

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% with 28 well-documented parameters and 7 enums, so the schema carries parameter meaning entirely; baseline 3 applies. The description only nudges prioritization ('Give at least...', 'add the outcome...') and adds no syntax or semantic detail beyond what the schema already states.

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?

The description opens with a specific verb and resource ('Works out a Part 36 offer in England and Wales') and enumerates the exact computations performed: deemed service timing, relevant period end, timeliness of acceptance, whether the offer was beaten under CPR 36.17(1), and the monetary consequences. That scope is highly distinctive, but no sibling is named (e.g. calculate_deemed_service or calculate_interest_on_costs, which overlap on sub-components), so differentiation is implicit rather than explicit.

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?

Usage is implied by the domain framing and the input hint ('Give at least who made the offer, the amount and the date it was sent; add the outcome to see the consequences'), which tells the agent how to drive the tool. However, there is no when-to-use/when-not-to-use statement and no routing to or away from the overlapping siblings (calculate_deemed_service, calculate_cpr_deadline, calculate_interest_on_costs).

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

All DMD Costs legal costs tools tools Inspect

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

Need Help?