DMD Costs legal costs tools

CPR 21.10 approval checklist (infant and protected party settlements)

check_cpr_21_10_approval

Read-onlyIdempotent

Checks when a settlement, interim payment or payment in by or for a child or protected party needs the court's approval in England and Wales (CPR 21.10; PD 21 was revoked in 2023), the route (a Part 8 claim before issue, or an application in the proceedings), the documents for the approval hearing, the court fee, investment of the money (CPR 21.11, the Court Funds Office forms and the Court of Protection for £100,000 or more) and the rules on deductions from damages (CPR 21.12, 46.4). It never values the claim or works out a costs or deduction figure.

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": {
      "party": "<party>",
      "stage": "<stage>"
    },
    "name": "check_cpr_21_10_approval"
  }
}

Input Schema

Name	Required	Description
`dob`	No	Optional: the child's date of birth.
`band`	No	The sum agreed, as a band (the rules turn on these; no figure is worked out): "up-to-5k" (£5,000 or less), "up-to-25k" (More than £5,000, up to £25,000), "under-100k" (More than £25,000, under £100,000), "100k-plus" (£100,000 or more).
`side`	No	Their side of the claim: "claimant" (Their claim), "defendant" (A claim against them).
`what`	No	What needs approval: "settlement" (A settlement or compromise, including accepting a Part 36 offer), "interim" (A voluntary interim payment), "payment-in" (Accepting money paid into court).
`party`	Yes	Who the settlement is for: "child" (A child (under 18)), "protected" (A protected party (lacks capacity to conduct the proceedings)).
`stage`	Yes	Whether proceedings have been issued: "before" (Before proceedings were issued), "issued" (In proceedings already issued).
`funding`	No	How the claim is funded: "cfa" (A conditional fee agreement (CFA)), "dba" (A damages based agreement (DBA)), "legal-aid" (Legal aid (publicly funded)), "other" (Another way, or not known).
`deductions`	No	Whether costs or expenses will be claimed out of the damages (CPR 21.12).
`dependency`	No	A sum is apportioned to a dependent child (CPR 21.10(7)).
`futureLoss`	No	The claim includes damages for future financial loss (CPR 21.10(4)).
`periodical`	No	The settlement includes periodical payments (CPR 21.10(5)).
`manageMoney`	No	Protected party: lacks capacity to manage the money; child: likely to remain unable to at 18.
`personalInjury`	No	A personal injury claim arising from an accident (CPR 21.10(3)(f)).
`existingAuthority`	No	A deputy or a registered attorney already manages the protected beneficiary's finances (CPR 21.11(9)(b)).
`protocolFixedCosts`	No	Section IV of Part 45 applies (the RTA and EL/PL protocol fixed costs, CPR 21.10(6)).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 1, 2026

changedInput schema / properties / deductions / description

Previous value: -"Whether costs or expenses will be claimed out of the damages (CPR 21.12): \"yes\" (Yes), \"no\" (No), \"unsure\" (Not sure)."New value: +"Whether costs or expenses will be claimed out of the damages (CPR 21.12)."

changedInput schema / properties / dob / description

Previous value: -"Optional: the child's date of birth (YYYY-MM-DD)."New value: +"Optional: the child's date of birth."

changedInput schema / properties / manageMoney / description

Previous value: -"Protected party: lacks capacity to manage the money; child: likely to remain unable to at 18: \"yes\" (Yes), \"no\" (No), \"unsure\" (Not sure)."New value: +"Protected party: lacks capacity to manage the money; child: likely to remain unable to at 18."

AddedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive and closed-world, so safety is covered. The description adds substantive domain behaviour beyond that: the two procedural routes (Part 8 before issue vs application in proceedings), the documents needed, the court fee, CPR 21.11 investment and Court Protection threshold at £100,000, and CPR 21.12/46.4 deduction rules. It stops short of describing the shape of the returned checklist, so 4 rather than 5.

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 core question is front-loaded before the enumeration of sub-topics, and the negative constraint is placed last where it usefully caps scope. It is a single dense sentence, so structure is slightly weaker than a multi-sentence layout would be, but every clause maps to real functionality.

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 15-parameter tool with no output schema, the description adequately conveys what the tool will cover (approval trigger, route, documents, fee, investment, deductions) while the fully documented schema handles parameter meaning. Only the form of the returned checklist is left implicit, a minor gap given the tool's scope.

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 coverage is 100% across 15 parameters, each with its own legal gloss, so the schema carries the burden and the baseline of 3 applies. The description adds only the framing point that the rules turn on the banded sum rather than a computed figure, which is useful but marginal over the field-level docs.

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?

Opens with a specific verb and resource: 'Checks when a settlement, interim payment or payment in by or for a child or protected party needs the court's approval in England and Wales (CPR 21.10)'. The scope (jurisdiction, CPR rule) is precise, and the closing sentence ('never values the claim or works out a costs or deduction figure') cleanly separates it from the many calculate_* siblings that produce figures.

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?

The scope sentence plus the explicit exclusion ('never values the claim or works out a costs or deduction figure') tells an agent when this tool applies and when a computation tool is the better route. It does not name a specific sibling as an alternative, 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.

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.