چیستارا — Iranian Legal Corpus

محاسبهٔ دیه — Calculate blood money (دیه)

calculate_diyeh

Read-onlyIdempotent

Calculate دیه for a bodily injury using the CURRENT official rate and the fractions set by قانون مجازات اسلامی. ALWAYS use this instead of computing دیه yourself: the full-دیه rate changes every Persian year and the per-injury fractions are statutory. Returns the amount with the governing article and the official rate source.

Input Schema

TableJSON Schema

Name	Required	Description
`year`	No	Persian year (e.g. 1405). Defaults to the latest loaded rate.
`count`	No	How many (fingers, teeth …). Default 1.
`gender`	No	Gender of the injured/deceased.
`fraction`	No	دیه fraction between 0 and 1 — only when no injury_type fits.
`injury_type`	No	Injury key from the standard list (e.g. full = دیهٔ کامل, hand_one = یک دست, tooth_front = دندان جلویی). Pick the key, not free text.
`sacred_month`	No	Occurred in a ماه حرام (تغلیظ — applies to دیهٔ نفس only).

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 3, 2026

addedInput schema / properties / count

Added value: +{
+  "description": "How many (fingers, teeth …). Default 1.",
+  "type": "integer"
+}

addedInput schema / properties / fraction

Added value: +{
+  "description": "دیه fraction between 0 and 1 — only when no injury_type fits.",
+  "type": "number"
+}

addedInput schema / properties / gender

Added value: +{
+  "description": "Gender of the injured/deceased.",
+  "enum": [
+    "male",
+    "female"
+  ],
+  "type": "string"
+}

removedInput schema / properties / injury

Removed value: -{
-  "description": "Injury in Persian, e.g. «شکستگی دست»، «از دست دادن یک انگشت»، «دندان».",
-  "type": "string"
-}

addedInput schema / properties / injury_type

Added value: +{
+  "description": "Injury key from the standard list (e.g. full = دیهٔ کامل, hand_one = یک دست, tooth_front = دندان جلویی). Pick the key, not free text.",
+  "enum": [
+    "full",
+    "eye_one",
+    "eye_both",
+    "ear_one",
+    "ear_both",
+    "hand_one",
+    "hand_both",
+    "foot_one",
+    "foot_both",
+    "finger_thumb",
+    "finger_other",
+    "finger_phalanx",
+    "tooth_front",
+    "tooth_molar",
+    "nose_full",
+    "nose_fracture",
+    "kidney_one",
+    "kidney_both",
+    "rib_heart",
+    "rib_each",
+    "rib_other",
+    "spleen",
+    "skull_fracture",
+    "spine_fracture",
+    "spine_fracture_healed",
+    "spinal_cord",
+    "eyelid_upper",
+    "eyelid_lower",
+    "testicle_left",
+    "testicle_right"
+  ],
+  "type": "string"
+}

removedInput schema / properties / is_haram_month

Removed value: -{
-  "description": "Whether it occurred in a حرام month (تغلیظ applies to دیهٔ نفس).",
-  "type": "boolean"
-}

addedInput schema / properties / sacred_month

Added value: +{
+  "description": "Occurred in a ماه حرام (تغلیظ — applies to دیهٔ نفس only).",
+  "type": "boolean"
+}

changedInput schema / properties / year / description

Previous value: -"Persian year (e.g. 1405). Defaults to the current year."New value: +"Persian year (e.g. 1405). Defaults to the latest loaded rate."

changedInput schema / required

Previous value: -[
-  "injury"
-]New value: +[]

First observedAug 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent; the description adds that it uses the current official rate, that the rate changes every Persian year, that fractions are statutory, and that the result cites the governing article and rate source. This directly addresses how the tool behaves and why manual calculation is unreliable, without contradicting any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: the purpose and method are first, the usage mandate and rationale second, and the output details last. Every sentence contributes either to selecting the tool or understanding its result.

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 calculation tool with no required parameters, a richly documented schema, and safety annotations, the description covers the key agent-facing concerns: why this tool must be used, what rate applies, and what the result contains. It does not specify edge-case behavior or error handling, but no output schema exists and the description provides the essential usage context.

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 documents every parameter, including the enum meanings and the 'fraction only when no injury_type fits' rule. The tool description adds no parameter-level information beyond what the schema already conveys, so the baseline of 3 is appropriate.

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 names the exact operation ('Calculate دیه for a bodily injury'), the source of truth ('CURRENT official rate' and 'قانون مجازات اسلامی'), and the output ('Returns the amount with the governing article and the official rate source'). It is immediately distinguishable from sibling calculators because it is the only one for statutory blood money.

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?

It gives a strong when-to-use directive: 'ALWAYS use this instead of computing دیه yourself,' supported by the reason that the full-دیه rate changes annually and fractions are statutory. It does not explicitly name sibling alternatives or state exclusion conditions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All چیستارا — Iranian Legal Corpus 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.

Resources

Need Help?