95,000+ articles of Iranian law, a legal glossary and 8 Iranian legal calculators. Free.
Scored across 14 tools
Each tool has a clearly distinct legal purpose. The calculate_* tools are separated by subject (deadline, court fee, diya, inheritance, late payment, lawyer fee, mehrieh, stamp duty) and their descriptions explicitly cross-reference each other to prevent misselection. The research tools cleanly separate finding a law by title, searching by subject, listing articles, reading a known article, and explaining a term.
All tools follow a consistent snake_case verb_noun pattern: calculate_*, get_*, list_*, find_*, search_*, and explain_*. There is no mixing of conventions or vague naming.
14 tools is well-scoped for a legal research and calculation server. Each tool earns its place by covering a distinct legal computation or lookup operation, with no redundant or filler tools.
The surface covers the main workflows: searching laws, retrieving articles, explaining terms, fetching reference rates, and calculating common legal amounts. Minor gaps remain, such as no support for court rulings (explicitly out of scope) and diya calculations limited to a listed set of injuries, but agents can work around these.
Compute the last day to appeal (تجدیدنظرخواهی), seek cassation (فرجامخواهی) or object to a default judgment (واخواهی) in an Iranian civil or criminal case, from the Jalali date the judgment was served, skipping Fridays and official holidays. Use it when the question is until when an objection can be filed; for the articles that set the periods use search_iranian_law. A third-party objection has no fixed deadline and the result explains why. Returns the deadline date, the period applied and its legal basis. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| matter | No | Civil or criminal case; civil when not given. Values: civil = حقوقی; criminal = کیفری. | |
| remedy | Yes | The objection to file. Values: appeal = تجدیدنظرخواهی; cassation = فرجامخواهی; objection = واخواهی از رأی غیابی; third_party = اعتراض ثالث. | |
| judgment | No | For appeal or cassation: whether the judgment was given in presence or by default; a default judgment's period runs from the end of the objection period. Values: presence = حضوری; absence = غیابی. | |
| residence | No | Where the objecting party lives; abroad lengthens the period. Inside Iran when not given. Values: inside = مقیم ایران; abroad = مقیم خارج از کشور. | |
| served_day | No | Day of the month it was served. | |
| served_year | No | Jalali year the judgment was served, e.g. 1405. | |
| served_month | No | Jalali month it was served, 1 for فروردین. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered; the description adds genuinely new behavior — that third-party objections have no fixed deadline and the result explains why, plus that holiday and Friday skipping is applied. It stops short of describing pagination or failure modes, but for a pure calculator that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the purpose and the routing rule come first, edge cases and the return note last. One stray sentence ('Amounts in rial') is irrelevant to a tool with no monetary parameters and appears to be template carry-over.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter calculator with an output schema, the description supplies everything the schema cannot: calendar conventions, holiday skipping, the alternative tool, and the no-deadline third-party case. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with enums fully glossed in both English and Persian, so the schema carries the parameter semantics. The description adds the holiday-skipping rule and Jalali framing, but those are behavioral rather than per-parameter detail; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compute) plus the exact resource (the last day to appeal, seek cassation or object to a default judgment) scoped to Iranian civil/criminal cases from the Jalali service date, skipping Fridays and holidays. An agent can separate this from siblings like calculate_court_fee or search_iranian_law without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('when the question is until when an objection can be filed') and names the alternative for the adjacent need ('for the articles that set the periods use search_iranian_law'). It also pre-empts a foreseeable edge case: third-party objection has no fixed deadline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the court fee (هزینهٔ دادرسی) to file a claim or an appeal in Iran: tiered by the claim's value for a financial claim, a fixed amount for a non-financial claim or a request such as تأمین خواسته, from the Budget Act and the Judiciary's circular. Use it when the question is what filing will cost; for a lawyer's fee use calculate_lawyer_fee, and for the power-of-attorney stamp calculate_stamp_duty. Returns the fee in rial with its breakdown and source; a fixed fee whose figure is not yet verified says so. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Stage, for a financial claim; first when not given. Values: first = مرحله بدوی; appeal = واخواهی و تجدیدنظرخواهی; supreme = فرجامخواهی، اعاده دادرسی و اعتراض ثالث. | |
| claim_kind | Yes | Financial claim or non-financial claim/request. Values: financial = دعوای مالی; non-financial = دعوای غیرمالی و درخواستها. | |
| amount_rial | No | For a financial claim: the claim's value at first instance, the judgment sum at later stages, in rial. | |
| fixed_fee_rial | No | A fixed fee in rial to use instead of the table's (family matters pay less); normally left out. | |
| non_financial_kind | No | For a non-financial claim or request: which one. Values: non-financial-first = دعاوی غیرمالی — مرحله بدوی; non-financial-objection = دعاوی غیرمالی — واخواهی; non-financial-appeal = دعاوی غیرمالی — تجدیدنظر; non-financial-retrial = دعاوی غیرمالی — اعاده دادرسی و اعتراض ثالث; family-first = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — مرحله بدوی; family-objection = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — واخواهی; family-appeal = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — تجدیدنظر; family-retrial = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — اعاده دادرسی و اعتراض ثالث; family-interim = تأمین خواسته یا دستور موقت در امور خانواده — مرحله بدوی; marriage-first = طلاق، نکاح، فسخ نکاح و نسب — مرحله بدوی; marriage-objection = طلاق، نکاح، فسخ نکاح و نسب — واخواهی; marriage-appeal = طلاق، نکاح، فسخ نکاح و نسب — تجدیدنظر; marriage-cassation = طلاق، نکاح، فسخ نکاح و نسب — فرجامخواهی; marriage-retrial = طلاق، نکاح، فسخ نکاح و نسب — اعاده دادرسی و اعتراض ثالث; hasbi-first = امور حسبی — مرحله بدوی; hasbi-objection = امور حسبی — واخواهی; hasbi-appeal = امور حسبی — تجدیدنظر; hasbi-cassation = امور حسبی — فرجامخواهی; hasbi-retrial = امور حسبی — اعاده دادرسی و اعتراض ثالث; civil-status-first = دعاوی اسناد سجلی — مرحله بدوی; civil-status-objection = دعاوی اسناد سجلی — واخواهی; civil-status-appeal = دعاوی اسناد سجلی — تجدیدنظر; civil-status-retrial = دعاوی اسناد سجلی — اعاده دادرسی و اعتراض ثالث; non-judicial-first = اعتراض به رأی مراجع غیرقضایی — مرحله بدوی; non-judicial-objection = اعتراض به رأی مراجع غیرقضایی — واخواهی; non-judicial-appeal = اعتراض به رأی مراجع غیرقضایی — تجدیدنظر; non-judicial-retrial = اعتراض به رأی مراجع غیرقضایی — اعاده دادرسی و اعتراض ثالث; evidence-preservation = درخواست تأمین دلیل; claim-security = درخواست تأمین خواسته; interim-order = درخواست دستور موقت; request-appeal = تأمین خواسته یا دستور موقت — تجدیدنظر; unvalued-claim = خواستهٔ مالی که هنگام تقدیم تقویم نشده (علیالحساب); provisional-enforcement = درخواست اجرای موقت حکم; order-appeal = اعتراض یا تجدیدنظر از قرار (دادگاه و دیوان عالی کشور); enforcement-third-party = اعتراض شخص ثالث به اجرای احکام مدنی. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, yet the description still adds real behavioral context: output is a fee in rial with a breakdown and source, and an unverified fixed-fee figure self-reports as unverified. Unit conventions (rial, Jalali dates) are also stated. The only gap is that it does not discuss the underlying legal source's coverage limits beyond the one data-quality caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then routing, then output/unit conventions. Every clause carries information an agent would otherwise have to guess; no filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return fields, and it correctly stops at noting the rial/breakdown/source shape plus the unverified-figure caveat. Purpose, routing, units, calendar, and data-quality caveat are all covered for a 5-parameter, enum-heavy calculator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents all five parameters with detailed enum glosses, including '(family matters pay less)' for fixed_fee_rial. The description's 'tiered by the claim's value' vs 'a fixed amount' framing adds a small conceptual layer but no parameter detail the schema lacks, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Compute the court fee (هزینهٔ دادرسی) to file a claim or an appeal in Iran') and immediately scopes the calculation logic: tiered for financial claims, fixed for non-financial claims or requests like تأمین خواسته. It also names the sibling tools it is not (calculate_lawyer_fee, calculate_stamp_duty), so the agent can differentiate without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Use it when the question is what filing will cost; for a lawyer's fee use calculate_lawyer_fee, and for the power-of-attorney stamp calculate_stamp_duty.' Both the trigger condition and the two nearest alternatives are named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the diya (دیه, blood money) owed for a death or a bodily injury under the Islamic Penal Code: the injury's legal fraction applied to the year's full diya from the Judiciary's annual circular, with the sacred-month and Haram increase and the woman's share where they apply. Use it when the question is how much diya an injury or death carries; for the full-diya figure of a year alone use get_reference_rates, and for the articles that set a fraction use search_iranian_law. Covers the 22 injuries listed under injury; for others the articles give the fraction. Returns the amount in rial and toman, its breakdown, the circular used and the legal basis. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Jalali year of the diya circular — the year of payment, which sets the amount; the current year when not given. | |
| count | No | How many injuries of this kind (e.g. three fingers); 1 when not given. | |
| injury | Yes | The death or injury. Values: life = قتل نفس — قتل نفس — دیه کامل; eye-one = اعضا و منافع — از بین بردن یک چشم; eye-both = اعضا و منافع — از بین بردن هر دو چشم; ear-one = اعضا و منافع — از بین بردن یک گوش; nose = اعضا و منافع — از بین بردن کل بینی; tongue = اعضا و منافع — از بین بردن زبان (گویا); lip-one = اعضا و منافع — از بین بردن یک لب; hand-one = اعضا و منافع — قطع یک دست; foot-one = اعضا و منافع — قطع یک پا; finger = اعضا و منافع — قطع یک انگشت دست یا پا; phalanx = اعضا و منافع — قطع یک بند از انگشت غیرشست; thumb-phalanx = اعضا و منافع — قطع یک بند از انگشت شست; harseh = جراحات سر و صورت — حارصه — خراش پوست بدون خونآمدن; damiyeh = جراحات سر و صورت — دامیه — بریدگی همراه با خونآمدن; motalahemeh = جراحات سر و صورت — متلاحمه — بریدگی عمیق گوشت; semhaq = جراحات سر و صورت — سمحاق — رسیدن جراحت به پرده استخوان; muzeheh = جراحات سر و صورت — موضحه — نمایان شدن استخوان; hashemeh = جراحات سر و صورت — هاشمه — شکستگی استخوان; monaqqeleh = جراحات سر و صورت — منقله — جابهجایی استخوان; maamumeh = جراحات سر و صورت — مأمومه — رسیدن جراحت به کیسه مغز; damegheh = جراحات سر و صورت — دامغه — پاره شدن کیسه مغز; jaefeh = جراحات بدن — جائفه — نفوذ جراحت به داخل بدن. | |
| inside_haram | No | The act took place inside the Haram of Mecca. | |
| sacred_month | No | The act took place in a sacred month (رجب، ذیالقعده، ذیالحجه، محرم); adds one third to a death's diya. | |
| victim_gender | No | The victim's sex; male when not given. Values: male = مرد; female = زن. | |
| full_diya_rial | No | A full-diya figure in rial to use instead of the table's, e.g. from a newer circular; normally left out. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: which legal modifiers are applied (sacred-month one-third increase, Haram increase, woman's share), what is returned (rial and toman amounts, breakdown, circular used, legal basis), and the unit/calendar conventions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and computation rule, then routes to alternatives, then states coverage limits and output conventions. The opening sentence is dense and long, but every clause carries information and nothing is repeated from the structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, yet the description still names the unit (rial) and calendar (Jalali) and warns that unsupported injuries fall back to the articles. For a 7-parameter calculator with enum-heavy inputs, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented including enum values in Persian, so the baseline is 3. The description reinforces that the year's circular drives the amount and that the sacred-month/Haram/gender rules modify it, but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compute) and resource (diya for death or bodily injury) plus the legal framework it applies, and explicitly contrasts itself with two siblings (get_reference_rates for the full-diya figure, search_iranian_law for the fraction-setting articles). An agent can distinguish it from every other calculate_* sibling without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('when the question is how much diya an injury or death carries') and two named alternatives with the conditions that select them. It also discloses the coverage boundary: the 22 injuries enumerated under `injury`, with the articles handling the rest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Divide a deceased person's net estate among the heirs under the Civil Code's classes and fixed shares (فروض), with return (رد) and shortfall (ورود نقص; no عول, as in Shia law) and a bequest of up to one third, flagging the rule on a wife's share of land. Use it when the question is who inherits how much; for the articles behind a share use search_iranian_law or get_law_article (قانون مدنی, مواد ۸۶۱ تا ۹۴۹). Give only the living heirs: a later class inherits only when every earlier class is empty, and a spouse inherits with every class. Returns each heir's fraction and amount in rial with the articles applied. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| sons | No | Living sons. | |
| wives | No | Number of surviving wives when spouse is wife. | |
| father | No | The father is alive. | |
| mother | No | The mother is alive. | |
| spouse | No | The surviving spouse, if any; none when not given. Values: none = ندارد; husband = زوج (شوهر); wife = زوجه (همسر). | |
| daughters | No | Living daughters. | |
| bequest_rial | No | A bequest (وصیت) in rial; capped at one third. | |
| full_sisters | No | Sisters of the same father and mother (class 2). | |
| full_brothers | No | Brothers of the same father and mother (class 2). | |
| maternal_aunts | No | Mother's sisters, خاله (class 3). | |
| mother_blocked | No | The mother's share is reduced by siblings (حاجب, Civil Code 892): two brothers, four sisters, or a brother and two sisters, with the father alive. | |
| paternal_aunts | No | Father's sisters, عمه (class 3). | |
| maternal_uncles | No | Mother's brothers, دایی (class 3). | |
| net_estate_rial | Yes | Net estate in rial, after debts, funeral costs and financial obligations. | |
| paternal_uncles | No | Father's brothers, عمو (class 3). | |
| paternal_sisters | No | Sisters by the father only (class 2). | |
| maternal_siblings | No | Brothers and sisters by the mother only (class 2). | |
| paternal_brothers | No | Brothers by the father only (class 2). | |
| maternal_grandfather | No | Mother's father is alive (class 2). | |
| maternal_grandmother | No | Mother's mother is alive (class 2). | |
| paternal_grandfather | No | Father's father is alive (class 2). | |
| paternal_grandmother | No | Father's mother is alive (class 2). |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent/non-destructive already covered by annotations, the description adds substantive domain behavior: رد and ورود نقص treatment, no عول under Shia law, the one-third bequest cap, a flagged special rule for a wife's share of land, and the return format (fraction + amount in rial with applied articles).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and organized into purpose, routing, and input rules; every sentence carries information. It is dense with parenthetical Persian legal terms and stacks several caveats, which slightly slows scanning but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 22-parameter legal calculator with an output schema, the description supplies the routing, the input-population rules, the jurisdictional caveats, and the unit/calendar conventions (rial, Jalali) an agent needs. Return values are already covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns above that by adding a genuinely non-obvious input rule that the schema does not encode ('a later class inherits only when every earlier class is empty', spouse inherits alongside every class). It still does not clarify the spouse/wives interaction or mother_blocked semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (divide a deceased person's net estate among heirs) and qualifies it with the legal framework (Civil Code classes, fixed shares فروض, رد/ورود نقص, no عول, one-third bequest cap). It is unmistakably distinct from monetary siblings such as calculate_diya, calculate_mehrieh, and calculate_court_fee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('when the question is who inherits how much') and where to go otherwise ('for the articles behind a share use search_iranian_law or get_law_article'). It also gives the calling rule for heirs: only living heirs, earlier classes block later ones, spouse inherits with every class.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute late-payment damages (خسارت تأخیر تأدیه, article 522 of the Civil Procedure Code) on a debt in rial between the month it fell due and the month it is paid, from the Central Bank's monthly price index. Use it for a money debt, a cheque or a judgment sum; a mehrieh is valued with calculate_mehrieh instead. A month whose index is not published yet uses the latest published one, and the result says so. Returns the damages, their breakdown and the index figures used with their dates. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| due_year | Yes | Jalali year the debt fell due or was demanded. | |
| due_month | Yes | Jalali month, 1 for فروردین. | |
| payment_year | No | Jalali year of payment; this year when they do not say. | |
| payment_month | No | Jalali month of payment, 1 for فروردین. | |
| principal_rial | Yes | اصل دین, in ریال. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds substantive behavior: index publications lag, unpublished months fall back to the latest published index, and the result explicitly flags that fallback. It also declares the return payload (damages, breakdown, index figures with dates) even though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then legal citation, exclusions, and edge-case behavior, all in three tight sentences with no filler. Slightly dense with parenthetical references but each clause carries rule-bearing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what remains after the schema and output schema: whether it applies to this debt type, which sibling handles the excluded case, the index-lag fallback, and the unit/calendar conventions. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds units and calendar conventions (rial, Jalali) and the fallback for payment_month, but does not go beyond the schema on principal or due-date semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compute) and resource (late-payment damages, خسارت تأخیر تأدیه) and anchors it to the legal basis (article 522 of the Civil Procedure Code). Explicitly distinguishes itself from sibling calculate_mehrieh by use case (mehrieh is valued with that tool instead).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names when to use it (money debt, cheque, judgment sum) and when not to (mehrieh routes to calculate_mehrieh). This is explicit criteria plus an exclusion with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the lawyer's fee (حقالوکاله) for a financial claim under the Bar tariff: the tiered amount on the claim's value and each stage's share, for the number of lawyers — the figure a court awards against the losing side. Use it when the question is the tariff fee or whether an agreed fee is above it; for the stamp on the power of attorney use calculate_stamp_duty, and for court fees calculate_court_fee. Returns the fee in rial per stage with its breakdown and the tariff's articles. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Stage of the case; first when not given. Values: first = مرحله نخستین (بدوی); appeal = تجدیدنظر; supreme = فرجام (دیوان عالی کشور); enforcement = اجرای احکام. | |
| lawyers | No | Number of lawyers; 1 when not given. | |
| amount_rial | Yes | The claim's value, or the judgment sum at enforcement, in rial. | |
| final_judgment | No | At first instance: the judgment cannot be appealed because the claim is small (Civil Procedure Code 331). | |
| agreed_fee_rial | No | The fee agreed in the contract, in rial, to compare with the tariff. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the payout frame ('the figure a court awards against the losing side'), the return shape ('fee in rial per stage with its breakdown and the tariff's articles'), and the unit/calendar conventions (rial, Jalali).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded with purpose first, then usage routing, then output/units, so an agent gets the essentials immediately. The middle sentence is long and clause-heavy, but each clause (stages, lawyer count, award direction) carries distinct information, so there is little true waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are supplied structurally, yet the description still summarizes them ('fee in rial per stage with its breakdown and the tariff's articles'). Combined with the routing guidance, unit conventions, and required-parameter clarity, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds purpose-level meaning the schema does not: agreed_fee_rial exists to test whether a contracted fee exceeds the tariff, and the stage parameter drives a per-stage share calculation. It does not, however, document defaults or enum semantics beyond what the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Compute the lawyer's fee (حقالوکاله) for a financial claim under the Bar tariff') and immediately scopes it (tiered amount on claim value, per-stage share, multiplied by number of lawyers). It is unmistakably distinct from the sibling calculators such as calculate_stamp_duty and calculate_court_fee.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use condition ('Use it when the question is the tariff fee or whether an agreed fee is above it') and names two alternatives with the condition that selects each ('for the stamp on the power of attorney use calculate_stamp_duty, and for court fees calculate_court_fee'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Value a mehrieh (مهریه) at today's prices: a sum in rial indexed by the Central Bank's annual price index from the year of the marriage to the year of the claim (note to article 1082 of the Civil Code), or a number of gold coins at their latest recorded price. Use it when the question is what a mehrieh is worth now; for damages on an ordinary debt use calculate_late_payment, and for the coin price alone get_reference_rates. Returns the figure, its breakdown, the index or price used with its date, and the legal basis. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | «وجه رایج» — a sum of money — or «سکه». Coins are not indexed; they are valued at the day's price. | |
| coin_type | No | sekee is سکهٔ تمام امامی and is what courts usually take; sekeb is سکهٔ تمام بهار آزادی. | |
| claim_year | No | Jalali year of the claim; this year when they do not say. Where the mehrieh is paid out of a deceased husband's estate, the year of the death instead. | |
| coin_count | No | How many full coins the عقدنامه names. | |
| marriage_year | No | Jalali year the marriage was contracted. | |
| already_paid_rial | No | What has already been paid, in ریال. | |
| contract_amount_rial | No | The sum written in the عقدنامه, in ریال. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description goes further by disclosing the valuation method (Central Bank annual index from marriage year to claim year, article 1082 note; coins at latest recorded price), the unit conventions, and the return contents including legal basis. It stops short of stating edge cases (e.g., what happens if index data for a year is missing), which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and tightly packed: valuation method, routing to alternatives, return contents, and unit conventions in four sentences with no filler. It is dense and long, but every sentence carries distinct information, so it stays just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter calculation tool with an output schema, the description covers the calculation basis, the alternatives, the return shape, and the unit/calendar conventions. Nothing an agent needs to invoke it correctly is missing, and return values are additionally explained despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter conventions the schema does not state globally: amounts are in rial and dates are Jalali, and that coins are not indexed but valued at the day's price. That clarifies which parameters apply per 'kind', adding genuine value above the per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Value a mehrieh at today's prices') and immediately distinguishes itself from siblings by naming calculate_late_payment and get_reference_rates. An agent can route between these three tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('when the question is what a mehrieh is worth now') plus two named alternatives with the conditions that select them ('for damages on an ordinary debt', 'for the coin price alone'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the tax stamp on a lawyer's power of attorney (وکالتنامه, article 103 of the Direct Taxes Act) and the fund and Bar shares paid with it, for one stage of one case, civil or criminal. Use it when the question is what the stamp costs; for the lawyer's tariff fee use calculate_lawyer_fee, and for court fees calculate_court_fee. Returns the amounts and their breakdown. Amounts in rial; dates in the Jalali calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | A civil matter is first, appeal, supreme or enforcement. A criminal one is prosecution (دادسرا), first, appeal, order_objection (اعتراض به قرار) or cassation. | |
| case_kind | Yes | family covers امور حسبی and the financial claims of a marriage — mehrieh and نفقه are family, not financial. non_judicial is a هیأت such as قانون کار. | |
| membership | No | bar is کانون وکلای دادگستری, markaz is مرکز وکلا؛ they owe different shares. bar when not said. | |
| criminal_band | No | Which band the gravest charge falls in. court1 is کیفری یک، نظامی یک و انقلاب; court2 is کیفری دو، نظامی دو و اطفال. | |
| extra_charges | No | Charges beyond the gravest one, in a criminal case (0–20). | |
| criminal_final | No | The criminal first-instance judgment is final (no appeal). | |
| final_judgment | No | A financial claim whose judgment cannot be appealed because of its value. | |
| claim_amount_rial | No | بهای خواسته, in ریال. Only a financial claim has one. | |
| contract_fee_rial | No | The حقالوکاله written in the وکالتنامه, in ریال. Left out, the stamp is computed on the tariff for that stage, which is also its floor. | |
| government_client | No | The client is a ministry, a state company or a شهرداری. | |
| no_prosecution_stage | No | A criminal case with no دادسرا stage (it goes straight to court); its share moves to the first instance. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context the annotations don't: what is computed (stamp plus fund and Bar shares), the output shape (amounts and their breakdown), and the units/calendar conventions (rial, Jalali). It does not discuss failure modes or rounding assumptions, which is the only gap for a pure calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the verb and resource, then routing to siblings, then units. Nothing is redundant and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't spell out return values beyond the brief 'amounts and their breakdown' note, and annotations cover the safety profile. Purpose, alternatives, scope, and unit conventions are all present, leaving nothing an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the heavily annotated enums carry most of the load. The description still adds framing the schema lacks: that the computation is for a single stage of a single case, and that this is a civil-or-criminal distinction, which tells the agent how stage and case_kind interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (compute the tax stamp on a lawyer's power of attorney) and anchors it legally via article 103 of the Direct Taxes Act. It explicitly distinguishes itself from calculate_lawyer_fee and calculate_court_fee, so an agent can disambiguate without reading any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule ('Use it when the question is what the stamp costs') and names both alternative tools with the condition that routes to each. The 'one stage of one case, civil or criminal' framing also scopes when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a Persian legal term means — «مهرالمثل», «اعسار», «قیم», «سرقفلی» — from Dadras's legal glossary: up to three distinct definitions, each with the article it explains and that article's dadrasai.com link. Use it when the question is what a legal word means; for the rules that apply to it, use search_iranian_law. When the whole phrase has no entry, its most specific word is looked up and the result names the word defined. The definitions are Dadras's explanatory notes, not statutory text.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The term in Persian, one or two words, e.g. «مهرالمثل» or «خیار غبن». |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world behavior, yet the description adds substantive traits: up to three distinct definitions with their source article and link, a fallback rule when the whole phrase has no entry (most specific word is looked up and named in the result), and a caveat that definitions are explanatory notes rather than statutory text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and examples, then usage routing, then the fallback caveat. Every sentence carries information, though the definition of "distinct definitions" and the source caveat could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return formatting need not be described. The description still covers source, result shape, fallback behavior, and the sibling alternative, leaving nothing an agent needs in order to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented, so baseline is 3. The description goes further by explaining multi-word phrase handling (the most specific word is resolved and named in the result), which tells the agent how an ambiguous input is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (explain) and resource (a Persian legal term), names the source (Dadras's legal glossary), and gives concrete example terms. An agent can distinguish it from the calculate_* and law-lookup siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the triggering condition ("Use it when the question is what a legal word means") and names the alternative with its own condition ("for the rules that apply to it, use search_iranian_law"). This is exactly the when/when-not/alternative pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Iranian laws and regulations by their title, or part of it, in Dadras's library: up to 10 matches, best first, each with its slug, number of articles and dadrasai.com page. Use it when the user names a law («قانون صدور چک», «مدنی») and its exact title or slug is needed, before list_law_articles. It matches title words only; to find what laws say about a subject, use search_iranian_law.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | All or part of the law's Persian title; a distinctive word works best, e.g. «مدنی» or «صدور چک». |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
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 result behavior: a cap of 10 matches, best-first ordering, per-match fields (slug, article count, dadrasai.com page), and the title-words-only matching rule. It stops short of describing behavior on zero matches or partial-word handling, but the disclosure is well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the core action and result shape, followed by usage conditions and the disambiguation rule. Every sentence carries distinct information with no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with an output schema already present, the description covers purpose, trigger, result cardinality and ordering, matching semantics, and sibling routing. An agent has everything needed to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the baseline is 3. The description nonetheless adds meaning the schema lacks: matching is against title words only, so an agent learns that a topic string or full-text query will not work here and that partial/distinctive words are the intended input style.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (find Iranian laws/regulations by title or partial title) and explicitly distinguishes itself from the two closest siblings: list_law_articles and search_iranian_law. An agent can pick it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the triggering condition ('when the user names a law'), gives concrete examples, states the exclusion ('matches title words only; to find what laws say about a subject, use search_iranian_law'), and specifies sequencing ('before list_law_articles'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full text of one article of an Iranian statute or regulation, word for word, with its law, the details on its page, a warning when it is marked repealed, and its dadrasai.com link. Use it when the article is known — named by the user or returned by another tool as a slug or link; to find which article covers a subject, use search_iranian_law instead. Dadras's explanatory notes, when present, follow the text under a heading that marks them as not part of the law. When the article is missing, the result says whether the law itself was found and gives its slug and article count for list_law_articles.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | The law's Persian name, full or short — «قانون مجازات اسلامی», «قانون مدنی». Used with `article`. | |
| slug | No | Instead of law and article: an article slug or a dadrasai.com/laws/… link from another tool's result. | |
| article | No | The article number, in Persian or Latin digits, e.g. «۱۰», «296», «۲۹۶ مکرر». Used with `law`. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the repealed-article warning, the fact that explanatory notes are labeled as not part of the law, and the missing-article fallback behavior. However, it does not address pagination or size limits for long articles (output schema is not visible here), so it is useful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and return contents, then routing guidance, then edge-case behavior. Dense but each sentence contributes a distinct fact; the middle clause about dadras's explanatory notes is the only part that could be trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-one-record tool with full schema coverage and an output schema, the description closes the remaining gaps: what to expect when the article is repealed, how explanatory notes are demarcated, and what happens on a miss. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents law, slug and article, including the law+article pairing and the slug-or-link alternative. The description only repeats that the article may arrive 'as a slug or link' and does not add syntax or format detail (e.g. Persian/Latin digit handling is already in the schema). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the full text of one article of an Iranian statute or regulation'), and differentiates itself from siblings by naming search_iranian_law and list_law_articles as the tools for adjacent jobs. An agent can tell what it fetches without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit selection rule: 'Use it when the article is known — named by the user or returned by another tool as a slug or link,' with the anti-case 'to find which article covers a subject, use search_iranian_law instead.' Both the trigger and the alternative are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the official figures Dadras's calculators use: the full diya for recent Jalali years (ordinary and sacred-month), the latest gold-coin prices, the Central Bank consumer price index (latest month and annual averages, 1395 = 100) and fixed court fees — each with its source, and a mark on any figure not yet checked against the official text. Use it when the question is the figure itself («دیهٔ کامل ۱۴۰۵ چقدر است؟»); to apply a figure to a case, use the matching calculate_* tool, which reads the same table.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Which figures: diya, coins, price_index, court_fees, or all (the default). | all |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: every figure ships with its source, and unverified figures are flagged as not yet checked against the official text. It doesn't discuss freshness/refresh behavior, but it meaningfully extends the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the resource content front-loaded and the routing rule after it; no filler. The first sentence is long and slightly run-on, which trims it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers what is queried and when. For a single-optional-parameter reference lookup with rich annotations, the definition leaves nothing an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an enum, so a baseline of 3 applies. The description earns above that by unpacking what each category actually contains (sacred-month vs ordinary diya, latest month and annual averages, 1395 = 100 base), which is real meaning beyond the bare enum tokens.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('look up') and resource ('official figures'), then enumerates the exact categories returned (diya, gold-coin prices, CPI, court fees). It explicitly contrasts itself with the calculate_* siblings, so an agent can distinguish it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use rule ('when the question is the figure itself') with a concrete example query, and an explicit alternative ('to apply a figure to a case, use the matching calculate_* tool'). The routing decision is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the articles of one Iranian law in order, 50 per page, each with its title and slug, headed by the law's article count and number of pages. Use it to browse a law's structure or to find an article's slug, with a law slug from find_law; then get_law_article reads an article in full. It lists titles, not text, and is not a search: for articles about a subject use search_iranian_law. A page past the end comes back empty and says so.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Which page of 50 articles, from 1; the first result gives the number of pages. | |
| law_slug | Yes | The law's slug as find_law returns it. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds valuable context beyond annotations: pagination size and ordering, that it returns titles not text, and the past-the-end empty-page behavior. It does not need to explain return values given the output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, all front-loaded: what it does, how to use it, what it is not, and an edge case. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a read-only listing tool. It covers ordering, page size, return contents, the upstream/downstream tools, the search alternative, and the empty-page edge case, with the output schema handling return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning: it specifies 50 per page and that the law slug comes from find_law, clarifying the 'law_slug' param's origin and the page numbering context beyond the schema's per-param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the articles of one Iranian law') and adds scope detail (in order, 50 per page, titles and slugs). It distinguishes itself from siblings like get_law_article (full text) and search_iranian_law (subject search) explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use cases ('browse a law's structure or find an article's slug'), names the upstream prerequisite (law slug from find_law), names the follow-on tool (get_law_article), and states when NOT to use it ('not a search: for articles about a subject use search_iranian_law'). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the text of Iranian statutes and regulations (قوانین و مقررات) published by Dadras — over 95,000 articles of more than 5,900 laws — and get the best-matching articles, each with an excerpt of its text, a note when it is repealed or old, and its dadrasai.com link. Use it for a question about what Iranian law says on a subject — «شرایط فسخ قرارداد اجاره», «مجازات کلاهبرداری» — or to check an article's wording before quoting it. Not for reading one known article in full (get_law_article), finding a law by its name (find_law), a word's meaning (explain_legal_term) or an amount (the calculate_* tools). Covers statutes and regulations only, not court rulings. Candidates are ordered by a legal relevance model; an article named by number and law comes first. Works best in Persian, in the statute's own vocabulary rather than as a story.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many articles to return (1–8); 5 when not given. | |
| query | Yes | A Persian search phrase of a few words — the legal subject («حضانت فرزند پس از طلاق») or an article («ماده ۱۰ قانون مدنی»); English works less well. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The result, in Persian, as it should be quoted. |
| links | Yes | The dadrasai.com pages the result cites, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: what each result includes (excerpt, repeal/age note, link), the ranking model ('legal relevance model', with an article named by number and law ranked first), the language expectation, and the corpus boundary. This is rich disclosure for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single dense paragraph, but front-loaded with purpose and results, then usage, then exclusions, then ranking behavior — every sentence carries information. Slightly long, yet no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the tool covers scope, alternatives, ranking rationale, and language/query style. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds query-formulation guidance beyond the schema: target the statute's own vocabulary rather than a narrative, use Persian, and expect article-number-style queries (e.g. «ماده ۱۰ قانون مدنی») to rank first. `limit` is left entirely to the schema, which already documents the 1–8 range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (text of Iranian statutes and regulations published by Dadras) with concrete scale (95,000+ articles across 5,900+ laws) and what each result contains (excerpt, repealed/old note, dadrasai.com link). It clearly differentiates itself from siblings like get_law_article and find_law by naming them in the negative space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('a question about what Iranian law says', 'check an article's wording before quoting') and when not to, naming each alternative tool for the excluded cases (get_law_article, find_law, explain_legal_term, the calculate_* tools). It also scopes the corpus ('statutes and regulations only, not court rulings').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_court_fee2 fields changedInput schema / properties / non_financial_kind / descriptionPrevious value: -"For a non-financial claim or request: which one. Values: non-financial-first = دعاوی غیرمالی — مرحله بدوی; non-financial-appeal = دعاوی غیرمالی — تجدیدنظر; evidence-preservation = درخواست تأمین دلیل; claim-security = درخواست تأمین خواسته."New value: +"For a non-financial claim or request: which one. Values: non-financial-first = دعاوی غیرمالی — مرحله بدوی; non-financial-objection = دعاوی غیرمالی — واخواهی; non-financial-appeal = دعاوی غیرمالی — تجدیدنظر; non-financial-retrial = دعاوی غیرمالی — اعاده دادرسی و اعتراض ثالث; family-first = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — مرحله بدوی; family-objection = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — واخواهی; family-appeal = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — تجدیدنظر; family-retrial = دعاوی غیرمالی خانواده (حضانت، ملاقات، تمکین و مانند آن) — اعاده دادرسی و اعتراض ثالث; family-interim = تأمین خواسته یا دستور موقت در امور خانواده — مرحله بدوی; marriage-first = طلاق، نکاح، فسخ نکاح و نسب — مرحله بدوی; marriage-objection = طلاق، نکاح، فسخ نکاح و نسب — واخواهی; marriage-appeal = طلاق، نکاح، فسخ نکاح و نسب — تجدیدنظر; marriage-cassation = طلاق، نکاح، فسخ نکاح و نسب — فرجامخواهی; marriage-retrial = طلاق، نکاح، فسخ نکاح و نسب — اعاده دادرسی و اعتراض ثالث; hasbi-first = امور حسبی — مرحله بدوی; hasbi-objection = امور حسبی — واخواهی; hasbi-appeal = امور حسبی — تجدیدنظر; hasbi-cassation = امور حسبی — فرجامخواهی; hasbi-retrial = امور حسبی — اعاده دادرسی و اعتراض ثالث; civil-status-first = دعاوی اسناد سجلی — مرحله بدوی; civil-status-objection = دعاوی اسناد سجلی — واخواهی; civil-status-appeal = دعاوی اسناد سجلی — تجدیدنظر; civil-status-retrial = دعاوی اسناد سجلی — اعاده دادرسی و اعتراض ثالث; non-judicial-first = اعتراض به رأی مراجع غیرقضایی — مرحله بدوی; non-judicial-objection = اعتراض به رأی مراجع غیرقضایی — واخواهی; non-judicial-appeal = اعتراض به رأی مراجع غیرقضایی — تجدیدنظر; non-judicial-retrial = اعتراض به رأی مراجع غیرقضایی — اعاده دادرسی و اعتراض ثالث; evidence-preservation = درخواست تأمین دلیل; claim-security = درخواست تأمین خواسته; interim-order = درخواست دستور موقت; request-appeal = تأمین خواسته یا دستور موقت — تجدیدنظر; unvalued-claim = خواستهٔ مالی که هنگام تقدیم تقویم نشده (علیالحساب); provisional-enforcement = درخواست اجرای موقت حکم; order-appeal = اعتراض یا تجدیدنظر از قرار (دادگاه و دیوان عالی کشور); enforcement-third-party = اعتراض شخص ثالث به اجرای احکام مدنی."Input schema / properties / non_financial_kind / enumPrevious value: -[
- "non-financial-first",
- "non-financial-appeal",
- "evidence-preservation",
- "claim-security"
-]New value: +[
+ "non-financial-first",
+ "non-financial-objection",
+ "non-financial-appeal",
+ "non-financial-retrial",
+ "family-first",
+ "family-objection",
+ "family-appeal",
+ "family-retrial",
+ "family-interim",
+ "marriage-first",
+ "marriage-objection",
+ "marriage-appeal",
+ "marriage-cassation",
+ "marriage-retrial",
+ "hasbi-first",
+ "hasbi-objection",
+ "hasbi-appeal",
+ "hasbi-cassation",
+ "hasbi-retrial",
+ "civil-status-first",
+ "civil-status-objection",
+ "civil-status-appeal",
+ "civil-status-retrial",
+ "non-judicial-first",
+ "non-judicial-objection",
+ "non-judicial-appeal",
+ "non-judicial-retrial",
+ "evidence-preservation",
+ "claim-security",
+ "interim-order",
+ "request-appeal",
+ "unvalued-claim",
+ "provisional-enforcement",
+ "order-appeal",
+ "enforcement-third-party"
+]calculate_stamp_duty4 fields changedInput schema / properties / criminal_finalAdded value: +{
+ "description": "The criminal first-instance judgment is final (no appeal).",
+ "type": "boolean"
+}Input schema / properties / extra_charges / descriptionPrevious value: -"Charges beyond the gravest one, in a criminal case."New value: +"Charges beyond the gravest one, in a criminal case (0–20)."Input schema / properties / final_judgmentAdded value: +{
+ "description": "A financial claim whose judgment cannot be appealed because of its value.",
+ "type": "boolean"
+}Input schema / properties / no_prosecution_stageAdded value: +{
+ "description": "A criminal case with no دادسرا stage (it goes straight to court); its share moves to the first instance.",
+ "type": "boolean"
+}calculate_court_deadlinecalculate_court_feecalculate_diyacalculate_inheritancecalculate_lawyer_feeexplain_legal_term1 field changedInput schema / properties / term / descriptionPrevious value: -"The term in Persian, e.g. «مهرالمثل»."New value: +"The term in Persian, one or two words, e.g. «مهرالمثل» or «خیار غبن»."find_law1 field changedInput schema / properties / name / descriptionPrevious value: -"All or part of the law's Persian name, e.g. «مدنی» or «صدور چک»."New value: +"All or part of the law's Persian title; a distinctive word works best, e.g. «مدنی» or «صدور چک»."get_law_article3 fields changedInput schema / properties / article / descriptionPrevious value: -"Article number, e.g. «۱۰» or «۲۹۶ مکرر»."New value: +"The article number, in Persian or Latin digits, e.g. «۱۰», «296», «۲۹۶ مکرر». Used with `law`."Input schema / properties / law / descriptionPrevious value: -"The law's Persian name, e.g. «قانون مجازات اسلامی»."New value: +"The law's Persian name, full or short — «قانون مجازات اسلامی», «قانون مدنی». Used with `article`."Input schema / properties / slug / descriptionPrevious value: -"An article slug or dadrasai.com/laws/… link instead."New value: +"Instead of law and article: an article slug or a dadrasai.com/laws/… link from another tool's result."get_reference_rateslist_calculatorslist_law_articles2 fields changedInput schema / properties / law_slug / descriptionPrevious value: -"From find_law."New value: +"The law's slug as find_law returns it."Input schema / properties / page / descriptionPrevious value: -"Page of 50 articles, from 1."New value: +"Which page of 50 articles, from 1; the first result gives the number of pages."run_calculatorsearch_iranian_law2 fields changedInput schema / properties / limit / descriptionPrevious value: -"How many articles to return (1–8)."New value: +"How many articles to return (1–8); 5 when not given."Input schema / properties / query / descriptionPrevious value: -"Persian search phrase, e.g. «حضانت فرزند پس از طلاق»."New value: +"A Persian search phrase of a few words — the legal subject («حضانت فرزند پس از طلاق») or an article («ماده ۱۰ قانون مدنی»); English works less well."calculate_late_payment1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}calculate_mehrieh1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}calculate_stamp_duty1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}explain_legal_term1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}find_law2 fields changedInput schema / properties / name / descriptionAdded value: +"All or part of the law's Persian name, e.g. «مدنی» or «صدور چک»."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}get_law_article1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}list_calculators1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}list_law_articles2 fields changedInput schema / properties / page / descriptionAdded value: +"Page of 50 articles, from 1."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}run_calculator3 fields changedInput schema / properties / slug / descriptionAdded value: +"The calculator's slug from list_calculators, e.g. «diya-calculator»."Input schema / properties / values / descriptionAdded value: +"The calculator's fields by id, as list_calculators names them; dates Jalali."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}search_iranian_law2 fields changedInput schema / properties / limit / descriptionAdded value: +"How many articles to return (1–8)."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "links": {
+ "description": "The dadrasai.com pages the result cites, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "The result, in Persian, as it should be quoted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "links"
+ ],
+ "type": "object"
+}calculate_late_paymentcalculate_mehriehcalculate_stamp_dutyexplain_legal_termfind_lawget_law_articlelist_calculatorslist_law_articlesrun_calculatorsearch_iranian_lawIranian statutes, rulings, opinions and legal calculators. Needs a paid Chistara connection link.
Search and read Lebanese laws, articles, court rulings and the Official Gazette, verbatim.
Read-only search of Al-Taswia's published Iraqi law articles. General information, not legal advice.
Pakistani case law and statutes: Supreme Court and High Court judgments, laws, drafting templates.
Add one secure layer between your agents and this server.
