Skip to main content
Glama

DMD Costs legal costs tools

Limitation period calculator (Limitation Act 1980)

calculate_limitation_period
Read-onlyIdempotent

Works out the last day to bring a civil claim in England and Wales under the Limitation Act 1980, strictly: personal injury, clinical negligence and industrial disease (s.11, with children and capacity under s.28, death under s.11(5) and s.12, child sexual abuse under s.11ZA, armed forces), housing disrepair (a continuing breach: the 6-year look-back from the issue date), contract, tort and latent damage with the 15-year longstop, deeds, the Defective Premises Act, contribution, defamation, defective products and judgments. It never infers a date of knowledge: give it. Where the law is unsettled it gives the earlier (safe) date first, never moves a last day off a weekend or bank holiday, and treats s.33 as a discretion, never a date.

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": {
      "kind": "<kind>"
    },
    "name": "calculate_limitation_period"
  }
}

Input Schema

NameRequiredDescriptionDefault
dobNo"pi": the date of birth, if the injured person may have been under 18 when the claim accrued.
diedNo"pi": the injured person has died.
kindYesThe kind of claim: "pi" (Personal injury, clinical negligence or industrial disease (including NIHL)), "housing" (Housing disrepair: the tenancy covenants), "contract" (Breach of contract), "tort" (Negligence or another tort, not personal injury), "deed" (A deed (specialty)), "dpa" (Defective Premises Act 1972, s.1 (building work)), "contribution" (Contribution between wrongdoers), "defamation" (Defamation or malicious falsehood), "cpa" (Defective product (Consumer Protection Act 1987)), "judgment" (An action on a judgment (s.24)).
abuseNo"pi": personal injury caused by sexual abuse while under 18 (s.11ZA).
deathNoWhere died: the date of death.
issueNo"housing": the date the claim will be issued (defaults to today).
latentNo"tort": latent damage under s.14A (give knowledge as the s.14A starting date, and longstopFrom).
accrualNoThe date the cause of action accrued: the injury, breach, damage, publication, completion of the dwelling, judgment or award. With deadline true, the deadline date itself. Not used for "housing".
pre1987No"pi": armed forces service or exposure before 15 May 1987 (Crown immunity, a liability bar, not a date).
deadlineNo"contract" or "deed": the breach was a failure to do something, or to pay, by a deadline; accrual is then the deadline date itself.
overseasNo"pi": injury on an overseas armed forces operation (s.33(1ZA)).
housingPiNo"housing": the claim includes damages for personal injury.
knowledgeNo"pi" and "cpa": the date of knowledge (s.14), if later than accrual, as you rely on it (never inferred). "tort" with latent true: the s.14A starting date.
prKnowledgeNoWhere died: the personal representative's date of knowledge, if later (s.11(5)).
abuseSettledNoWhere abuse: the claim was settled, or decided by a court, before 29 June 2026.
longstopFromNo"tort": the date of the last negligent act or omission (15-year longstop, s.14B). "cpa": the date the producer supplied the product (10-year longstop).
capacityRegainedNo"pi": the date capacity was regained, if it has been.
dependantKnowledgeNoWhere died: a dependant's date of knowledge, if later (s.12(2)).
incapableAtAccrualNo"pi": whether the injured person lacked capacity to conduct proceedings on the date of the injury, including because of it: "yes", "no" or "" if not known.
abuseSuedBeforeDeathNoWhere abuse and died: the victim brought the action before dying.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • changedInput schema / properties / accrual / description
      Previous value: -"The date the cause of action accrued: the injury, breach, damage, publication, completion of the dwelling, judgment or award. With deadline true, the deadline date itself. Not used for \"housing\" (YYYY-MM-DD)."New value: +"The date the cause of action accrued: the injury, breach, damage, publication, completion of the dwelling, judgment or award. With deadline true, the deadline date itself. Not used for \"housing\"."
    • changedInput schema / properties / capacityRegained / description
      Previous value: -"\"pi\": the date capacity was regained, if it has been (YYYY-MM-DD)."New value: +"\"pi\": the date capacity was regained, if it has been."
    • changedInput schema / properties / death / description
      Previous value: -"Where died: the date of death (YYYY-MM-DD)."New value: +"Where died: the date of death."
    • changedInput schema / properties / dependantKnowledge / description
      Previous value: -"Where died: a dependant's date of knowledge, if later (s.12(2)) (YYYY-MM-DD)."New value: +"Where died: a dependant's date of knowledge, if later (s.12(2))."
    • changedInput schema / properties / dob / description
      Previous value: -"\"pi\": the date of birth, if the injured person may have been under 18 when the claim accrued (YYYY-MM-DD)."New value: +"\"pi\": the date of birth, if the injured person may have been under 18 when the claim accrued."
    • changedInput schema / properties / issue / description
      Previous value: -"\"housing\": the date the claim will be issued (defaults to today) (YYYY-MM-DD)."New value: +"\"housing\": the date the claim will be issued (defaults to today)."
    • changedInput schema / properties / knowledge / description
      Previous value: -"\"pi\" and \"cpa\": the date of knowledge (s.14), if later than accrual, as you rely on it (never inferred). \"tort\" with latent true: the s.14A starting date (YYYY-MM-DD)."New value: +"\"pi\" and \"cpa\": the date of knowledge (s.14), if later than accrual, as you rely on it (never inferred). \"tort\" with latent true: the s.14A starting date."
    • changedInput schema / properties / longstopFrom / description
      Previous value: -"\"tort\": the date of the last negligent act or omission (15-year longstop, s.14B). \"cpa\": the date the producer supplied the product (10-year longstop) (YYYY-MM-DD)."New value: +"\"tort\": the date of the last negligent act or omission (15-year longstop, s.14B). \"cpa\": the date the producer supplied the product (10-year longstop)."
    • changedInput schema / properties / prKnowledge / description
      Previous value: -"Where died: the personal representative's date of knowledge, if later (s.11(5)) (YYYY-MM-DD)."New value: +"Where died: the personal representative's date of knowledge, if later (s.11(5))."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, which already mark this as a read-only, idempotent, non-destructive calculation, the description discloses important behavioral rules: it never infers date of knowledge, gives the earlier safe date where the law is unsettled, never moves a last day off a weekend or bank holiday, and treats s.33 as a discretion. These are material traits an agent would not get from the annotations or schema.

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 supplies relevant legal scope and caveats. The long enumerated claim-type sentence is dense, but it serves to clarify coverage; there is little wasted language, though it could be more sharply structured.

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 complex 20-parameter legal calculator with no output schema, the description covers scope, key legal assumptions, and several edge-case behaviors. It does not describe the shape of the returned result, which is a minor gap given the absence of an output schema, but the legal and behavioral context is otherwise strong.

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 detailed parameter meanings are already documented in the schema. The description reinforces a few points, notably that date of knowledge must be supplied, but it does not add substantial parameter-level guidance beyond what is already in the structured fields.

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 works out the last day to bring a civil claim in England and Wales under the Limitation Act 1980. It enumerates the claim types covered (personal injury, housing disrepair, contract, tort, defamation, etc.), making it clearly distinguishable from siblings that calculate procedural deadlines or costs.

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 identifies the domain and several preconditions, such as 'It never infers a date of knowledge: give it' and caveats about s.33 being a discretion rather than a date. It does not explicitly name alternative tools, but the context is strong enough for an agent to know when this limitation-period calculator is appropriate.

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