DMD Costs legal costs tools

CPR deadline calculator (CPR 2.8 clear days and time limits)

calculate_cpr_deadline

Read-onlyIdempotent

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.

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": {
      "event": "<event>"
    },
    "name": "calculate_cpr_deadline"
  }
}

Input Schema

Name	Required	Description
`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.
`amount`	No	Without a preset: the length of the period, e.g. "14".
`preset`	No	A common time limit (the enum lists them all). Where the id is not self-explanatory: defence-14 = no acknowledgment filed; defence-28 = after an acknowledgment; reply-to-defence = earliest date the court can set; defence-28-extended = CPR 15.5; agreed-extension = CPR 3.8(4); costs-budget = Precedent H; budget-discussion-report = Precedent R; statement-of-costs-fast-track = fast track trial; part-36-relevant-period = 21 days; notice-of-commencement = N252; 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).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / event / description

Previous value: -"The date the period runs from: the date of service, of the decision, of the hearing or other event (YYYY-MM-DD)."New value: +"The date the period runs from: the date of service, of the decision, of the hearing or other event."

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / preset / description

Previous value: -"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."New value: +"A common time limit (the enum lists them all). Where the id is not self-explanatory: defence-14 = no acknowledgment filed; defence-28 = after an acknowledgment; reply-to-defence = earliest date the court can set; defence-28-extended = CPR 15.5; agreed-extension = CPR 3.8(4); costs-budget = Precedent H; budget-discussion-report = Precedent R; statement-of-costs-fast-track = fast track trial; part-36-relevant-period = 21 days; notice-of-commencement = N252; replies = to Points of Dispute; request-assessment = N258; costs-officer-appeal = from an authorised court officer. Leave \"\" to give your own period."

changedInput schema / properties / preset / enum

Previous value: -[
-  "",
-  "claim-form-service",
-  "particulars-to-follow",
-  "acknowledgment",
-  "defence-14",
-  "defence-28",
-  "application-notice",
-  "statement-of-costs-fast-track",
-  "appellants-notice",
-  "part-36-relevant-period",
-  "notice-of-commencement",
-  "points-of-dispute",
-  "replies",
-  "request-assessment",
-  "costs-officer-appeal"
-]New value: +[
+  "",
+  "claim-form-service",
+  "particulars-to-follow",
+  "acknowledgment",
+  "defence-14",
+  "defence-28",
+  "reply-to-defence",
+  "defence-28-extended",
+  "agreed-extension",
+  "costs-budget",
+  "budget-discussion-report",
+  "application-notice",
+  "statement-of-costs-fast-track",
+  "summary-judgment-notice",
+  "summary-judgment-evidence",
+  "summary-judgment-reply",
+  "part-35-questions",
+  "witness-summons",
+  "appellants-notice",
+  "part-36-relevant-period",
+  "notice-of-commencement",
+  "points-of-dispute",
+  "replies",
+  "request-assessment",
+  "costs-officer-appeal"
+]

First observedOct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish a safe, read-only, idempotent, closed-world operation, so the bar is lower; the description still adds real context by naming the exact rule set applied and the categories of calculation supported. Its one omission is what the tool actually returns (a single date, a date plus reasoning?), which matters for a no-output-schema calculator.

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?

It is front-loaded with the computation scope and then the two ways to invoke it (preset or custom period plus start date); every clause earns its place by naming a distinct rule or input mode. It is dense and long-sentenced, but not 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?

With 6 parameters, full schema coverage, complete annotations and no output schema, the description covers the conceptual model and the preset/custom split well. The remaining gap is that it never states the shape of the result, which for a deadline calculator is the one thing an agent still has to guess.

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% and the enum descriptions are unusually thorough (e.g. mapping preset ids to their CPR basis), so the schema does the heavy lifting. The description contributes only the high-level preset-vs-manual-period pattern, which is the baseline-3 level when the schema is complete.

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 gives a precise verb and resource ('works out a deadline under the Civil Procedure Rules in England and Wales') and enumerates the specific rules it implements (CPR 2.8(2)-(5), 2.10, PD 2A, 6.26), so an agent knows exactly what computation is offered. It does not, however, explicitly differentiate itself from close siblings such as calculate_deemed_service or calculate_limitation_period, even though it touches deemed service concepts.

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?

Guidance is framed around how to drive the parameters ('Name a common time limit as a preset ... or give your own period'), not when to choose this tool over a sibling that also computes service or limitation dates. Usage is implied by the CPR rule list rather than stated with exclusions or alternatives.

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.