Skip to main content
Glama

چیستارا — Iranian Legal Corpus

by ai.hoghogh
OverviewDiscussionsAdmin

محاسبهٔ حق‌الوکاله — Calculate lawyer fee (bar tariff)

calculate_lawyer_fee
Read-onlyIdempotent

Calculate حق‌الوکاله from آیین‌نامهٔ تعرفهٔ حق‌الوکاله (1398/12/28): financial claims are a marginal ladder on the claim value (art. 9); family, non-financial, criminal and administrative matters are a min–max RANGE independent of value (arts. 13, 14, 20). stage is art. 21's share of the whole-case fee (60% first instance / 40% appeal). The tariff does not scale by winning or losing. Never guess a lawyer's statutory fee.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stageYesfirst = 60%, appeal = 40%, cassation = on the appeal tariff (arts. 16–17).
outcomeNoHow the case ends (default judgment). Settlement is paid in full (art. 23); art. 12 halves or quarters a fee for قرار رد / ابطال.
case_typeNocivil = financial claim (art. 9); family = family/حسبی (art. 13a); non_financial (art. 13b); criminal (art. 14, needs criminal_grade); admin = دیوان عدالت اداری / تعزیرات (art. 20); board = non-judicial boards e.g. labour (art. 20).
criminal_gradeNoCriminal only: court (کیفری یک / دو) and offence grade.
case_value_tomanNoClaim value in Toman — civil only.
final_at_first_instanceNoCivil only: first-instance judgment is final as to value ⇒ flat 10% (art. 9 opening).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • changedInput schema / properties / case_type / description
      Previous value: -"Case type."New value: +"civil = financial claim (art. 9); family = family/حسبی (art. 13a); non_financial (art. 13b); criminal (art. 14, needs criminal_grade); admin = دیوان عدالت اداری / تعزیرات (art. 20); board = non-judicial boards e.g. labour (art. 20)."
    • changedInput schema / properties / case_type / enum
      Previous value: -[
-  "civil",
-  "criminal",
-  "admin"
-]New value: +[
+  "civil",
+  "family",
+  "non_financial",
+  "criminal",
+  "admin",
+  "board"
+]
    • changedInput schema / properties / case_value_toman / description
      Previous value: -"Case value in Toman."New value: +"Claim value in Toman — civil only."
    • addedInput schema / properties / criminal_grade
      Added value: +{
+  "description": "Criminal only: court (کیفری یک / دو) and offence grade.",
+  "enum": [
+    "k1_grade1",
+    "k1_grade2_3",
+    "k1_other",
+    "k2_hodud_diyat_grade4_5",
+    "k2_grade6",
+    "k2_other"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / final_at_first_instance
      Added value: +{
+  "description": "Civil only: first-instance judgment is final as to value ⇒ flat 10% (art. 9 opening).",
+  "type": "boolean"
+}
    • changedInput schema / properties / outcome / description
      Previous value: -"Case outcome (or projection)."New value: +"How the case ends (default judgment). Settlement is paid in full (art. 23); art. 12 halves or quarters a fee for قرار رد / ابطال."
    • changedInput schema / properties / outcome / enum
      Previous value: -[
-  "full_win",
-  "partial_win",
-  "settlement",
-  "lose"
-]New value: +[
+  "judgment",
+  "settlement",
+  "dismissed_no_merits",
+  "rejected_after_defence",
+  "voided_before_defence"
+]
    • changedInput schema / properties / stage / description
      Previous value: -"Court stage."New value: +"first = 60%, appeal = 40%, cassation = on the appeal tariff (arts. 16–17)."
    • changedInput schema / required
      Previous value: -[
-  "stage",
-  "outcome"
-]New value: +[
+  "stage"
+]
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive behavior, so the bar for description-added context is lower. The description usefully adds domain behavior: the tariff does not scale by outcome, `stage` is a share of the whole-case fee (60/40), and range-based vs ladder-based calculation differs by case type. It could go further on return format, though a calculator tool's output is largely self-evident.

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?

Three dense, front-loaded sentences. Sentence one gives the governing regulation and the two fee structures; sentence two covers the stage share; sentence three is the usage warning. No filler.

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 read-only calculator with 100% schema coverage and no output schema, the description is close to complete: it names the governing statute, the two calculation regimes, and the stage-share rule. What is thin is the outcome/arts. 12–23 behavior and the cassation edge case, but those are covered by schema descriptions.

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 every parameter already has an enum + description. The description reinforces the meaning of `stage` (art. 21 share) and the ladder/range split, but does not add syntax or format details beyond what the schema provides. Baseline 3 is correct here.

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 the specific action (calculate حق‌الوکاله) against a named regulation (آیین‌نامهٔ 1398/12/28) and describes the fee structures it handles (marginal ladder vs. min-max range). This is enough for an agent to distinguish it from calculators like calculate_diyeh or calculate_litigation_fee, though it never explicitly names siblings.

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 explains the internal logic of when financial claims use a marginal ladder vs. when family/criminal/admin matters use a range, and warns not to guess a statutory fee. But it does not tell the agent when to pick this tool over calculate_litigation_fee or lookup_law_article — the sibling routing is left implicit.

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