Free tools for civil costs in England and Wales: CPR deadlines, Part 36, fees, interest.
Scored across 10 tools
Most tools have clearly distinct purposes, such as court fees, interest, Part 36 offers, and J-code lookup. However, the three deadline calculators (calculate_cpr_deadline, calculate_deemed_service, calculate_detailed_assessment_deadlines) overlap for general deadline questions, and search_legal_costs_help can duplicate any calculator for high-level queries, so selection may occasionally be ambiguous.
All tool names use consistent snake_case and follow a verb_noun pattern (calculate_*, check_*, find_*, look_up_*, search_*). The naming is predictable and readable throughout the set.
Ten tools is well within the ideal 3-15 range for a specialized legal costs server. Each tool covers a distinct sub-domain, and none appears redundant or trivial.
The surface covers major costs workflows: court fees, CPR deadlines, deemed service, detailed assessment deadlines, interest, Part 36, J-codes, court finding, and Awaab's Law timescales. Minor gaps remain, such as a dedicated costs budget (Precedent H) calculator or a bill-of-costs total calculator, but these can be partly addressed via search_legal_costs_help.
Works out the main civil court fees in England and Wales, with fee numbers: the issue fee for money, non-money (such as repairs), possession, goods, costs-only (CPR 46.14) and Solicitors Act claims; hearing fees by track; applications; appeals; detailed assessment by the size of the bill; default costs certificates; and enforcement. Help with fees is not taken into account.
| Name | Required | Description | Default |
|---|---|---|---|
| dcc | No | Include the fee for a default costs certificate (N254). | |
| claim | No | What the claim is: "money" (A money claim), "other-remedy" (Repairs or another non-money remedy), "goods" (Recovery of goods), "possession" (Possession of land), "costs-only" (Costs-only proceedings (CPR 46.14)), "solicitors-act" (Assessment of a solicitor's bill (Solicitors Act 1974, Part 3)), "none" (Already issued: later fees only). | |
| court | No | County Court (default) or High Court. | |
| track | No | The track, for the hearing fee: "small", "fast", "intermediate", "multi", or "" for no hearing fee yet. | |
| value | No | The amount claimed with interest; for a non-money claim, the damages claimed with it, in pounds, e.g. "12500" or "12,500.50". | |
| appeal | No | Any appeal: to the High Court, or in the County Court (small claims, or other claims). | |
| billVat | No | The VAT in that total, if known, in pounds, e.g. "12500" or "12,500.50". | |
| daAppeal | No | Include the fee for an appeal in detailed assessment proceedings. | |
| legalAid | No | The bill is for legal aid costs only (fee 5.4). | |
| setAside | No | Include the fee for setting aside a default costs certificate. | |
| billTotal | No | The bill's total including VAT, for the assessment fee, in pounds, e.g. "12500" or "12,500.50". | |
| withMoney | No | A non-money claim also claims money (default true). | |
| assessment | No | Include the detailed assessment fee (N258), which depends on the bill. | |
| moneyBasis | No | Whether that money claim is additional to the other remedy or an alternative to it. | |
| enforcement | No | Enforcement methods to include, as true or false: "warrantControl" (Warrant of control), "warrantPossession" (Warrant of possession or delivery), "furtherAttempt" (Further attempt at a new address), "orderInfo" (Order to attend court for questioning), "bailiffService" (Bailiff service of that order), "attachment" (Attachment of earnings order), "charging" (Charging order), "tpdo" (Third party debt order), "judgmentSummons" (Judgment summons), "writ" (High Court writ of control, possession or delivery). | |
| hearingValue | No | For a small claims hearing fee where there is no money claim: the sum claimed, in pounds, e.g. "12500" or "12,500.50". | |
| valueUnlimited | No | The money claim's value is not limited or not stated. | |
| applicationsOnNotice | No | How many applications on notice, e.g. "1". | |
| applicationsByConsent | No | How many applications by consent or without notice, e.g. "1". | |
| fixedCostsDetermination | No | Include the fee for a fixed costs determination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: that it returns fee numbers and that help-with-fees reductions are excluded from the computation, which is a meaningful accuracy limitation for anyone using the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense but front-loaded sentence: purpose first, then the scope enumeration, then the caveat. Every clause names a distinct fee category and thus earns its place, though the list is long enough to border on a data dump.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 20-parameter, zero-required, nested-object tool, the description gives a full orientation to the breadth of fee types covered, and no output schema is needed since results are numeric fees. It could say more about how optional parameters combine and that all inputs are optional, but the schema plus description are largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter (including the nested enforcement object) is documented in the schema itself. The description's fee-category list maps onto the claim enum but adds no syntax, format, or defaulting detail beyond what the schema already states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Works out') and resource (main civil court fees in England and Wales), then enumerates the exact fee categories covered (issue fee, hearing fees by track, applications, appeals, detailed assessment, default costs certificates, enforcement). This clearly distinguishes it from sibling calculators like calculate_interest_on_costs or calculate_part_36_offer, which handle different quantities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The enumeration of covered fee types implicitly tells the agent when this tool applies, and the caveat 'Help with fees is not taken into account' scopes the results. However, there is no explicit when-to-use vs. when-not-to-use guidance and no sibling alternative is named, so selection still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a deadline under the Civil Procedure Rules in England and Wales from a date: clear days (CPR 2.8(2) and (3)), the 5-day rule (CPR 2.8(4)), calendar months (CPR 2.10), court office closures (CPR 2.8(5) and PD 2A) and the latest days to email or post a document for deemed service (CPR 6.26). Name a common time limit as a preset (for example the defence, the acknowledgment of service, the appellant's notice or Points of Dispute), or give your own period, plus the date it runs from.
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | Without a preset: "court" for a filing at court (default), "serve" for a document to be served, "other" for anything else. | |
| unit | No | Without a preset: "days" (default) or "months" (months only for a period after the event). | |
| event | Yes | The date the period runs from: the date of service, of the decision, of the hearing or other event (YYYY-MM-DD). | |
| amount | No | Without a preset: the length of the period, e.g. "14". | |
| preset | No | A common time limit: "claim-form-service", "particulars-to-follow", "acknowledgment", "defence-14" (no acknowledgment filed), "defence-28" (after an acknowledgment), "application-notice", "statement-of-costs-fast-track" (fast track trial), "appellants-notice", "part-36-relevant-period" (21 days), "notice-of-commencement" (N252), "points-of-dispute", "replies" (to Points of Dispute), "request-assessment" (N258), "costs-officer-appeal" (from an authorised court officer). Leave "" to give your own period. | |
| direction | No | Without a preset: "within" a period after the event (default), at least a period "before" it, or at least a period "after" it (gives the earliest day). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context about the rules applied (clear days, the 5-day rule, court office closures) but says nothing about the return shape, rounding conventions or edge cases for a pure calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and rule coverage are front-loaded in the first clause, followed by the usage note on presets. It is dense but every clause corresponds to real functionality; slight bloat from listing CPR citation numbers alongside each concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of indicating what comes back, and it only loosely implies a computed deadline date without describing the result (single date, adjusted date, explanation). For a six-parameter calculator the coverage of inputs is good but the output side is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters including enums and the preset list. The description restates the preset-vs-own-period choice and lists a few example presets, largely duplicating what the schema provides rather than adding new meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (works out a deadline) and a precise resource (a CPR deadline in England and Wales), then enumerates the rules applied (CPR 2.8, 2.10, 6.26, PD 2A). It is very clear what the tool does. However it never distinguishes itself from siblings like calculate_deemed_service, which it partially overlaps by offering 'latest days to email or post a document for deemed service'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains how to drive the tool (use a named preset or supply your own period plus a start date) but not when to choose this over siblings such as calculate_deemed_service or calculate_detailed_assessment_deadlines. Usage is implied by the CPR scope rather than stated with conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out when a claim form and particulars of claim are deemed served in England and Wales, and every date that follows: acknowledgment of service, the defence, agreed extensions and the earliest default judgment, with bank holidays and court closures. Also covers the Damages Claims Portal (PD 51ZB). Give the issue date, how and when the claim form was served, and how the particulars were served.
| Name | Required | Description | Default |
|---|---|---|---|
| aos | No | Whether the defendant acknowledged service: "yes", "no" or "" if not known. | |
| poc | No | Whether the particulars of claim are in the claim form, served with it (default), or to follow. | |
| issue | Yes | The date the claim form was issued (YYYY-MM-DD). | |
| route | No | "part7" for a claim served under Part 6 (default), "dcp" for the Damages Claims Portal. | |
| cfStep | No | The date of the step taken to serve the claim form (posting, sending, delivering) (YYYY-MM-DD). | |
| cfTime | No | The time of that step, where the method is timed (24-hour HH:MM). Leave out if not known. | |
| pocDate | No | Where the particulars followed: the date of the step taken to serve them (YYYY-MM-DD). | |
| pocTime | No | Where the particulars followed: the time of that step (24-hour HH:MM). Leave out if not known. | |
| special | No | Leave "" unless service was outside the jurisdiction, on the Crown, or by an alternative method ordered by the court. | |
| cfMethod | No | How the claim form was served (default first-class-post). | |
| servedBy | No | Who served the claim form (default claimant). | |
| extension | No | Days of extension for the defence agreed under CPR 15.5 (up to 28), e.g. "28". | |
| pocMethod | No | Where the particulars followed: how they were served. | |
| courtDeemed | No | Where the court served the claim form: the deemed service date on its notice (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context: bank holidays and court closures are accounted for, the DCP regime is handled, and the set of computed milestones is enumerated, which tells the agent what the calculation actually produces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences: purpose first, scope extensions second, input guidance last, with zero filler. The middle sentence is a dense list, but every clause (holidays, closures, DCP) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, high-complexity legal calculator with no output schema, the description conveys jurisdiction, routes, inputs, and the kinds of dates returned. It could go one step further on the returned structure, but with 100% schema coverage and clear scope it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters well, including enums and defaults. The description adds only a light natural-language summary of the driving inputs (issue date, service method/time), which is a marginal gain over the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('works out when a claim form and particulars of claim are deemed served in England and Wales') and enumerates the downstream dates produced (acknowledgment of service, defence, extensions, earliest default judgment). This clearly separates it from siblings like calculate_cpr_deadline or calculate_civil_court_fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It scopes jurisdiction (England and Wales), names the two procedural routes (Part 6 vs Damages Claims Portal PD 51ZB), and tells the agent which inputs to supply ('give the issue date, how and when the claim form was served...'). It stops short of naming when to use this tool over a sibling calculator or when it is inapplicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out the CPR Part 47 detailed assessment timetable in England and Wales from the dates you have: the last day to serve the notice of commencement (N252), Points of Dispute, the first day for a default costs certificate (N254), Replies, the request for an assessment hearing (N258), provisional assessment steps and payment. Allows for deemed service, weekends, bank holidays and court office closures. Give at least the right to costs (its kind and date).
| Name | Required | Description | Default |
|---|---|---|---|
| hearingDate | No | The date of the detailed assessment hearing, if one is listed (YYYY-MM-DD). | |
| hearingEnded | No | The date the detailed assessment hearing ended, if it has (YYYY-MM-DD). | |
| noticeServed | No | The date the notice of commencement was served (deemed service), if it has been (YYYY-MM-DD). | |
| pointsServed | No | The date Points of Dispute were served, if they have been (YYYY-MM-DD). | |
| certificateDate | No | The date of the final or interim costs certificate, if issued (YYYY-MM-DD). | |
| rightToCostsDate | Yes | The date of that judgment, order or event (YYYY-MM-DD). | |
| rightToCostsKind | Yes | What gave the right to costs: "judgment" (Judgment or order), "stay-lifted" (Stay lifted after appeal), "discontinuance-served" (Discontinuance served), "discontinuance-upheld" (Discontinuance upheld), "part-36-accepted" (Part 36 offer accepted). | |
| provisionalReceived | No | The date the provisional assessment was received, if there was one (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds real behavioral context: it accounts for deemed service, weekends, bank holidays and court office closures, and it enumerates the outputs computed. That goes meaningfully beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose and jurisdiction before the output enumeration and the input requirement. The deadline list is dense but earns its place by conveying what the tool returns in the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-input calculator with no output schema, the description adequately conveys what is computed (the enumerated deadlines) and what is required, plus jurisdiction and the holiday/closure handling. Minor gaps remain around any failure modes or edge-case behavior, but nothing essential for invoking it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents every date parameter and the rightToCostsKind enum. The description only reinforces the minimum required inputs ('right to costs, its kind and date'), adding marginal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (works out) and a tightly scoped resource (the CPR Part 47 detailed assessment timetable in England and Wales), then enumerates the concrete deadlines produced (N252, Points of Dispute, N254, Replies, N258, provisional assessment, payment). This domain specificity distinguishes it from the generic calculate_cpr_deadline sibling, though it never names a sibling to avoid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use it (when you have assessment dates and need the timetable) and states a minimum input requirement ('Give at least the right to costs'). But it offers no explicit when-not guidance and no routing against the many sibling calculators, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out simple interest at 8% a year on an order for costs in England and Wales: from the date of the order (or acceptance of a Part 36 offer, or the date the court set) to the date you choose, allowing for payments on account, the County Court £5,000 rule and its exceptions, and leap years. It does not decide rates where the court has a discretion.
| Name | Required | Description | Default |
|---|---|---|---|
| costs | Yes | The costs the interest is on: the assessed or agreed sum, in pounds, e.g. "12500" or "12,500.50". | |
| court | Yes | High Court or County Court. | |
| crown | No | County Court: the costs are payable by the Crown, such as the MoD. | |
| endDate | No | The date to calculate interest to (defaults to today) (YYYY-MM-DD). | |
| payments | No | Payments on account, each with a date and an amount. | |
| orderDate | Yes | The date of that order or event (YYYY-MM-DD). | |
| orderKind | Yes | What gave the right to costs: "assessed" (Order for costs to be assessed if not agreed), "stated" (Order for costs of a stated sum (summary assessment)), "p36-in-time" (Part 36 offer accepted within the relevant period, after the claim was issued), "p36-late" (Part 36 offer accepted late, and the court decided costs), "approval" (Settlement approved by the court (child or protected party)), "costs-only" (Order in costs-only proceedings (Part 8)), "other" (Another order or event). | |
| otherSums | No | County Court: any other sums, such as damages, ordered in the same judgment, for the £5,000 test, in pounds, e.g. "12500" or "12,500.50". | |
| startDate | No | Where customStart is true: the date interest runs from (YYYY-MM-DD). | |
| customStart | No | The court ordered interest to run from another date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to spend its words on computation behavior — and it does: payments on account, the County Court £5,000 rule and its exceptions, and leap years. The one gap is that with no output schema it never says what the call returns (interest total, breakdown, daily rate).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then qualification and the exclusion. The opening sentence is long, but every clause (rate, start-point variants, payments, £5,000 rule, leap years) carries distinct information and none is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, enum-heavy calculator with no output schema, this description supplies the legal framing an agent needs to select and feed it correctly, including the key exclusion. It stops short of describing the returned figures or units, which is the only material omission given there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so 3 is the baseline; the description rises above it by explaining how start date is derived (order date, Part 36 acceptance, or court-set date) and by flagging payments on account and the County Court £5,000 test that drive the payments/otherSums/crown fields. It adds interpretive value rather than merely restating the schema's field blurbs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('works out simple interest ... on an order for costs in England and Wales') plus the governing regime and rate (Judgments Act 1838, 8%). An agent can distinguish it from siblings such as calculate_part_36_offer or calculate_detailed_assessment_deadlines 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear jurisdictional and legal context (England and Wales, Judgments Act 8%) and an explicit boundary: 'It does not decide rates where the court has a discretion.' It also enumerates the triggering events (order date, Part 36 acceptance, court-set date) that select this tool's inputs. It does not, however, name sibling calculators or say when to reach for one of those instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Checks a social landlord's Awaab's Law timescales in England (section 10A of the Landlord and Tenant Act 1985 and the Hazards in Social Housing (Prescribed Requirements) (England) Regulations 2025, S.I. 2025/1042, in force from 27 October 2025 for damp and mould and for emergency hazards): the investigation, the written summary, the safety work, alternative accommodation and supplementary preventative work, each with its deadline and whether it was met, counting working days or 24-hour periods. It does not decide whether a hazard is significant or an emergency: that is a question of fact. Give the hazard, the timescale (track) and the date the landlord became aware; add later dates to check each step.
| Name | Required | Description | Default |
|---|---|---|---|
| alt | No | Alternative accommodation: "none" recorded (default), "provided", or "refused" (the tenant refused an offer). | |
| asAt | No | Check as at this date (defaults to today) (YYYY-MM-DD). | |
| aware | Yes | The date the landlord became aware of the issue (a report, complaint, inspection or letter of claim) (YYYY-MM-DD). | |
| track | Yes | "significant" (working days, default) or "emergency" (24 hours). | |
| hazard | Yes | The hazard: "damp" (Damp, mould or fungal growth), "excess-cold" (Excess cold), "excess-heat" (Excess heat), "hygiene" (Domestic hygiene, including food, pests, waste and sanitation), "falls-level" (Falls on the level, including baths and showers), "falls-stairs" (Falls on stairs, steps or ramps), "falls-between" (Falls between levels), "electrical" (Electrical hazards), "fire" (Fire and smoke), "explosion" (Explosions), "collapse" (Structural collapse or falling elements), "other" (Another housing hazard (e.g. water supply, carbon monoxide or gas, intruders)), "crowding" (Crowding and space). | |
| prevBy | No | Which investigation identified the preventative work: "first" (and it could begin at once), "first-wait" (it needed the further investigation first) or "further". | |
| altDate | No | Where provided: the date alternative accommodation was provided from (YYYY-MM-DD). | |
| altTime | No | Where provided: the time (24-hour HH:MM). Leave out if not known. | |
| further | No | The date the further investigation was completed (YYYY-MM-DD). | |
| outcome | No | What the latest investigation found: "none" (no significant or emergency hazard), "significant", "emergency", or "further" (a hazard, but a further investigation was needed). | |
| renewed | No | A renewed investigation (reg 7): the date it was completed (YYYY-MM-DD). | |
| landlord | No | "social" for a council or housing association (default), "private" or "other". Awaab's Law covers social housing. | |
| safetyBy | No | Where outcome is "further": which investigation identified the safety work. | |
| summary1 | No | The date the written summary was given after the first investigation (handed over, posted or emailed) (YYYY-MM-DD). | |
| summary2 | No | The date the written summary was given after the renewed investigation (YYYY-MM-DD). | |
| summary3 | No | The date the written summary was given after the further investigation (YYYY-MM-DD). | |
| awareTime | No | Emergency: the time the landlord became aware (24-hour HH:MM). Leave out if not known. | |
| workBegan | No | The date the preventative work began (YYYY-MM-DD). | |
| knewBefore | No | The landlord knew of the problem before the regulations applied to it (reg 21). | |
| safetyDone | No | The date the safety work was completed (YYYY-MM-DD). | |
| stepsTaken | No | The date steps were taken to arrange the preventative work (e.g. a contractor booked) (YYYY-MM-DD). | |
| adviceGiven | No | The date a safety advice document was given (optional) (YYYY-MM-DD). | |
| furtherTime | No | The time the further investigation was completed (24-hour HH:MM). Leave out if not known. | |
| groundsDate | No | Where groundsLater: when the grounds arose (YYYY-MM-DD). | |
| groundsTime | No | Where groundsLater: the time the grounds arose (24-hour HH:MM). Leave out if not known. | |
| renewedTime | No | The time the renewed investigation was completed (24-hour HH:MM). Leave out if not known. | |
| fireLocation | No | For a fire hazard: "inside" (inside a flat, or anywhere in a house) or "block" (a building with two or more homes: its structure, external walls, common parts or a flat's front door). | |
| firstOutcome | No | Where there was a renewed investigation: what the first one found, "none" or "significant". | |
| groundsLater | No | Emergency: reasonable grounds to believe there was an emergency arose later than awareness. | |
| investigated | No | The date the investigation (or emergency investigation) was completed (YYYY-MM-DD). | |
| preventative | No | Whether supplementary preventative work was identified (reg 13): "yes", "no" or "" if not known. | |
| furtherHazard | No | Where outcome is "further": the hazard found. | |
| workCompleted | No | The date the preventative work was completed (YYYY-MM-DD). | |
| safetyDoneTime | No | Emergency: the time the safety work was completed (24-hour HH:MM). Leave out if not known. | |
| askedInspection | No | The tenant asked for a physical inspection. | |
| firstWasPhysical | No | Whether the first investigation included a physical inspection: "yes", "no" or "" if not known. | |
| investigatedTime | No | Emergency: the time the investigation was completed (24-hour HH:MM). Leave out if not known. | |
| inspectionRequested | No | Where askedInspection: the date of the request (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real context beyond that: it discloses the counting mechanics (working days vs 24-hour periods), the commencement date, and an important limitation that questions of fact are out of scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Core purpose is front-loaded, followed by scope limitation and invocation guidance. The dense statutory parenthetical is long but each clause carries substantive meaning, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 38-parameter tool with no output schema, the description does indicate the return shape ('each with its deadline and whether it was met'), and the schema fully documents every parameter. It stops short of explaining how the many optional parameters interrelate, but the essentials for correct invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every one of the 38 parameters is documented in the schema, so the baseline is 3. The description adds the conceptual role of the three required inputs and the working-day/24-hour distinction, but no syntax or value details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Checks) and resource (Awaab's Law timescales) with statutory grounding and enumerates exactly what is assessed: investigation, written summary, safety work, alternative accommodation and preventative work, each against its deadline. It is unmistakably distinct from the calculation siblings (civil court fees, CPR deadlines, deemed service).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear invocation guidance: 'Give the hazard, the timescale (track) and the date the landlord became aware; add later dates to check each step,' and sets a scope boundary ('It does not decide whether a hazard is significant or an emergency'). It does not name an alternative tool or when-not-to-use, but no sibling overlaps this domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Says which court office deals with a detailed assessment in England and Wales, from the court named on the case: the local County Court hearing centre or district registry, or the Senior Courts Costs Office (SCCO). Handles the London rule in PD 47 para 4.2, where the request for an assessment hearing (N258) goes to the SCCO on CE-File but the default costs certificate (N254) stays at the local hearing centre.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | N252 (notice of commencement), N254 (request for a default costs certificate) or N258 (request for an assessment hearing). Defaults to N258. | |
| court | Yes | The court as it appears on the order, e.g. 'County Court at Wandsworth', 'County Court at Manchester', 'High Court, King's Bench Division, Royal Courts of Justice'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent/non-destructive behavior, so the description correctly focuses on domain behavior instead: the PD 47 para 4.2 'London rule' split routing. It discloses a conditional outcome rule beyond what annotations provide, though it does not describe the shape of the returned answer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core answer ('Says which court office deals with...'), with the conditional London-rule detail second. Dense with legal jargon but each sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only lookup with no output schema, the description covers what the tool returns (the correct court office) and the key conditional rule. Only minor gaps remain, such as not stating a default form or the general output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3, but the description adds real meaning: it ties the 'form' enum to divergent routing outcomes (N258 to SCCO on CE-File, N254 staying local), which the schema alone does not convey. It stops short of explaining N252.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific outcome verb (says which court office deals with a matter) and the exact resource (detailed assessment filing venue in England and Wales), naming the candidate destinations (local hearing centre/district registry vs SCCO). No sibling tool competes for this task, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The domain context (detailed assessment, England and Wales, court named on the case) implies when the tool applies, but there is no explicit when-to-use/when-not statement or named alternative. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the code for a piece of work in an electronic bill of costs (Precedent S, PD 47 Schedule 2) by code or by the work done: phases P1 to P15, tasks T1 to T41, activities A1 to A10, expenses X1 to X15 and the matching J-codes, with each task's Precedent H budget phase.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Limit the search to these kinds of code. | |
| query | Yes | A code (e.g. 'T19', 'JK10', 'A5') or the work done (e.g. 'trial bundle', 'Part 36 offer'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value the annotations cannot: it discloses that results include the matching J-code and each task's Precedent H budget phase, which tells the agent what it actually gets back from a reference lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that is front-loaded with the verb and the resource, with no filler. It is long and comma-heavy, but every clause (scope, code families, return content) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-value burden, and it does so partially by naming the J-code match and the Precedent H budget phase. Coverage is adequate for a small, bounded catalog lookup; only minor details such as result shape or ordering are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by spelling out what the query string can be (a code such as 'T19'/'JK10'/'A5' or work done such as 'trial bundle') and by mapping the five code families to the kinds enum. It meaningfully enriches the parameter beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (finds/looks up) and a specific resource (electronic bill of costs codes under Precedent S, PD 47 Schedule 2), and enumerates exactly which code families are covered (P1-P15, T1-T41, A1-A10, X1-X15, J-codes). This is a registry/lookup tool, clearly distinguishable from the sibling calculators and the search helper, so an agent can route to it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies two usage modes (search by code or by work-done description) but never states when this tool is preferred over siblings or when it is not applicable. No prerequisites, exclusions, or named alternatives are given, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers costs questions from solicitors in England and Wales, on either side of a claim: budgets, Part 36, settlement, detailed assessment, interest and getting paid. Searches about 30 short answers, each citing its CPR rule, practice direction or statute, a glossary of legal costs terms, and a guide to the court forms and costs precedents (N252, N254, N258, N260, Precedents A to U), with the official version of each form and the free tool that fills it in. Use it for 'what is', 'when must', 'who pays', 'how do we' and 'which form' questions about civil costs in England and Wales.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The question or term, in plain words, e.g. 'who pays the costs of detailed assessment' or 'default costs certificate'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description usefully adds the corpus shape (about 30 short answers, each citing a CPR rule/practice direction/statute, plus glossary and forms guide with official versions and filler tools), which tells the agent what kind of result to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, purpose and scope front-loaded before the topic and platform inventory. It is list-heavy but every clause maps to something the agent needs (coverage, sources, question types).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description still explains the result content (cited short answers, glossary, forms/precedent guide) and the intended question types. Nothing critical is missing for a single-parameter lookup tool; only result-count or pagination behavior is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'query' parameter is already documented with two examples, so the schema does the heavy lifting. The description reinforces that the query is plain-words triage of question types but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (answers/searches) and resource (legal costs help: short answers, glossary, court-form guide) with concrete topic coverage (budgets, Part 36, settlement, detailed assessment, interest). It implicitly separates itself from the calculator siblings by being a Q&A/glossary lookup, but never names or contrasts with them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear positive routing with the exact question shapes it serves ('what is', 'when must', 'who pays', 'how do we', 'which form') and scopes usage to civil costs in England and Wales. There is no explicit when-not or named alternative, even though the sibling calculators are the obvious complement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_civil_court_feescalculate_cpr_deadlinecalculate_deemed_servicecalculate_detailed_assessment_deadlinescalculate_interest_on_costscalculate_part_36_offercheck_awaabs_law_timescalesfind_detailed_assessment_courtlook_up_j_codessearch_legal_costs_helpUK case law MCP (21 tools). Free API key: casenode.ai/api/signup → Dashboard → API keys.
Free UK CIS calculators: deductions, deadlines, late penalties, gross payment test, verification.
Over 200 free UK-focused calculators, converters and generators as MCP tools: take-home pay and National Insurance for 2026/27, VAT, stamp duty, mortgages, loans, savings, inflation since 1988, currency with live rates, dates and working days with bank holidays, unit conversions, health calculators, colour and text utilities, encoding, hashing, JWT and TOTP, and validators for IBANs and Bitcoin and Ethereum addresses. Every tool is read-only, stateless and computes on the spot; nothing you send is stored. Each result links to its source page on hopi.co.uk.
Free UK sole-trader tools: VAT & MTD checks, tax set-aside, expense categories, bookkeeper requests.
Add one secure layer between your agents and this server.
