Skip to main content
Glama

DMD Costs legal costs tools

Solicitors Act assessment checker (Solicitors Act 1974, s.70)

check_solicitors_act_assessment
Read-onlyIdempotent

Works out whether a solicitor's bill can still be assessed under section 70 of the Solicitors Act 1974 (England and Wales), for the client, the firm, a third party who paid it (s.71(1)) or a beneficiary of an estate or trust that paid, or is entitled to pay, it (s.71(3)), from the dates of delivery, payment, judgment and the application: assessment as of right within one month of delivery (s.70(1)), the court's discretion up to 12 months (s.70(2)), special circumstances after 12 months, after judgment or after payment (s.70(3)), and no power more than 12 months after payment (s.70(4)). An emailed bill counts as delivered on the first working day after it was sent (s.69(2F)). Fees taken from money held for the client count as payment only where the client agreed the amount (Oakwood Solicitors Ltd v Menzies [2024] UKSC 34); a part payment is not payment of the bill (Rippon Patel and French LLP v Mowlam [2020] EWHC 1079 (QB)), and an unclear deduction, or a deadline that ended on a day the court office was closed with the claim issued on the next open day (Pritam Kaur), gives both answers. Optionally the one-fifth rule for the costs of the assessment (s.70(9) and (12); Karatysz v SGI Legal LLP [2022] EWCA Civ 1388) and the CPR 46.10 timetable from the order. It never says whether special circumstances exist and never estimates what an assessment would allow.

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": {
      "applicant": "<applicant>"
    },
    "name": "check_solicitors_act_assessment"
  }
}

Input Schema

NameRequiredDescriptionDefault
paidNoWhether the bill has been paid: "no" (not paid), "yes" (paid in full), "part" (part paid).
scopeNoFor the one-fifth rule: what is being assessed: "all" (The whole bill), "profit" (Profit costs only (s.70(5))), "other" (Costs other than profit costs).
paidOnNoThe date of payment; for fees taken from money held for the client, the date the client agreed the amount, if later.
applyOnNoThe date the claim for assessment would be issued (defaults to today).
orderOnNoFor the CPR 46.10 timetable: the date of the order for assessment.
paidHowNoHow the bill was paid: "direct" (paid by the client, or for them), "deduction" (taken from money the firm held for the client).
deliveryNoHow the bill was delivered: "email" (By email or another electronic means), "post" (By post), "hand" (By hand).
grossSumNoThe bill is a gross sum bill for contentious business (s.64).
judgmentNoWhether the firm has obtained judgment for the costs in the bill.
applicantYesWho would apply for the assessment (a firm checking whether its client can still challenge a bill: client): "client" (The client who was billed), "solicitor" (The solicitor who sent the bill), "third-party" (Someone else who paid, or must pay, the bill), "beneficiary" (A beneficiary of an estate or trust that paid, or is entitled to pay, the bill).
compliantNoWhether the bill is a statute bill: signed (or sent with a signed letter), delivered by hand, post or, where the client agreed, electronically, and final for the work it covers.
deliveredNoBy hand or post: the day the bill arrived. By email ("email"): the day it was sent; s.69(2F) moves delivery to the next working day.
billAmountNoFor the one-fifth rule: the amount of the bill, or of the part being assessed (the total it demands, paid or not), in pounds (e.g. "12500.50").
agreedAmountNoWhere "deduction": whether the client agreed the amount taken for this bill.
pointsServedNoThe date the points of dispute were served.
assessedAmountNoFor the one-fifth rule: the amount allowed on assessment, or a figure to test, in pounds (e.g. "12500.50").
breakdownServedNoThe date the breakdown of costs was served.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • changedInput schema / properties / agreedAmount / description
      Previous value: -"Where \"deduction\": whether the client agreed the amount taken for this bill: \"yes\", \"no\" or \"unsure\"."New value: +"Where \"deduction\": whether the client agreed the amount taken for this bill."
    • changedInput schema / properties / applyOn / description
      Previous value: -"The date the claim for assessment would be issued (defaults to today) (YYYY-MM-DD)."New value: +"The date the claim for assessment would be issued (defaults to today)."
    • changedInput schema / properties / assessedAmount / description
      Previous value: -"For the one-fifth rule: the amount allowed on assessment, or a figure to test, in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"For the one-fifth rule: the amount allowed on assessment, or a figure to test, in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / billAmount / description
      Previous value: -"For the one-fifth rule: the amount of the bill, or of the part being assessed (the total it demands, paid or not), in pounds, e.g. \"12500\" or \"12,500.50\"."New value: +"For the one-fifth rule: the amount of the bill, or of the part being assessed (the total it demands, paid or not), in pounds (e.g. \"12500.50\")."
    • changedInput schema / properties / breakdownServed / description
      Previous value: -"The date the breakdown of costs was served (YYYY-MM-DD)."New value: +"The date the breakdown of costs was served."
    • changedInput schema / properties / compliant / description
      Previous value: -"Whether the bill is a statute bill: signed (or sent with a signed letter), delivered by hand, post or, where the client agreed, electronically, and final for the work it covers: \"yes\", \"no\" or \"unsure\"."New value: +"Whether the bill is a statute bill: signed (or sent with a signed letter), delivered by hand, post or, where the client agreed, electronically, and final for the work it covers."
    • changedInput schema / properties / delivered / description
      Previous value: -"By hand or post: the day the bill arrived. By email (\"email\"): the day it was sent; s.69(2F) moves delivery to the next working day (YYYY-MM-DD)."New value: +"By hand or post: the day the bill arrived. By email (\"email\"): the day it was sent; s.69(2F) moves delivery to the next working day."
    • changedInput schema / properties / judgment / description
      Previous value: -"Whether the firm has obtained judgment for the costs in the bill: \"yes\" or \"no\"."New value: +"Whether the firm has obtained judgment for the costs in the bill."
    • changedInput schema / properties / orderOn / description
      Previous value: -"For the CPR 46.10 timetable: the date of the order for assessment (YYYY-MM-DD)."New value: +"For the CPR 46.10 timetable: the date of the order for assessment."
    • changedInput schema / properties / paidOn / description
      Previous value: -"The date of payment; for fees taken from money held for the client, the date the client agreed the amount, if later (YYYY-MM-DD)."New value: +"The date of payment; for fees taken from money held for the client, the date the client agreed the amount, if later."
    • changedInput schema / properties / pointsServed / description
      Previous value: -"The date the points of dispute were served (YYYY-MM-DD)."New value: +"The date the points of dispute were served."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds real behavioural disclosure beyond them: it will not decide whether special circumstances exist and will not estimate what an assessment would allow. It also warns that unclear facts (an unclear deduction, or a deadline ending on a court-closure day) produce both answers, which materially changes how an agent should read the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the opening clause, but it is delivered as a single very long sentence dense with statutory subsections and case citations, followed by more citation-heavy sentences. Every element is legally relevant, yet the density and lack of paragraphing make it harder to scan than it needs to be for an agent deciding whether to call it.

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 17-parameter, no-output-schema legal calculator, the description covers the decision rules (s.70(1)-(4) windows, judgment and payment bars), the optional one-fifth and CPR 46.10 outputs, and the limits of its conclusions. What it does not describe is the shape of the answer (e.g. a yes/no with reasons versus a date window), which matters more here because 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.

Parameters4/5

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 adds legal meaning the schema cannot: email delivery moves to the first working day (s.69(2F)), deduction payments only count where the client agreed the amount (Oakwood v Menzies), and part payment is not payment of the bill (Rippon Patel). These interpret enums like paid, paidHow and agreedAmount rather than merely restating them.

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 ('works out whether a solicitor's bill can still be assessed under s.70 Solicitors Act 1974') and scopes it to England and Wales with the four applicant classes. An agent can distinguish it from neighbours like calculate_detailed_assessment_deadlines or look_up_cpr_costs_rule without opening any schema.

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 clear usage context: it enumerates who can apply (client, firm, third party under s.71(1), beneficiary under s.71(3)) and the facts it needs (delivery, payment, judgment, application dates), and notes optional add-ons (one-fifth rule, CPR 46.10 timetable). It never explicitly says when to prefer a sibling tool or when this one does not apply, so it stops short of a 5.

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