Iranian statutes, legal glossary and legal calculators from Dadras, linked to dadrasai.com.
Scored across 10 tools
Most tools have clearly distinct purposes: search vs. find vs. get vs. list for laws, and separate calculators for specific common questions. However, the three specialized calculators (calculate_late_payment, calculate_mehrieh, calculate_stamp_duty) overlap functionally with the generic run_calculator, which likely can run the same calculators, creating some selection ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (calculate_*, explain_*, find_*, get_*, list_*, run_*, search_*). There are no deviations in style or verb choice.
10 tools is a reasonable and well-scoped set for a legal reference and calculator server. The count is slightly inflated by three specialized calculators that appear to duplicate functionality available through run_calculator, but overall the set is not excessive.
The surface covers the domain well: searching laws, retrieving specific articles, finding laws by name, listing articles, explaining legal terms, and running both specialized and generic calculators. There are no obvious dead ends for typical legal research and calculation tasks.
خسارت تأخیر تأدیه on a debt (مادهٔ ۵۲۲ قانون آیین دادرسی مدنی): what the loss of purchasing power between the month a debt fell due and the month it is paid comes to, from the central bank's price index. Call it for any question about what a late debt is worth today, and never work the figure out yourself. 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 ریال. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context beyond that. It does so usefully by disclosing the data source (the central bank's price index), the legal basis, and unit conventions, though it says nothing about edge cases such as partial payments or index revisions.
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?
The definition is compact, front-loaded with the legal term and rule, and every sentence carries information. The first sentence is dense but not padded, and the trailing conventions sentence is terse.
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-only calculation tool with full schema coverage, the description supplies what the schema cannot: the legal basis, the index source, the meaning of the result, and the instruction to rely on the tool rather than computing manually. No output schema exists, but the description's phrasing ("what ... comes to") makes the return value clear enough.
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 all five parameters, including the default for payment_year/payment_month. The description's unit note (rial, Jalali calendar) restates conventions already present in the schema, adding only marginal value. 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?
The description names a specific operation (calculating خسارت تأخیر تأدیه on a debt), cites the governing rule (مادهٔ ۵۲۲), and defines the computation precisely as the loss of purchasing power between the due month and the payment month. It is clearly distinguishable from the other topic-specific calculators (mehrieh, stamp duty) 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?
"Call it for any question about what a late debt is worth today, and never work the figure out yourself" gives both a clear trigger condition and an explicit prohibition on doing the math manually. It stops short of naming an alternative tool or stating when-not-to-use (e.g., debts not subject to Art. 522), so it is strong but not fully exhaustive.
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 ریال indexed from the year of the marriage to the year of the claim, or a number of gold coins at their current price. Call it for any question about what a mehrieh is worth now, and never work the figure out yourself. 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 ریال. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds domain disambiguation: coins are valued at the day's price rather than indexed, amounts are in rial, and dates use the Jalali calendar. This is meaningful context beyond the annotations, though return format is not described.
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 compact sentences, front-loaded with the core purpose before the usage directive and unit conventions. No filler, though the final clause about rial/Jalali slightly overlaps the schema.
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 computation tool with 7 parameters, one required, full schema coverage, and no output schema, the description supplies enough to understand both input modes and the units involved. The main gap is that it does not describe the shape of the returned valuation.
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 parameters are already well documented in the schema (including the coin-type enum and the estate/death-year nuance). The description only restates the rial/Jalali unit conventions, which is baseline-level added value.
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 (value) and resource (mehrieh) and explains the two valuation modes – indexed rial sum vs. gold coins at current price – which distinguishes it clearly from siblings like calculate_late_payment or calculate_stamp_duty.
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?
"Call it for any question about what a mehrieh is worth now, and never work the figure out yourself" gives a clear use condition and even an explicit directive against doing the math manually. It does not name alternative tools, but the applicability condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tax stamp on a وکالتنامه (مادهٔ ۱۰۳ قانون مالیاتهای مستقیم) and the fund and Bar shares paid with it, for one stage of one case. Call it for any question about what a lawyer pays to file a وکالتنامه, and never work the figure out yourself. 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. | |
| 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 شهرداری. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful operating context beyond that: what is being computed (stamp + fund + Bar shares), the scope limitation (one stage, one case), and the units ('Amounts in rial; dates in the Jalali calendar').
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 sentences, front-loaded with what is computed, with no filler. The legal citation and unit conventions are packed into the same breath as the purpose.
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 an 8-parameter, enum-heavy read-only calculator with full schema coverage, the description tells the agent what the result comprises and in which units, so nothing essential for a correct call is missing. A brief note on the return shape (since no output schema exists) would have made it complete.
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 parameter descriptions themselves carry the domain nuance (defaults for membership, contract_fee floor, criminal band mapping). The description adds only the rial/Jalali unit convention and the single-stage scope, so the 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?
Names a specific verb-resource pair (the tax stamp on a وکالتنامه plus fund and Bar shares), cites its legal basis (مادهٔ ۱۰۳), and fixes the scope to 'one stage of one case.' An agent can distinguish this from the sibling calculators (calculate_mehrieh, calculate_late_payment) purely from the description.
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?
'Call it for any question about what a lawyer pays to file a وکالتنامه, and never work the figure out yourself' gives explicit when-to-use guidance and steers the agent away from self-computation. It does not, however, mention when a different calculator is the right one (e.g. mehrieh or late-payment questions that may also touch a وکالتنامه).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a Persian legal term means — «مهرالمثل», «اعسار», «قیم», «دعوای بازرگانی» — from Dadras's legal glossary, with the article each definition explains and its dadrasai.com link. Use it when a reader asks what a legal word means.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The term in Persian, e.g. «مهرالمثل». |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds useful non-annotation context: definitions come from Dadras's glossary and include the explaining article plus a dadrasai.com link.
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 and examples, then the usage condition in one clause. The four inline examples consume space but earn it by illustrating the Persian input domain; still slightly heavier than strictly needed.
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 rich annotations and no output schema, the description adequately explains what comes back (definition, source article, link). Nothing essential to invoking 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% on the single 'term' parameter and the schema itself gives the Persian example and length bounds. The description repeats the example style but adds no format or matching semantics, 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+resource ('what a Persian legal term means') and anchors it with four concrete Persian examples and the source glossary (Dadras). Siblings are about law articles, searches, and calculators, so an agent can tell this glossary lookup apart instantly.
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?
'Use it when a reader asks what a legal word means' gives a clear triggering context. There is no explicit when-not guidance or named alternative among the siblings (e.g. find_law vs this glossary), which keeps it just short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Iranian laws by (part of) their name in Dadras's library and get each one's slug, article count and dadrasai.com page.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine value by disclosing the return payload (slug, article count, dadrasai.com page), which no output schema provides; pagination and multi-match behavior are still unstated.
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?
One sentence, front-loaded with the action and matching rule, with the return fields trailing. No filler or 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 single-parameter lookup with no output schema, the description covers the input semantics and the returned fields, which is most of what an agent needs. It stops short of describing behavior on zero matches or multiple matches.
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 0%, so the description must carry the parameter burden, and it does explain that matching is on a *partial* name rather than an exact identifier. It does not mention the minLength 2 / maxLength 120 constraints, leaving a small gap.
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 ('Find'), resource ('Iranian laws'), matching mechanism ('by (part of) their name') and the resulting fields (slug, article count, page). It never distinguishes itself from the near-identical sibling search_iranian_law, so an agent must guess which name-lookup path to use.
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?
Usage is only implied: the description makes clear this is a lookup keyed on (partial) law names. There is no explicit when-to-use, no exclusion, and no pointer to search_iranian_law as the alternative for full-text or topical queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full text of one article of an Iranian statute or regulation, with its dadrasai.com link. Give the law's name and the article number (law: «قانون مدنی», article: «۱۰») or a slug/link from another tool's result.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | The law's Persian name, e.g. «قانون مجازات اسلامی». | |
| slug | No | An article slug or dadrasai.com/laws/… link instead. | |
| article | No | Article number, e.g. «۱۰» or «۲۹۶ مکرر». |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and determinism are covered by structured data. The description adds only that the response includes a dadrasai.com link; it says nothing about error behavior for missing laws/articles or how the two input modes interact.
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 sentences, front-loaded with the return value followed by the input guidance, with no filler. It is efficient, though the second sentence mixes two input modes without a structural cue for when each applies.
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?
There is no output schema, and the description compensates by naming the return payload (full article text with link). It also implicitly resolves the unusual 'no required parameters' schema by describing the law+article versus slug alternatives, though it does not say what happens if both modes are omitted.
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 all three parameters with examples in Persian. The description merely repeats the law/article example and hints the slug may come from another tool, adding little beyond the structured fields; 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 concrete verb and resource: it returns the full text of exactly one Iranian law article plus its dadrasai.com link. The singular 'one article' implicitly separates it from list_law_articles and search_iranian_law, but no sibling is named explicitly, so it stops short of a 5.
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?
The invocation hint ('Give the law's name and the article number ... or a slug/link from another tool's result') implies this is a follow-up call to a finder/search tool, which is useful chaining guidance. However, it never states when to prefer this over find_law or search_iranian_law, so usage is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every legal calculator Dadras offers (diya, inheritance shares, court fees, lawyer's fees, court deadlines and more) with the fields each one takes, for run_calculator.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered externally. The description adds real behavioral context by disclosing what the tool returns — every calculator plus the fields each accepts — which is exactly what an agent needs to plan a follow-up run_calculator call.
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?
One compact sentence with the resource and its payoff front-loaded. The parenthetical list and 'and more' are slightly loose but earn their place by signaling breadth of coverage.
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?
No output schema exists, yet the description carries the return-value burden by stating that each calculator's fields are included, which is the key fact for a discovery tool. A note on ordering or count would be nice but is not essential for correct invocation.
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?
The tool takes zero parameters, so the baseline is 4 by rule. The description correctly implies a no-argument enumeration and adds nothing misleading about inputs.
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 (list) and resource (Dadras's legal calculators), enumerates concrete contents (diya, inheritance shares, court fees, lawyer's fees, court deadlines), and explicitly ties itself to the run_calculator sibling, so an agent can distinguish it from run_calculator and the other calculate_* tools immediately.
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?
The trailing 'for run_calculator' makes the intended workflow clear: call this to discover available calculators and their fields before invoking run_calculator. It does not explicitly state when NOT to use it (e.g., if you already know the calculator name), but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The articles of one law in order, 50 per page, each with its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| law_slug | Yes | From find_law. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: results are ordered and chunked at 50 per page, and each item carries a slug, which tells the agent how to page and what identifiers come back.
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?
One compact sentence, front-loaded with the resource and followed immediately by the two operational facts an agent needs (ordering and page size). Zero 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 no output schema, the description carries the return shape and it does so adequately: ordered articles, paginated at 50, each with a slug. What is missing is any sense of volume, termination, or what a law with zero articles yields, which keeps it from a 5.
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 50%: law_slug has a description ('From find_law'), while page is undocumented. The description compensates by clarifying the page size (50 per page), which is the one semantic the schema omits, but it adds nothing about page numbering or bounds beyond the schema's minimum/default.
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 the resource (articles of one law), ordering, and pagination rate, which clearly separates it from get_law_article (single article) and find_law (law lookup). The verb is only implied, and no sibling is named explicitly, so it falls short of a 5.
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?
The description gives no when-to-use guidance, no indication of when to prefer get_law_article over this, and no prerequisites. The only routing hint ('From find_law') lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one calculator from list_calculators: slug plus values keyed by the field ids it lists. Returns the result, its breakdown, the reference figures used and their legal basis. Never work these figures out yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| values | Yes |
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 adds meaningful behavioral context by explaining that it returns the result, breakdown, reference figures, and legal basis, though it omits error or edge-case behavior.
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 tight sentences: purpose and inputs first, then return contents, then a clear directive. Nothing is wasted and the most important information is front-loaded.
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 no output schema, the description usefully describes the return shape. Given nested values, it clarifies how keys work. It is nearly complete, though error handling and validation expectations are left implicit.
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 0%, so the description must compensate. It explains that 'slug' comes from list_calculators and that 'values' are keyed by the field ids the calculator lists, adding essential meaning beyond the bare 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?
The description states a specific verb and resource: 'Run one calculator from list_calculators.' It clearly positions the tool as the generic calculator runner and explains the required inputs, but it does not explicitly differentiate itself from the specific calculate_* sibling tools.
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 tells the agent to get a calculator from list_calculators and gives a strong directive: 'Never work these figures out yourself.' That is useful usage context, but it does not name alternatives such as calculate_late_payment or describe when not to use this generic runner.
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. Returns matching articles with their text and a dadrasai.com link to each. Use it for any question about what Iranian law says, and quote from the results instead of from memory. Write the query in Persian, in the statute's vocabulary — «شرایط فسخ قرارداد اجاره», «مجازات کلاهبرداری», «ماده ۱۰ قانون مدنی» — not as a story. An article named by number and law comes first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Persian search phrase, e.g. «حضانت فرزند پس از طلاق». |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine non-annotation context: the return shape (article text plus dadrasai.com link) and ranking behavior ('an article named by number and law comes first'). No pagination or result-count behavior is described, but that is a minor gap given the small limit cap.
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 what the tool does and what it returns, then the usage rule, then query-format advice with examples. Every sentence carries information; nothing is padding despite the length.
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 no output schema, the description usefully describes the return content and ranking. With no annotation contradictions and a simple two-parameter surface, an agent has enough to call it correctly; the only missing piece is routing guidance versus the find_law/get_law_article siblings.
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 only 50% (limit is undocumented), so the description must compensate — and it does, explaining that the query must be Persian, in statute vocabulary, with three concrete example phrasings. It adds real semantics beyond the schema's short query description, though it says nothing about the undocumented limit parameter.
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 — searching Iranian statutes/regulations published by Dadras — and adds what comes back (matching articles plus a link). However, it never distinguishes itself from siblings find_law and get_law_article, so an agent cannot be sure which of the three to pick without opening schemas.
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 clear when-to-use instruction ('any question about what Iranian law says') plus a behavioral rule to quote results rather than memory, and detailed query-writing guidance with Persian examples. It stops short of naming when NOT to use it or why find_law/get_law_article would be preferred, so exclusion guidance is absent.
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_late_paymentcalculate_mehriehcalculate_stamp_dutyexplain_legal_termfind_lawget_law_articlelist_calculatorslist_law_articlesrun_calculatorsearch_iranian_lawSearch Iranian statutes, court rulings, advisory opinions and circulars, with legal calculators.
Pakistani case law and statutes: Supreme Court and High Court judgments, laws, drafting templates.
Czech legal calculators, document templates, legal glossary and lawyer-reviewed guides.
Automatic Brazilian legal calculators: monetary correction and debt settlement (correction by IPCA,
Add one secure layer between your agents and this server.
