Skip to main content
Glama

چیستارا — Iranian Legal Corpus

محاسبهٔ دستمزد کارشناسی رسمی — Calculate court expert fee

calculate_expert_fee
Read-onlyIdempotent

Calculate the official تعرفهٔ دستمزد کارشناسان رسمی دادگستری as replaced by the 1405 instrument (approved 1405/05/07, promulgated 1405/05/20; supersedes the 1398/12/25 tariff and its 1402 amendment). valuation is a marginal ladder on the ارزش موضوع کارشناسی (art. 11) with a hard per-expert cap (1,350,000,000 rial) and explicit percentage add-ons for a few named subject matters (art. 11 notes 3–4, art. 22(2)); residual is expert work with no specific tariff in this instrument (art. 9) — a RANGE of 20,000,000–100,000,000 rial set on the expert's proposal with the referring authority's agreement, and the tool returns only the floor and says so; evidence is the flat minimum for تأمین دلیل (art. 7, 20,000,000 rial). Dozens of OTHER specialties (arts. 13–55) carry their own separate tariff and are not modelled here. Never guess a court expert's statutory fee.

Input Schema

NameRequiredDescriptionDefault
kindYesvaluation = art. 11 ladder (needs value_rial); residual = flat minimum, no specific tariff (art. 9); evidence = تأمین دلیل flat minimum (art. 7).
modifiersNovaluation only; usually at most one: contract_dispute = employer/contractor/consulting-engineer dispute or صورت‌وضعیت review over the whole contract value (+100%, art. 11 note 3); contract_dispute_partial = appraisal of only part of the contract, e.g. finding breach or delay (+50%, note 3); intangible_assets = valuation of intangible assets such as brands (+50%, art. 11 note 4 in the 1405 tariff); underground_mine = underground mineral reserves (+35%, art. 22(2)).
value_rialNoValue of the subject matter under appraisal, in RIAL — valuation only. Never pass Toman.
expert_countNoNumber of same-specialty experts working the SAME subject jointly (valuation only). More than 1 applies a 30% reduction per expert, with the cap checked after the reduction (art. 56). Default 1 (no reduction). Do not use for a multi-specialty panel — price each specialty separately.
travel_days_same_provinceNoMission days within the expert's own province (art. 6 daily travel allowance) — added to any kind.
travel_days_other_provinceNoMission days outside the expert's own province (art. 6).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / expert_count / description
      Previous value: -"Number of same-specialty experts working the SAME subject jointly (valuation only). More than 1 applies a 30% reduction per expert (art. 11 note 6). Default 1 (no reduction). Do not use for a multi-specialty panel — price each specialty separately."New value: +"Number of same-specialty experts working the SAME subject jointly (valuation only). More than 1 applies a 30% reduction per expert, with the cap checked after the reduction (art. 56). Default 1 (no reduction). Do not use for a multi-specialty panel — price each specialty separately."
    • changedInput schema / properties / modifiers / description
      Previous value: -"valuation only; usually at most one: contract_dispute = employer/contractor/consulting-engineer dispute or صورت‌وضعیت review over the whole contract value (+100%, art. 11 note 3); contract_dispute_partial = appraisal of only part of the contract, e.g. finding breach or delay (+50%, note 3); damage_assessment = determining cause and extent of damage (+50%, note 4); used_goods = used parts/goods/food-drug-hygiene items/scrap/tools/micro-electronics, standalone (+50%, note 5); intangible_assets = brand and other intangibles (+50%, note 7); underground_mine = underground mineral reserves (+35%, art. 22(2))."New value: +"valuation only; usually at most one: contract_dispute = employer/contractor/consulting-engineer dispute or صورت‌وضعیت review over the whole contract value (+100%, art. 11 note 3); contract_dispute_partial = appraisal of only part of the contract, e.g. finding breach or delay (+50%, note 3); intangible_assets = valuation of intangible assets such as brands (+50%, art. 11 note 4 in the 1405 tariff); underground_mine = underground mineral reserves (+35%, art. 22(2))."
    • changedInput schema / properties / modifiers / items / enum
      Previous value: -[
      -  "contract_dispute",
      -  "contract_dispute_partial",
      -  "damage_assessment",
      -  "used_goods",
      -  "intangible_assets",
      -  "underground_mine"
      -]New value: +[
      +  "contract_dispute",
      +  "contract_dispute_partial",
      +  "intangible_assets",
      +  "underground_mine"
      +]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds rich behavioral context: the marginal ladder for valuation, a hard 1,350,000,000 rial cap, percentage add-ons for named subject matters, and the crucial caveat that 'residual' returns only the floor of a 20,000,000–100,000,000 rial range. It also discloses the legal articles driving the behavior, which goes well beyond structured fields.

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 a single dense paragraph but is front-loaded with the core purpose and then systematically covers each kind, exclusions, and caveats. Every sentence carries legal or operational information; it could be easier to scan with structure, but it is not padded.

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, annotation-rich calculator with no output schema, the description is nearly complete: it explains the three modes, caps, add-ons, exclusions, and the limited return of 'residual'. It does not explicitly state the return format for 'valuation' and 'evidence', though a numeric fee is strongly implied, leaving a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3, but the description adds meaning beyond the schema by explaining that 'valuation' is a marginal ladder on the subject value with a per-expert cap, and by tying modifiers to specific articles and percentage effects. The schema already documents each parameter fully, so this is incremental but real added value.

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 precise verb ('Calculate') and resource ('official تعرفهٔ دستمزد کارشناسان رسمی دادگستری'), and pins the legal instrument (1405 tariff superseding prior ones). It clearly distinguishes the three supported kinds (valuation, residual, evidence) from each other and from the dozens of unmodeled specialties, so an agent can immediately tell what the tool does and does not cover.

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 strong context for when each 'kind' applies, and explicitly bounds scope by warning that other specialties (arts. 13–55) are not modelled. It even says 'Never guess a court expert's statutory fee,' which is useful. However, it does not name or route to sibling tools like calculate_lawyer_fee, leaving the choice of this calculator versus other fee calculators implicit.

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