Skip to main content
Glama
Sign In

DMD Costs legal costs tools

by io.github.Ments123
OverviewDiscussionsAdmin

Pre-action protocol deadline calculator

calculate_pre_action_protocol_deadlines
Read-onlyIdempotent

Works out the dates the main pre-action protocols in England and Wales set after a letter of claim, counted the way each protocol words them, with the paragraph for each: housing conditions (20 working days from receipt, deemed 2 days after the letter's date; inspection; expert's report), clinical disputes (14 days from receipt; Letter of Response 4 months from the letter of claim, and from receipt), personal injury (21 calendar days from posting; 3 months from the acknowledgment), disease and illness including hearing loss (21 days from posting; 90 days from the acknowledgment), professional negligence, construction and engineering, debt claims, and the Practice Direction where no protocol applies. Flags dates that fall on a weekend or bank holiday (protocol periods do not roll forward).

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": {
      "protocol": "<protocol>"
    },
    "name": "calculate_pre_action_protocol_deadlines"
  }
}

Input Schema

NameRequiredDescriptionDefault
ackDateNoPersonal injury, disease and professional negligence: the date of the defendant's acknowledgment.
foreignNoPersonal injury and disease: the accident or negligence was abroad, or the defendant is outside England and Wales.
protocolYesThe protocol: "housing" (Housing conditions (disrepair), England or Wales), "clinical" (Clinical disputes (clinical negligence)), "pi" (Personal injury), "disease" (Disease and illness (including hearing loss)), "profneg" (Professional negligence), "construction" (Construction and engineering), "debt" (Debt claims (business against an individual)), "none" (No specific protocol (the Practice Direction)).
sentDateNoPersonal injury and disease: the date the letter of claim was posted or sent.
replyDateNoDebt: the date the completed Reply Form was received.
letterDateNoHousing, clinical and debt: the date of the letter of claim.
recordsDateNoClinical and disease: the date the records were requested.
receivedDateNoClinical, professional negligence, construction and no protocol: the date the letter of claim was received.
responseDateNoHousing: the date of the landlord's response, for the inspection.
inspectionDateNoHousing: the date of the inspection, for the expert's report.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / ackDate / description
      Previous value: -"Personal injury, disease and professional negligence: the date of the defendant's acknowledgment (YYYY-MM-DD)."New value: +"Personal injury, disease and professional negligence: the date of the defendant's acknowledgment."
    • changedInput schema / properties / inspectionDate / description
      Previous value: -"Housing: the date of the inspection, for the expert's report (YYYY-MM-DD)."New value: +"Housing: the date of the inspection, for the expert's report."
    • changedInput schema / properties / letterDate / description
      Previous value: -"Housing, clinical and debt: the date of the letter of claim (YYYY-MM-DD)."New value: +"Housing, clinical and debt: the date of the letter of claim."
    • changedInput schema / properties / receivedDate / description
      Previous value: -"Clinical, professional negligence, construction and no protocol: the date the letter of claim was received (YYYY-MM-DD)."New value: +"Clinical, professional negligence, construction and no protocol: the date the letter of claim was received."
    • changedInput schema / properties / recordsDate / description
      Previous value: -"Clinical and disease: the date the records were requested (YYYY-MM-DD)."New value: +"Clinical and disease: the date the records were requested."
    • changedInput schema / properties / replyDate / description
      Previous value: -"Debt: the date the completed Reply Form was received (YYYY-MM-DD)."New value: +"Debt: the date the completed Reply Form was received."
    • changedInput schema / properties / responseDate / description
      Previous value: -"Housing: the date of the landlord's response, for the inspection (YYYY-MM-DD)."New value: +"Housing: the date of the landlord's response, for the inspection."
    • changedInput schema / properties / sentDate / description
      Previous value: -"Personal injury and disease: the date the letter of claim was posted or sent (YYYY-MM-DD)."New value: +"Personal injury and disease: the date the letter of claim was posted or sent."
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent, closed-world read, so the bar is lower. The description adds genuinely non-obvious domain behaviour: periods are counted the way each protocol words them (working days vs calendar days), the 2-day deemed receipt rule, and that dates landing on a weekend or bank holiday are flagged rather than rolled forward. It stops short of describing the shape of the returned dates/paragraphs, which is the remaining gap.

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 scope (England and Wales, post letter of claim) is front-loaded ahead of the protocol enumeration, and the weekend/bank-holiday flagging caveat is placed at the end where it belongs. It is a single dense sentence that borders on a list, but nearly every clause carries operative information an agent needs to select the right inputs.

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 10-parameter calculator with no output schema, the description supplies the domain logic behind the parameters and indicates that each deadline comes with its governing paragraph. What is missing is conditional-parameter guidance — which inputs are required per protocol value — which matters given only 'protocol' is marked required. Otherwise an agent has enough to invoke it 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% and each property already names the protocols it applies to, so the schema does the heavy lifting. The description contextualises the triggers (letter of claim, acknowledgment, posting, reply form) but adds little parameter-level detail beyond what the schema states, and does not clarify conditional requirements such as which fields become mandatory for which protocol value. Baseline 3 is appropriate.

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?

States a specific verb (works out) and resource (pre-action protocol deadlines after a letter of claim) in England and Wales, and enumerates the eight protocols covered plus the Practice Direction fallback. An agent can tell this is the pre-action protocol calculator rather than a general CPR deadline tool. It does not, however, name distinguishing siblings such as calculate_cpr_deadline, calculate_pi_portal_timescales or calculate_deemed_service, so the boundary is inferred rather than stated.

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?

The description implies the use case — deadlines arising after a letter of claim under the main pre-action protocols — and the protocol enum makes selection concrete. But it never says when to prefer this over the sibling deadline calculators, nor what to do when a protocol falls outside the enumerated list beyond the 'none' Practice Direction option. Usage is implied, not guided.

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