Skip to main content
Glama

DMD Costs legal costs tools

PI portal timescales (RTA, EL/PL and RTA small claims protocols)

calculate_pi_portal_timescales
Read-onlyIdempotent

Works out the timescales in the Pre-Action Protocol for Low Value Personal Injury Claims in Road Traffic Accidents, the EL/PL protocol and the RTA Small Claims (OIC) protocol, in business days: the CNF response (15 or 30 business days RTA, 30 employers' liability, 40 public liability; RTA small claims 30 or 40), interim payments, the Stage 2 consideration and negotiation periods and their extensions, settlement and non-settlement payments, the Court Proceedings Pack, the exit points and Stage 3 under PD 49F. Dates beyond the bank-holiday data are never given as firm. It never advises on liability, value or settlement.

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_pi_portal_timescales"
  }
}

Input Schema

NameRequiredDescriptionDefault
mibNoRTA and RTA small claims: no insurer identified, so the MIB deals with the claim.
cnfSentNoThe day the CNF was sent (RTA small claims: the day the claim was accepted on the Portal).
cppSentNoOptional: the day the Court Proceedings Pack was sent (RTA small claims: the Court Pack list).
settledNoOptional: the day a settlement was agreed.
accidentNoOptional: the date of the accident, to check which protocol applies.
packSentNoOptional: the day the Stage 2 Settlement Pack was sent (RTA small claims: the medical report and the para 8.5 items).
protocolYesThe protocol: "rta" (RTA protocol: road traffic accident, above the small claims limit, up to £25,000), "elpl" (EL/PL protocol: employers’ liability (including disease) or public liability, up to £25,000), "oic" (RTA small claims protocol (Official Injury Claim): injury up to £5,000, overall up to £10,000).
claimTypeNo"elpl": the kind of claim: "el" (Employers’ liability (accident or disease)), "pl" (Public liability).
offerMadeNoOptional: the day of the last offer.
interimKindNoOptional, RTA and EL/PL: the interim payment requested: "1000" (£1,000), "more" (More than £1,000).
interimSentNoOptional: the day the Interim Settlement Pack was sent (RTA small claims: the interim payment request).
stage3ServedNoOptional, RTA and EL/PL: the day the step to serve the Stage 3 claim form was taken.
initialExtensionNoOptional, RTA and EL/PL: business days agreed to add to the initial consideration period (a whole number).
negotiationExtensionNoOptional, RTA and EL/PL: business days agreed to add to the negotiation period (a whole number).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / accident / description
      Previous value: -"Optional: the date of the accident, to check which protocol applies (YYYY-MM-DD)."New value: +"Optional: the date of the accident, to check which protocol applies."
    • changedInput schema / properties / cnfSent / description
      Previous value: -"The day the CNF was sent (RTA small claims: the day the claim was accepted on the Portal) (YYYY-MM-DD)."New value: +"The day the CNF was sent (RTA small claims: the day the claim was accepted on the Portal)."
    • changedInput schema / properties / cppSent / description
      Previous value: -"Optional: the day the Court Proceedings Pack was sent (RTA small claims: the Court Pack list) (YYYY-MM-DD)."New value: +"Optional: the day the Court Proceedings Pack was sent (RTA small claims: the Court Pack list)."
    • changedInput schema / properties / interimSent / description
      Previous value: -"Optional: the day the Interim Settlement Pack was sent (RTA small claims: the interim payment request) (YYYY-MM-DD)."New value: +"Optional: the day the Interim Settlement Pack was sent (RTA small claims: the interim payment request)."
    • changedInput schema / properties / offerMade / description
      Previous value: -"Optional: the day of the last offer (YYYY-MM-DD)."New value: +"Optional: the day of the last offer."
    • changedInput schema / properties / packSent / description
      Previous value: -"Optional: the day the Stage 2 Settlement Pack was sent (RTA small claims: the medical report and the para 8.5 items) (YYYY-MM-DD)."New value: +"Optional: the day the Stage 2 Settlement Pack was sent (RTA small claims: the medical report and the para 8.5 items)."
    • changedInput schema / properties / settled / description
      Previous value: -"Optional: the day a settlement was agreed (YYYY-MM-DD)."New value: +"Optional: the day a settlement was agreed."
    • changedInput schema / properties / stage3Served / description
      Previous value: -"Optional, RTA and EL/PL: the day the step to serve the Stage 3 claim form was taken (YYYY-MM-DD)."New value: +"Optional, RTA and EL/PL: the day the step to serve the Stage 3 claim form was taken."
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the business-day basis, the caveat that dates beyond bank-holiday data are never stated as firm, and the explicit scope limit that it does not advise on liability, value or settlement. These are genuine behavioral disclosures beyond the annotations, though no indication of output shape is given.

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?

Front-loaded with the verb and resource, followed by the enumerated computations and two scope caveats; every clause is relevant. The single semicolon-heavy sentence packing all milestones is dense, but trimming would lose useful specificity about what is calculated.

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 14-parameter, no-output-schema tool in a technical legal domain, the description does the essential work: it names the protocols, the unit (business days), the milestones returned, the bank-holiday reliability caveat, and the advisory limits. The main remaining gap is that the shape of the returned deadlines (per-stage dates vs. summary) is left implicit even though no output schema exists.

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% (all 14 parameters documented, three with enums), so the schema already carries the parameter burden. The description adds the CNF response windows (15/30/30/40 business days) and the existence of consideration/negotiation extensions, which marginally clarifies the protocol, claimType and extension parameters, but it does not explain the interplay among the many optional date fields.

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 a precise resource (timescales under the RTA, EL/PL and OIC pre-action protocols), and enumerates the exact milestones computed (CNF response, interim payments, Stage 2 periods, CPP, Stage 3). It is clear what the tool produces, though it never names a sibling or states how it differs from calculate_pre_action_protocol_deadlines or calculate_cpr_deadline.

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 domain context is clear enough to imply when the tool applies (PI portal claims under these three protocols), and the schema notes 'accident' can be used to check which protocol applies. However, it gives no explicit when-to-use/when-not guidance and points to no alternative tool for non-PI pre-action deadlines, leaving routing to inference.

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