Skip to main content
Glama
Sign In

DMD Costs legal costs tools

by io.github.Ments123
OverviewDiscussionsAdmin

Fast track and intermediate track timetable calculator (PD 28, CPR Part 28)

calculate_fast_track_timetable
Read-onlyIdempotent

Works out the standard timetable after allocation to the fast track or the intermediate track in England and Wales: the PD 28 para 9.5 typical periods from the notice of allocation (disclosure, witness statements, experts' reports, pre-trial checklists, trial within 30 weeks), the time to apply to set aside or vary the order, agreed directions before a case management conference, the pre-trial checklist (N170), notice of trial, the trial fee (fee 2.1), the trial bundle (CPR 39.5), skeleton arguments, Precedent U or the N260 statement of costs, written questions to experts, and the Damages Claims Portal and noise-induced hearing loss variants. Each date says whether it is a typical period, a rule, the standard order or your own order, and which rest on our reading. The court's own order governs every date.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calculate_fast_track_timetable"
  }
}

Input Schema

NameRequiredDescriptionDefault
dcpNoThe claim is in the Damages Claims Portal (PD 51ZB).
nihlNo"fast": a noise-induced hearing loss claim, with its own standard directions (CPR 28.9).
costsNoWhether costs are fixed, for the statement of costs step (default unsure): "unsure" (Not sure: show both), "fixed" (Fixed recoverable costs (CPR 45 Section VI, VII or VIII)), "notFixed" (Not fixed (for example a housing disrepair claim)).
trackNoThe track (default fast). The multi-track and the small claims track are not covered: "fast" (Fast track), "intermediate" (Intermediate track).
cmcDateNo"intermediate": the date of any case management conference.
ptcDateNoThe date the order gives for filing pre-trial checklists.
trialDateNoThe date the trial is listed for, once the notice of trial is sent.
windowEndNoThe last day of the trial window (leave out for a fixed trial date).
noticeDateNoWhere the order did not fix the trial date or window: the date the court first gave notice of it, for the trial fee.
reportDateNoThe date an expert's report was served, for written questions to the expert.
servedDateNoThe date the order was served, if later than its date.
windowStartNoThe trial date, or the first day of the trial window.
readinessDateNo"fast" in the portal: the date of the court's notice to complete the trial readiness certificate.
allocationDateNoThe date of the notice of allocation, or of the directions order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • changedInput schema / properties / allocationDate / description
      Previous value: -"The date of the notice of allocation, or of the directions order (YYYY-MM-DD)."New value: +"The date of the notice of allocation, or of the directions order."
    • changedInput schema / properties / cmcDate / description
      Previous value: -"\"intermediate\": the date of any case management conference (YYYY-MM-DD)."New value: +"\"intermediate\": the date of any case management conference."
    • changedInput schema / properties / noticeDate / description
      Previous value: -"Where the order did not fix the trial date or window: the date the court first gave notice of it, for the trial fee (YYYY-MM-DD)."New value: +"Where the order did not fix the trial date or window: the date the court first gave notice of it, for the trial fee."
    • changedInput schema / properties / ptcDate / description
      Previous value: -"The date the order gives for filing pre-trial checklists (YYYY-MM-DD)."New value: +"The date the order gives for filing pre-trial checklists."
    • changedInput schema / properties / readinessDate / description
      Previous value: -"\"fast\" in the portal: the date of the court's notice to complete the trial readiness certificate (YYYY-MM-DD)."New value: +"\"fast\" in the portal: the date of the court's notice to complete the trial readiness certificate."
    • changedInput schema / properties / reportDate / description
      Previous value: -"The date an expert's report was served, for written questions to the expert (YYYY-MM-DD)."New value: +"The date an expert's report was served, for written questions to the expert."
    • changedInput schema / properties / servedDate / description
      Previous value: -"The date the order was served, if later than its date (YYYY-MM-DD)."New value: +"The date the order was served, if later than its date."
    • changedInput schema / properties / trialDate / description
      Previous value: -"The date the trial is listed for, once the notice of trial is sent (YYYY-MM-DD)."New value: +"The date the trial is listed for, once the notice of trial is sent."
    • changedInput schema / properties / windowEnd / description
      Previous value: -"The last day of the trial window (leave out for a fixed trial date) (YYYY-MM-DD)."New value: +"The last day of the trial window (leave out for a fixed trial date)."
    • changedInput schema / properties / windowStart / description
      Previous value: -"The trial date, or the first day of the trial window (YYYY-MM-DD)."New value: +"The trial date, or the first day of the trial window."
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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 meaningful behavioral context by explaining that each date is labelled as a typical period, rule, standard order, or the user's own order, and that some dates rest on the tool's reading while the court's own order always governs. This is valuable transparency beyond the annotations.

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 description is front-loaded with the core purpose and then lists the timetable components and variants. It is dense and long, but the length is largely justified by the procedural complexity and the need to signal output provenance. Some compression could improve readability, but it is 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?

Given a complex legal timetable tool with 14 parameters, full schema coverage, rich annotations, and no output schema, the description is largely complete. It explains the scope, the main timetable steps, the variant inputs, and the important caveat that the court's order governs. It does not specify the exact return structure, but it conveys enough for an agent to invoke the tool correctly.

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%, so the schema already documents all 14 parameters thoroughly. The description references key variants such as DCP, NIHL, costs, and track, but does not add syntax, format, or dependency details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The description states a specific verb and resource: it calculates the standard timetable after allocation to the fast track or intermediate track under PD 28 and CPR Part 28. It names the concrete timetable components (disclosure, witness statements, experts' reports, pre-trial checklists, trial, etc.), so an agent can distinguish it from generic deadline calculators.

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 description clearly establishes the procedural context: use it after allocation to the fast or intermediate track, with variants for the Damages Claims Portal and noise-induced hearing loss claims. It does not explicitly name sibling tools or say when not to use this tool, but the track scope is clear from the description and schema.

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 toolsInspect
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