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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool uses only the first 6 digits / BIN, but it omits whether the input is validated, what the return value looks like, and how unknown or malformed BINs are handled.

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 description is a single, front-loaded sentence with no wasted words. It conveys the core operation and the relevant input portion efficiently.

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 and no annotations, the description should explain return values and error behavior. It says what the tool identifies but not what an agent receives back or what happens for unrecognized BINs, leaving the definition incomplete for a lookup utility.

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% and the only parameter is an undescribed string. The description adds meaningful semantics by specifying that the parameter is a card number and that only the first 6 digits / BIN are used, but it does not specify format constraints such as digit-only input or accepted lengths.

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 uses a specific verb ('Identify') and resource ('Iranian bank') and states the exact input ('card number (first 6 digits / BIN)'). This clearly distinguishes it from siblings such as validate_card_number (validation) and bank_from_sheba (sheba-based lookup).

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 does not say when to use this tool versus alternatives, nor does it state prerequisites or exclusions. An agent can infer that it is used when a card BIN is available, but no explicit usage guidance is provided.

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

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

No annotations are provided, so the description carries the full behavioral burden and it does not meet it. It says nothing about what happens with an invalid or unformatted Sheba, whether input must be a full IBAN or may be just the 3-digit code, or whether the lookup is offline/static.

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?

A single front-loaded sentence with no padding, which is the right size for a one-parameter lookup. The parenthetical is the only slightly ambiguous element, so it falls short of perfect.

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 and no annotations, the description should hint at the return value (e.g., a bank name and/or code) and error behavior, but it does neither. For a tool whose entire value is the mapping it returns, that leaves a real gap.

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 0% and the single parameter 'sheba' has no schema description, so the description must compensate. It does clarify the parameter expects a Sheba/IBAN number, but the trailing '(3-digit bank code)' muddies whether the argument is the full IBAN or only the bank-code portion.

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 ('Identify') and resource ('the Iranian bank') with the exact input medium ('Sheba (IBAN) number'), which is enough to distinguish it from the sibling bank_from_card and validate_sheba 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?

Usage is implied by the specified input type, so an agent can infer it fires when a Sheba/IBAN is in hand. However, there is no explicit when-to-use guidance, no mention of the sibling bank_from_card for card numbers, and no statement of prerequisites such as the Sheba needing to be valid.

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

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

With no annotations, the description carries the full behavioral burden, and it leaves key traits undisclosed: what the tool returns (tax amount, net, gross, or all three), rounding behavior, and whether ratePercent is a fraction or percent (partially implied by the name). It does state the rate-supply requirement, which is a small but real disclosure.

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 short sentences, front-loaded with the operation and its required input, then the mode semantics. The opening 'VAT helper' is mildly redundant with the tool name, but nothing else is wasted.

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 three-required-parameter calculator with no annotations and no output schema, the description covers inputs adequately but says nothing about the return value, which an agent cannot infer from structured fields. Rounding/precision behavior is also unstated, leaving a meaningful gap for a numeric tool.

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 defines what 'exclusive' and 'inclusive' mean in relation to the amount, adding genuine semantic meaning beyond the bare enum values, and clarifies that ratePercent is a percent. Only 'amount' is left undefined, but its meaning is self-evident.

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 name plus 'VAT helper' and the mode definitions make it clear this computes VAT on an amount, and it distinguishes the two calculation directions. It does not explicitly differentiate from siblings, but no sibling tool is VAT-related, so ambiguity is low.

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?

There is no when-to-use guidance, no statement of when this is preferable to computing manually, and no mention of related tools (e.g., currency conversion or number formatting siblings). The only guidance-like content is the prerequisite that ratePercent must be supplied, which is already enforced by the schema's required list.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the critical domain fact (1 toman = 10 rial), which prevents a wrong-direction conversion, but says nothing about rounding/precision, negative or zero amounts, or the output shape.

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?

A single sentence that front-loads the action and the resource, with the conversion ratio parenthetically appended. Nothing is wasted and nothing extraneous is present.

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 three-parameter arithmetic utility with no annotations and no output schema, the description is nearly sufficient — the core mechanic and ratio are given. The remaining gap is unstated rounding/precision behavior and the unit basis of 'amount', which a careful agent would want.

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 clarifies the relationship between the two enum-valued parameters and the conversion factor, but never states that 'amount' is denominated in the 'from' unit, leaving a real ambiguity in the most important 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 ('Convert') and resource ('between rial and toman') and even supplies the exact exchange ratio, so the operation is unambiguous. It does not explicitly distinguish itself from siblings, but no sibling covers currency conversion, so the risk of confusion is low.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., calculate_vat for tax math). The usage is arguably self-evident from the name, but the description itself adds no routing or exclusion information.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses BOM insertion, quoting, Persian-digit conversion in numeric cells, formula-injection guarding, and corruption warnings. It still omits return shape, defaults for optional flags, and how delimiter/excelSafe toggles affect 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?

A single front-loaded sentence with a colon and compact feature list. Every clause adds a concrete behavioral trait, and there is no padding.

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?

The description is appropriately rich about safety behavior, but for a four-parameter tool with no output schema and no annotations it should also describe return format, optional parameter defaults, and delimiter/excelSafe semantics. It is adequate for choosing the tool but incomplete for invoking it precisely.

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 explain the four parameters. It implies `rows` and mentions BOM/Excel safety, but it does not explain `delimiter`, `bom`, or `excelSafe` as parameters, nor their defaults or effects. This is only partial compensation for a fully undocumented 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 and resource: "Build Excel/Sheets-safe CSV from rows." It also names the output context (Excel/Sheets) and the key safety properties, so an agent can distinguish it from general formatting or Persian-text utilities.

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 usage context is implied by "Excel/Sheets-safe CSV from rows," but there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative. The sibling list contains no direct CSV export tool, so the lack of alternatives is less harmful, but usage remains inferred rather than stated.

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

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

No annotations are provided, so the description carries the full burden, and it only partly does. The examples usefully disclose output shape and that percent appends درصد, but it says nothing about default mode behavior, what halfAsNim changes (presumably rendering 0.5 as نیم), or how malformed input is handled.

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?

A single compact sentence with two worked examples — very little waste. It is front-loaded on the domain but opens as a sentence fragment with no verb, which costs a bit of immediate legibility.

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, no annotations, and 0% parameter coverage, the description should document the three parameters and the return string format. It demonstrates output nicely via examples but leaves halfAsNim and mode defaults entirely unaddressed, which is a material gap for an agent invoking the tool.

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% across three parameters, so the schema gives no meaning at all. The description indirectly covers mode (decimal/percent/fraction examples) and hints at value formatting, but halfAsNim is completely unexplained and no default for mode is stated.

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 the resource precisely (decimals, percents, fractions) and shows concrete input→output examples, so the transformation is unmistakable. It does not explicitly contrast itself with the sibling integer/price word converters (number_to_persian_words, price_to_persian_words), leaving that differentiation to inference.

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 implied: an agent can infer this is the tool for decimals/percents/fractions while number_to_persian_words covers integers. But there is no explicit when-to-use statement, no mention of the sibling alternatives, and no guidance on invalid input or unsupported formats.

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

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

With no annotations and no output schema, the description carries the burden and does reasonably well: it discloses the three detection outputs and enumerates the safe-wrapping modes (FSI/RLI/LRI isolates vs. HTML bdi / dir=auto). It does not describe error handling or the exact return shape, so it stops short of full disclosure.

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 no filler; the core detection capability is front-loaded and the optional wrapping plus usage hint follow. Every clause carries information.

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 two-parameter, annotation-free tool with no output schema, the description covers purpose, the detection outputs, the wrap modes, and usage context, which is close to sufficient. The main gap is the absence of a described return shape, which no structured field supplies.

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 meaningfully categorizes the wrap enum values ('Unicode isolates (FSI/RLI/LRI)' and 'HTML <bdi> / dir=auto'), adding semantics beyond the bare enum strings, and the text parameter is self-evident. It never explicitly names the 'wrap' parameter, so it is not fully explicit.

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 (detect) and resource (text direction) and clarifies the two outputs it produces (first-strong direction, dominant script, mixed flag) plus an optional wrapping capability. It is clearly distinguishable from siblings like rtl_guidelines or rtl_audit_css, which are about CSS/layout rather than direction detection.

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 concrete usage context: 'Use for usernames, product names and mixed Persian/English strings.' This is a clear positive signal for when to reach for the tool, though it offers no explicit when-not guidance or named alternative (e.g., versus rtl_guidelines).

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

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

With no annotations, the description carries the full burden, and it does disclose the core behavior: ISIRI 9147 mapping, bidirectionality (Latin->Persian and Persian->Latin), and an auto-detection mode, all illustrated with a worked example. It stops short of edge-case behavior (mixed-script input, unmappable keys, handling of digits/punctuation), so it is not fully closed.

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 dense sentence: action first, mapping standard second, concrete example third, parameter hint last. No filler and nothing that could be dropped without losing information.

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 stateless, two-parameter text transform with no output schema, the description supplies what an agent needs to invoke it correctly – the direction semantics and the transformation contract. Only the individual enum values and edge-case handling are left unstated, which is a minor gap.

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 the meaning of the 'auto' enum value ('picks by script') but leaves en-to-fa and fa-to-en implicit and says nothing about the required 'text' parameter beyond context. Partial compensation, hence a middle score.

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 ('fix text typed with the wrong keyboard layout') and anchors it with a concrete bidirectional example ('sghl' -> 'سلام'), so the transformation is unambiguous. It does not name or differentiate itself from adjacent siblings such as normalize_persian_text or detect_text_direction, which keeps it just 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 only routing guidance is the embedded note that direction 'auto' picks by script, which implies the tool is safe to call without knowing the direction. There is no statement of when to prefer this over normalize_persian_text or the other text-fixing siblings, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It discloses accepted input forms (Persian digits, +98, 0098), which is useful, but says nothing about whether the value is validated, what output format is produced by default, or what happens on invalid input.

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 with the core purpose front-loaded and no filler. The parenthetical examples are dense but serve a purpose; minor ambiguity between input and output examples is the only flaw.

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 formatting tool with no output schema and no annotations, the description should clarify the returned format and the role of persianDigits. It leaves the output contract and the second parameter entirely unaddressed, so an agent cannot fully predict the result.

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 should compensate. It explains accepted input syntax but never mentions the persianDigits boolean, which appears to control output digit rendering and is undocumented in both the schema and the description.

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 conveys that the tool produces display formats for Iranian mobile and landline numbers, which is a clear resource and operation. However, it does not distinguish itself from the sibling normalize_mobile, which likely also handles phone formatting, so sibling differentiation is absent.

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?

There is no statement of when to use this tool versus alternatives like normalize_mobile or mobile_operator, nor any exclusions or preconditions. The agent must infer usage purely from the topic.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state what the tool returns, whether the result is a string, how persianDigits affects output, what the default pattern is, or whether there are side effects. The token list is useful but mostly concerns the pattern parameter rather than overall 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?

The description is two short sentences with zero filler and is front-loaded with the core purpose. The token list is compact and directly useful for constructing the pattern argument.

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 annotations, no output schema, five parameters, and 0% schema description coverage, the description is too sparse. It omits return format, default behavior, persianDigits semantics, and any relationship to sibling date tools, leaving meaningful gaps for an agent trying to invoke 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 0%, and the description only documents the pattern tokens. It does not explain the persianDigits boolean, does not state that pattern is optional or what its default is, and does not add meaning for year, month, or day beyond the schema. The token list is helpful but does not compensate for the undocumented remaining parameters.

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: "Format a Jalali date." It also lists formatting tokens, which clarifies the pattern parameter. However, it does not differentiate this tool from sibling date tools such as parse_jalali_date, jalali_add, or gregorian_to_jalali.

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 prerequisites, and no alternatives. An agent must infer that this tool is for producing formatted Jalali date strings rather than parsing, adding, or converting dates.

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

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

No annotations are provided, but this is a pure string-transformation function with no side effects, permissions, or destructive behavior to disclose. The description adds that Persian/Arabic digits are accepted, which is useful, but it does not clarify the exact return format for edge cases (negatives, decimals, non-digit input).

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?

A single front-loaded sentence with a parenthetical example pair, zero waste. The example does double duty by demonstrating both output styles, though a brief clause naming the options would have earned more without bloat.

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 3-parameter pure function with no output schema and no annotations, the examples do convey the expected output shape, which partially covers the missing return documentation. Still, the two optional enum parameters go undescribed, leaving an agent to guess how to select digit style and separator beyond copying an example.

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% for all three parameters. The description's examples (200,000 vs ۲۰۰٬۰۰۰) implicitly signal the separator and digit-style choices, but the parameters 'digits' (ascii/persian) and 'separator' (','/'٬') are never named or explained, so the description only partially compensates for the coverage 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?

The description states a specific verb+resource (group digits in threes) and gives concrete before/after examples, making the transformation unambiguous. It does not, however, explicitly differentiate itself from the sibling parse_grouped_number (its inverse), so the agent must infer the relationship.

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?

There is no statement of when to use this tool, when not to, or which sibling to prefer. The inverse tool parse_grouped_number is never named, and no context (e.g. display formatting vs. parsing) is given, leaving routing to inference.

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

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

With no annotations, the description carries the burden, and it does disclose useful behavior via worked examples: the localized scale suffix (میلیون/هزار), the Persian decimal separator, the 'latin' style alternative, and unit appending. However, it says nothing about defaults, rounding/truncation behavior, invalid or negative input, or whether the result is a plain string.

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?

A single dense sentence with front-loaded purpose and inline examples; almost no waste. The parenthetical style aside is slightly compressed but still readable and earns its place.

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 compact 5-parameter tool with no output schema and no annotations, the description gives enough to form a correct call (value + optional style/unit) and shows sample outputs. It remains incomplete on three parameters and on edge-case behavior, so it is adequate rather than thorough.

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% across 5 parameters, so the description must compensate. It covers 'style' (with the 'latin' enum value) and 'unit' (with a تومان example), but leaves 'value', 'maxFraction', and 'persianDigits' completely unexplained—a notable gap given the low schema coverage.

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 operation (short/compact number formatting) and immediately grounds it with two concrete input→output examples, so the resource and the transformation are unambiguous. It does not explicitly contrast itself with the likely sibling format_number_grouped, so it falls short of 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?

Usage is only implied by the word 'short' and the compact examples (e.g., UI labels, prices). There is no explicit when-to-use guidance and no mention of when to prefer format_number_grouped or number_to_persian_words instead, which are the obvious alternatives in the sibling list.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it states only the conversion operation. It does not describe the return format, how invalid Gregorian dates are handled, or the extreme year range permitted by the schema (up to ±9007199254740991).

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 description is a single front-loaded sentence with no filler. It is appropriately sized for a simple conversion tool, though it is terse enough that other dimensions suffer.

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, no annotations, and zero parameter descriptions mean the description must compensate for missing structured context, but it does not. An agent cannot tell what the return value looks like (e.g., object with year/month/day vs. a formatted string) or how invalid inputs are handled.

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%; the schema only defines year, month, and day as integers with min/max bounds and no descriptions. The description adds no parameter-level meaning, such as accepted formats, leap-year behavior, or expected ranges beyond 'a Gregorian date'.

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 uses a specific verb ('Convert') and names both source and target resources ('Gregorian date' to 'Jalali calendar'), and the direction implicitly distinguishes it from the sibling jalali_to_gregorian. It does not, however, differentiate from date-formatting or parsing siblings such as format_jalali_date or parse_jalali_date.

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?

There is no when-to-use guidance or mention of alternatives. The agent is not told when this conversion should be preferred over formatting (format_jalali_date), parsing (parse_jalali_date), or the reverse conversion (jalali_to_gregorian).

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

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

With no annotations, the description carries the burden and does add real behavior: weekend model (Friday default, Thursday optional), holiday sourcing ('supply holidays yourself or enable the fixed solar ones'), negative 'days' for add, and count's inclusive boundary. It omits return shapes and whether the start date is counted for 'add'.

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 resource and packed into a single dense sentence with a colon-introduced list; every clause carries information. It is a run-on that could be split for readability, but nothing is wasted.

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, 3-op tool with no output schema, the description covers op semantics and configuration well but never states what each op returns (boolean, date, count). That return-format gap matters precisely because no output schema exists.

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 57%, so the description must compensate, and it does: it explains that 'days' may be negative, that 'to' drives the 'count' op, and that weekend/holidays are configurable. It adds genuine meaning beyond the schema's type declarations, though 'includeFixedSolarHolidays' semantics remain vague.

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 resource ('Business-day helper') and enumerates the three operations with their semantics: 'is_business_day', 'add' (days may be negative) and 'count' (inclusive of 'to'). The Iranian business-day framing distinguishes it implicitly from generic siblings like jalali_add/jalali_diff, but those siblings are never named.

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 per-op semantics imply when each mode applies, and it notes holidays can be supplied or auto-enabled, but there is no explicit when-to-use guidance and no routing away from jalali_add/jalali_diff for plain date math. Usage is inferable rather than stated.

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

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

With no annotations provided, the description does the heavy lifting: it discloses that fixed holidays are returned with Gregorian dates while the Hijri-based list is returned WITHOUT dates, and that lunar holidays shift yearly. That is genuine output-behavior context, though it says nothing about ordering, format, or error cases.

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?

A single front-loaded sentence with purpose first and the coverage detail in parentheses; every clause carries information. It is dense with parenthetical enumerations, which slightly hurts scanability.

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 must convey the return shape, and it does explain the two-part result (dated solar holidays plus undated Hijri list). It stops short of describing the actual date formatting or the structure of each entry, leaving some ambiguity for a consumer.

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 0% and the sole parameter 'year' is undocumented in the schema, so the description must compensate. It does so partially by stating the year is a Jalali year (not Gregorian), which is the key disambiguation, but it adds no guidance on the 1-3177 range or required format.

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 resource (Iranian public holidays) scoped to a Jalali year, and enumerates exactly which fixed solar holidays are covered (Nowruz, 14-15 Khordad, 22 Bahman, 29 Esfand). It is easily distinguished from the neighboring iran_business_days and jalali_year_info 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 implies when the tool applies by explaining the data model (fixed solar holidays vs. Hijri-based ones), and warns that lunar holidays need the official annual calendar. However, it never names an alternative tool or states when a caller should prefer a different sibling for business-day or year-level information.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the set is a fixed 31 provinces, that matching is letter-variant tolerant (valuable for Persian ی/ك variants), and what each record contains — behavior an agent needs before calling. It stops short of stating ordering or exact response shape, which is the only meaningful gap.

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, zero waste: the resource and its return fields come first, then the optional filter behavior. Nothing is repeated or padded.

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, read-only list tool with no output schema, the description covers the data set, the fields returned, and the filter semantics. Minor gaps in output ordering and exact field naming are tolerable at this complexity.

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 0% and the single parameter has no schema description, so the description must compensate — and it does, defining query as an optional Persian/English name filter with letter-variant tolerance. Only the matching mechanics (substring vs exact, case handling) remain unstated.

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 Iran's 31 provinces") and even enumerates the returned fields (ISO 3166-2 code, Persian/English names, capital). It is distinguishable from lookup-style siblings like landline_province, though it never names an alternative 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?

The description says the query parameter is optional and describes its matching behavior (Persian or English, letter-variant tolerant), which implies when to supply it. It gives no explicit when-not-to-use guidance or pointer to a sibling such as persian_fuzzy_search for more advanced matching.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful trait – month overflow clamps to month length – which is not derivable from the schema. However, it omits day-overflow semantics (does adding days roll into months?), how negative deltas behave, and what the tool returns.

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?

A single front-loaded sentence with no filler. The operational detail (overflow clamping) is placed in a parenthetical right where it is relevant, so every clause earns its place.

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 annotations, no output schema, and a 6-parameter sign-sensitive date tool, the description is thinner than the complexity warrants. Return format, day-overflow behavior, and the base-date vs delta distinction are missing, though the clamping note and operand list cover the essentials.

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 0% across 6 parameters, so the description must compensate. It maps the three delta parameters (days, months, years) clearly via 'add days, months and/or years', but it never explains that year/month/day are the base date and that days/months/years are the offsets, nor that negative values subtract. The critical day-vs-days distinction is left implicit.

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 (add) and resource (a Jalali date) plus the operands (days, months, years), so an agent instantly knows this is date arithmetic rather than parsing, formatting, or diffing. It does not explicitly name a sibling to differentiate against, but its purpose is unambiguous.

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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as jalali_diff or format_jalali_date. The use case is only weakly implied by the verb 'add', leaving the agent to infer context from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return shape (years, months, days, total days) and the default value of asOf, which is real behavioral context. It does not say what happens with invalid Jalali input, a future birth date, or whether any permission/rate constraints apply, leaving edge behavior unspecified.

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 short sentences, zero filler, with the core purpose front-loaded and the optional-parameter default appended where it belongs. Every clause carries information.

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, but the description enumerates the returned fields, which covers the main return-value need. For a two-parameter calculator with 100% schema coverage this is nearly sufficient; only edge-case behavior (invalid dates, future birth dates, negative results) 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, and the description genuinely adds meaning by documenting that asOf defaults to today — a default the schema itself does not declare. It does not add further syntax detail beyond the schema's '{year,month,day} or text' examples, so it earns a modest bump above baseline rather than a top score.

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 age) and resource (Jalali birth date), and enumerates the output units (years, months, days, total days), so the agent knows exactly what it gets back. It is distinguishable from the broader date arithmetic siblings, but it never names jalali_diff, which could also be used for age-like math, so differentiation is implicit rather than explicit.

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 note that 'asOf defaults to today' implies the intended usage (age as of now, or as of an arbitrary date), which is useful. However, there is no explicit when-to-use vs alternatives guidance and no mention of exclusions or error conditions (e.g. a birth date in the future, or an invalid Jalali date).

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

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

No annotations, so the description carries the full behavioral burden. It does disclose that the result includes both a numeric day count and a Persian relative description, which is useful, but it says nothing about sign/ordering (what happens if 'to' precedes 'from'), error behavior, or calendar edge cases.

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 core operation and followed by the output detail. Nothing wasted and nothing buried.

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 two-argument nested-object tool with no annotations and no output schema, the definition covers the operation but omits ordering/negative-difference semantics, input format expectations (Jalali year/month/day as separate integers is only inferable from the schema), and any error conditions.

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% and both parameters are nested year/month/day objects with only numeric ranges. The description implies the two dates via 'between two Jalali dates' but never clarifies the from/to direction semantics, leaving a real gap the schema does not fill.

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 computation (day difference) over a specific resource (Jalali dates) and even hints at the output shape (a Persian relative description). It is clearly distinct from sibling jalali_add or format_jalali_date, though it doesn't name those siblings 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?

No explicit when-to-use, when-not-to-use, or named alternatives. For a simple, self-evident utility the usage is strongly implied by the purpose, but an agent gets no guidance on choosing it over jalali_add or format_jalali_date.

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

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

With no annotations, the description carries the full burden and does disclose output shape (weeks of 7 cells, day number, Gregorian date, Friday flag, null padding) and a default (weekStart = Saturday). It does not cover error/validation behavior for out-of-range year or month, which is a notable gap for a zero-annotation 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?

A single dense sentence, front-loaded with the artifact and audience, then the cell structure, then the default. No filler and no repetition of the 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?

Because there is no output schema, the description must describe return values, and it does so well enough for a caller to consume the grid. It falls short only on parameter semantics for year/month and on error behavior, which no other structured field supplies.

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 documents the weekStart default ('Saturday'), which is genuinely useful, but says nothing about year/month ranges, calendar system, or the enum values' full set, leaving two required parameters essentially unspecified.

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 output artifact ('calendar grid for a Jalali month') plus its intended consumer ('for date-pickers'), which cleanly separates it from siblings like format_jalali_date, jalali_period_range or gregorian_to_jalali. The description of the returned structure (weeks of 7 cells) makes the resource unambiguous.

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 parenthetical 'for date-pickers' gives a clear use context, and 'Default week starts Saturday' signals the configurable case. However, there is no explicit when-not guidance or named alternative among the many jalali_* siblings, so the agent must infer the boundary.

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

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

With no annotations, the description carries the behavioral burden and does disclose the meaningful output shape (start and end, in both Jalali and Gregorian) plus the non-obvious week convention (Saturday-Friday). It stops short of stating that this is a pure computation with no side effects or how invalid dates are handled, which leaves a small gap for an unannotated 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?

Two tightly packed sentences, front-loaded with the returned value and followed by the routing advice. Every clause adds information; nothing is redundant.

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 and no annotations, the description covers the return shape and period semantics reasonably well, but it leaves the input-date calendar ambiguous and says nothing about behavior on malformed dates. For a nested-object, zero-coverage schema, more specificity is needed.

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% and the date parameter is a nested object, so the description must compensate. It usefully expands the period enum (week defined as Saturday-Friday, quarter as season), but it never clarifies whether the input date is Jalali or Gregorian, which is the single most important semantic for this tool. Partial compensation only.

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 precise verb and resource ('Start/end ... of the Jalali day, week, month, quarter or year containing a date') and names the output calendars (Jalali and Gregorian). It is clearly distinguishable from siblings such as jalali_month_grid, jalali_year_info, and format_jalali_date, which do not return period boundaries.

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 usage directive ('Use for reports and finance periods instead of Gregorian date libraries'), which names the alternative approach to avoid. It does not, however, contrast against sibling tools that also deal with Jalali dates, so the routing guidance is contextual rather than exhaustive.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it is nearly silent. It does not disclose the return shape (string vs. {year,month,day}), how invalid or out-of-range dates are handled, or leap-year behavior — all things an agent needs for a pure-function conversion.

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?

A single efficient, front-loaded sentence with no wasted words. It is concise to the point of being slightly under-specified, but nothing is redundant.

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 annotations, no output schema, and 0% parameter descriptions, the description is too thin for a 3-required-parameter conversion tool. Return format, validation behavior, and month convention are all left unstated.

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 0% and the description says only 'a Jalali date', leaving all three parameters undocumented. It never clarifies month indexing (1-12 vs 0-11), accepted year range, or whether the values are Jalali rather than Gregorian, so it fails to compensate for the coverage 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 (Convert) and resource (Jalali/Persian date) with a clearly named target (Gregorian calendar). The purpose is unambiguous and the name makes the inverse of sibling gregorian_to_jalali obvious, though the description itself never acknowledges siblings.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as gregorian_to_jalali or jalali_year_info. The agent must infer applicability purely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a pure read-only computation with no side effects, but never explicitly states that, nor whether the year must be a Jalali year and how leap status is reported.

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?

A single front-loaded sentence with no filler. Efficient, though its brevity contributes to the gaps elsewhere.

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, so the description usefully names the two return values (leap status, month length). However, with two undocumented parameters at 0% schema coverage and no usage context, an agent still lacks enough to call it confidently.

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 0% for both parameters, so the description must compensate and largely does not. 'month length' hints that the optional month parameter selects a specific month, but it never clarifies that year is a Jalali year, that month is optional, or what the accepted ranges/format are.

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 resource (a Jalali year) and what the tool returns (leap-year status, month length). This vocabulary clearly separates it from the date-arithmetic siblings (jalali_add, jalali_diff) and formatters, though it never names an alternative.

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?

No when-to-use guidance, no prerequisites, and no mention of when a sibling such as format_jalali_date or jalali_diff would be preferred. The agent must infer the use case purely from the resource name.

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

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

No annotations exist, so the description carries the full behavioral burden and it does not deliver. It never states that the operation is a pure read-only lookup, nor does it define the accepted input shape (full number vs. bare area code, leading zero, Persian vs. ASCII digits) or what happens on an unrecognized prefix.

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 verb and resource, and the qualifying mechanism ('from its area code') lands immediately after. 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?

There is no output schema, so the description should disclose the return value, yet it never says whether the province comes back as a Persian name, an English name, or a code, nor what an invalid or unassigned area code yields. For a lookup tool with a 0%-documented parameter, too much is left unstated.

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% and the single parameter is named only 'value', which is uninformative. The description hints the input relates to an area code but leaves it genuinely ambiguous whether the caller should pass a full landline number or just the area code, an ambiguity the agent cannot resolve from 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 and resource ('Find the province of an Iranian landline number') plus the mechanism ('from its area code'), which is enough to separate it from neighbors like mobile_operator and bank_from_card. It does not explicitly name a sibling, 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?

No when-to-use, when-not-to-use, or alternative is given. The agent must infer from the tool name alone that this is the landline counterpart to mobile_operator; nothing in the description routes it there.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state the accepted input formats (local 09xx vs +989xx), what happens with invalid or non-Iranian numbers, or whether the result is an operator name versus a code — all things an agent would need to call it safely.

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?

A single tight sentence with the verb, resource, and enumerated outputs front-loaded. There is no wasted text.

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 simple one-parameter lookup with no output schema and no annotations, the description covers the core intent but omits the input format and the return shape. An agent can guess, but the definition is only minimally sufficient.

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?

Only one parameter ('value') with 0% schema description coverage, so the description must compensate. It identifies the parameter as an Iranian mobile number, which adds real meaning over the bare 'value' key, but gives no format, prefix, or length constraints.

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 gives a specific verb ('Detect') and resource ('mobile operator') and even enumerates the possible outputs (MCI/Irancell/Rightel) on an Iranian mobile number. It is clear on its own, but it never distinguishes itself from the close sibling normalize_mobile, which also operates on mobile numbers.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The agent must infer that this is the tool for operator lookup rather than mobile normalization, which is the adjacent sibling.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the output format but says nothing about accepted input shapes (+989..., 00989..., Persian digits), what happens when validation fails (error vs. null vs. passthrough), or whether a leading-zero-prefixed number is required. For a validation tool, the failure semantics are the most important missing piece.

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?

A single front-loaded sentence that names the action, the resource, the locale and the output contract. Nothing is wasted.

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?

The tool is simple (one required string param, no nested objects), but with no annotations and no output schema the description is the only source of contract information, and it omits input format tolerance and invalid-input behavior. Adequate but with clear gaps.

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% and the single parameter is generically named 'value'. The description implies the parameter is a mobile number but gives no accepted formats or examples, so the agent still has to guess what strings will be accepted.

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 pair (validate and normalize) plus the resource (Iranian mobile number) and even the target output format (09xxxxxxxxx), so the agent knows exactly what comes back. It stops short of naming how it differs from siblings like mobile_operator or normalize_persian_text, but the purpose itself is unambiguous.

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?

No when-to-use or when-not-to-use guidance, no prerequisites, and no routing to alternatives such as mobile_operator (which presumably extracts operator info rather than canonicalizing the number). The agent must infer that this is the canonicalization step before storing or comparing numbers.

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

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

With no annotations, the description carries the full burden, and it does disclose the three transformations it applies, which is meaningful behavioral content. However, it says nothing about how ambiguous cases are treated (ZWNJ/zero-width non-joiner handling, which Arabic variants map to which Persian letters), whether the operation is idempotent, or what the returned value looks like.

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?

A single front-loaded sentence with no filler and no redundancy. It is efficient, though the terseness is partly what leaves the usage and behavioral gaps unaddressed.

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 string-to-string transformation with no output schema or annotations, the description covers the core 'what' adequately. It falls short on the 'when' relative to its many siblings and on any statement of the return value, which is the only thing an agent still has to guess.

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% and the single 'text' parameter has no description in the schema. The description implies the input is Persian/Arabic text to be normalized, which is trivially inferable from the tool name, but it adds no detail about expected encoding, length, or whether mixed scripts are accepted.

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 verb (normalize) and enumerates three concrete transformations: Arabic letter variant mapping to Persian, spacing cleanup, and digit conversion to Persian. That is unambiguous about what the tool does. It loses a point because it never distinguishes itself from siblings like sanitize_persian_text or slugify_persian, which an agent could easily confuse with it.

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?

There is no statement of when to reach for this tool versus sanitize_persian_text, slugify_persian, or to_persian_digits. Given that at least three siblings operate on Persian text and one overlaps on digit conversion, the absence of any routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full burden. It states a 'non-negative integer' constraint and the output language, but the schema explicitly allows negative values (minimum -9007199254740991), so the stated constraint conflicts with the actual input domain. No edge-case, error, or output-format behavior is disclosed.

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?

A single tight sentence that front-loads the operation and appends a brief use-case hint. Nothing is padded, though the example clause adds little beyond flavor.

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 converter with no output schema, the description covers the basics, but the negative-number mismatch with the schema is a real correctness gap and there is no guidance on which sibling converter to use. It is minimally adequate rather than 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 0% and the single parameter is named only "value" with no description. The description adds the intended type (integer) but contradicts the schema's actual range by claiming non-negativity, so it does not reliably compensate for the coverage 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+resource: converting an integer into Persian words, with a concrete example use case (invoices). It is clear what the tool does, but it does not differentiate itself from the close sibling price_to_persian_words, which targets the same invoice domain.

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?

"e.g. for invoices" implies a usage context but gives no explicit when-to-use versus when-not, and never mentions the obvious alternative price_to_persian_words. The guidance is only implied, leaving the agent to infer which converter to pick.

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

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

No annotations are provided, so the description carries the full disclosure burden. It conveys the core transform and implies a pure, side-effect-free operation, but says nothing about the return type (numeric string vs number), decimal-separator handling (Persian ٫ vs thousands ٬), negative signs, or behavior on non-numeric input.

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?

A single sentence with the transform front-loaded and an inline example that does the work of several explanatory sentences. No 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?

For a one-parameter, annotation-free utility with no output schema, the description covers what it does and gives an input example. It omits the return type and error/edge-case behavior, which an agent would need to know to chain this into a calculation pipeline.

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 single 'text' parameter has 0% schema description coverage, so the description must compensate. The example does show the expected input shape ('۲۰۰٬۰۰۰'), which is genuinely useful, but it does not state whether mixed Latin/Persian digits, whitespace, decimals, or stray characters are accepted.

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 ('Strip') and resource (separators and Persian/Arabic digits) with a concrete worked example, so the transform is unmistakable. It does not name the siblings it is distinguished from (to_persian_digits, persian_words_to_number, format_number_grouped), so an agent must infer the boundary from the example rather than from explicit routing.

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 by the example: use this when you have a separated digit string that needs normalizing. There is no explicit when-to-use, no mention of the inverse tool (format_number_grouped) or of the words-vs-digits alternative (persian_words_to_number), leaving the agent to reason about selection.

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

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

With no annotations, the description carries the full disclosure burden. It does add real behavioral context: extraction is 'heuristic' (results may be approximate) and city extraction is limited to 'province capitals only' — a meaningful scope constraint. However, it says nothing about failure modes, partial results, or error handling when no address pattern matches.

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, zero waste, and the essential qualifiers ('heuristically', 'province capitals only') are placed inline where they matter. Nothing could be cut without losing information.

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 effectively enumerates the return fields, which is the key missing piece. It stops short of describing the output structure or behavior on unparseable input, but for a single-parameter read-only parser it is nearly sufficient.

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 single 'text' parameter is undocumented structurally. The description implies the input is a Persian address string, which aligns with the parameter, but adds no format, length, or encoding detail (the 2000-char limit is invisible). Minimal compensation for the coverage 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?

The description gives a specific verb ('extract') and resource ('Persian address string') and enumerates exactly which fields are pulled out (province, city, postal code, plaque/unit/floor). It is distinguishable from validation siblings like validate_postal_code or landline_province, though it never names those alternatives 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?

There is no guidance on when to use this parser versus the many sibling validators (validate_postal_code, landline_province, iran_provinces). The word 'heuristically' hints at approximate behavior but no condition or exclusion tells the agent when this tool is the right choice.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not say what the returned 'Jalali date' looks like (object, ISO string, epoch), nor how unparseable or ambiguous input is handled. It discloses accepted input shapes but nothing about output or failure 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?

A single front-loaded sentence whose examples all earn their place by disambiguating input formats. Zero 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?

For a one-parameter parser with no annotations and no output schema, the description covers input well but leaves the return value unspecified, which is the main thing an agent needs beyond the schema. Adequate but with a clear gap.

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 0%, so the description must compensate, and it does: the three examples show the accepted textual formats, including Persian digits and a Persian-month form, which meaningfully defines the 'text' parameter. It does not mention whether whitespace, time components, or other separators are tolerated.

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 (parse) and resource (text into a Jalali date), with three concrete input examples that make the direction of conversion unmistakable. It does not explicitly name a sibling such as format_jalali_date to contrast the opposite direction, so it falls just 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?

No when-to-use statement, prerequisites, or alternatives are given. The examples imply the tool is for turning user-entered Jalali text into a structured date, so usage is inferable but never stated.

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

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

With no annotations, the description carries the full burden, and it does disclose the output shape (import link, font stack, RTL base styles) and a real limitation (IRANSans has no CDN link). However, it says nothing about whether the result is a pure/read-only snippet, whether it is static or generated, or how the selector influences the emitted CSS.

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 sentence that front-loads the resource and then the output contents. Every clause carries information; the only minor cost is the parenthetical font list, which is slightly redundant with the schema enum.

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 two-parameter, no-annotation, no-output-schema snippet tool, the description explains output contents adequately but leaves the `selector` parameter and any default behavior unexplained. It is the minimum viable level rather than 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 0%. The description lists the four font values, partially compensating for the `font` enum, but the `selector` parameter is never mentioned anywhere — neither in the schema nor the description — leaving its meaning and default entirely unknown. Half the parameters are undocumented.

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 resource (CSS preset for Persian fonts) and enumerates exactly what the output contains: import link, font stack with fallbacks, RTL base styles. It also lists the supported fonts, matching the enum. It stops short of explicitly distinguishing itself from near-neighbors like rtl_starter_snippet or rtl_guidelines, so it is clear but not fully disambiguated.

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?

There is no statement of when to use this tool versus rtl_guidelines, rtl_starter_snippet, or rtl_audit_css. The only caveat given (IRANSans is commercial, so no CDN link) is a behavioral note, not usage guidance. The agent must infer the use case from the tool name alone.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a meaningful trait — that variant characters, diacritics, ZWNJ and digit styles are treated as equal, i.e. matching is deliberately lenient — and hints at output ordering (ranked with scores). It omits error behavior, defaults, and any performance constraints for the 5000-item candidate 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?

Two tight sentences: the matching semantics and normalization rules come first, the return shape second. No filler, no restatement of the tool name, and every clause carries information.

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?

The core semantic contract (what counts as a match, what comes back) is covered, but for a 4-parameter tool with 0% schema coverage and no output schema or annotations, the description should at minimum explain threshold/limit semantics and the score range. Adequate but with a clear documentation gap on the tuning parameters.

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, but it only obliquely covers 'query' and 'candidates'. It says nothing about 'threshold' (the 0–1 match cutoff) or 'limit' (max results returned), which are the two parameters most likely to be misused.

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 ('Fuzzy-match a query against candidate strings') plus the exact normalization scope (Arabic/Persian letter variants, diacritics, ZWNJ, digit styles) and the return shape (ranked matches with scores). This is clearly distinguishable from siblings like normalize_persian_text, which transform a single text rather than rank a candidate list.

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 use case is implied by the phrasing 'query against candidate strings', so an agent can infer this is for matching/searching rather than normalizing. However, there is no explicit when-to-use guidance, no statement about when to prefer normalize_persian_text, and no mention of prerequisites or limits on candidate size.

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

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

With no annotations and no output schema, the description carries the full burden. It does disclose key traits: deterministic output, seed-driven, and an original word list rather than quoted real prose. It does not state the return format (a plain text blob per paragraph), whether seeds default when omitted, or that generation is side-effect free.

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?

A single tightly written sentence with the core identity and the determinism caveat front-loaded. Nothing is wasted and nothing is padded.

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 4-parameter generator with no annotations and no output schema, the description covers purpose and determinism but leaves output shape and three parameter meanings entirely to inference. Adequate for a low-risk snippet generator, but not 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 0% across 4 parameters, so the description must compensate. It explains the seed concept ('seeded') but says nothing about paragraphs, wordsPerSentence, or sentencesPerParagraph; those names are largely self-explanatory, which limits the damage.

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 resource (Persian placeholder text) with a clear use case (mockups), and the parenthetical clarifies what it is not ('not real prose'). It is unambiguous, though it never uses an explicit verb like 'generate' and has no sibling to be differentiated from since no other lorem tool exists.

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?

'for mockups' implies the intended context, which is the only realistic use case for a placeholder generator. However, there is no explicit when-to-use/when-not-to-use framing and no mention of alternatives (e.g. rtl_starter_snippet, which also supplies sample Persian content).

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

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

No annotations, so the description carries the full burden. It does disclose one behavioral quirk – 1 yielding اول plus the firstAsYekom switch for یکم – but says nothing about out-of-range inputs, non-integers, or the 0/999999999 bounds the schema allows.

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?

A single tight sentence with the core mapping front-loaded and the edge-case switch appended. No padding, though the parenthetical could be clearer about what firstAsYekom actually defaults to.

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 two-parameter no-output utility the coverage is nearly adequate, but with zero annotation and zero schema-description support the terse note on firstAsYekom leaves the agent guessing about ranges and defaults.

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 0%, so both parameters rely on the description. It explains firstAsYekom's effect by example ('set firstAsYekom for یکم') and the value parameter is evident from the mappings, but neither is given explicit semantics or default behavior.

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 the specific resource and operation ('Persian ordinal words') and illustrates with concrete mappings (3 -> سوم, 21 -> بیست و یکم), so an agent immediately knows it converts integers to Persian ordinals. It stops short of naming the cardinal sibling (number_to_persian_words) it must not be confused with.

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?

No statement of when to use this versus cardinal-conversion siblings, nor any prerequisite or exclusion. The examples imply ordinal context but leave the agent to infer that this is the ordinal-only variant.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals the approximation conventions ('Months = 30 days, years = 365 days') and that 'now' defaults to the current time, which are genuine behavioral traits beyond the schema. However it says nothing about output format details, invalid-input handling, or the effect of persianDigits on the result.

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 short sentences, each earning its place: the first frames the output with examples, the second specifies input and a default, the third pins down the time approximations. Front-loaded and free of 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?

For a low-complexity formatting function with no output schema, the description covers the core contract and the non-obvious month/year conventions. It remains incomplete on the persianDigits parameter and does not state the return shape beyond examples, so an agent still guesses on one input.

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 for three bare parameters. It explains timestamp (ISO) and now (defaults to current time) well, but persianDigits is never mentioned, leaving one of three parameters undocumented in both schema and description.

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 the resource (Persian relative time) and supplies concrete output examples ('۳ روز پیش', '۲ ساعت دیگر'), so an agent can immediately see what the tool produces. It stops short of differentiating itself from close siblings like jalali_age or jalali_diff, which also transform timestamps into human-readable temporal output.

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 implied by the examples and the instruction to 'Pass an ISO timestamp', which tells the agent the input shape. There is no explicit when-to-use or when-not-to-use guidance, and no sibling (e.g. jalali_age, jalali_diff) is named as an alternative, leaving the routing decision to inference.

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

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

With no annotations, the description carries the behavioral burden and does add real value: it discloses the ordering tier (digits → Persian → Latin) and that ZWNJ and Arabic/Persian letter variants are ignored. It stops short of noting case handling for Latin strings, the 10000-item cap, or error behavior on non-string input.

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, front-loaded with the core purpose and followed by the ordering rules. No filler or repetition; every sentence conveys actionable information.

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 two-parameter tool with no output schema and no annotations, the description covers the collation semantics well but omits the sort-direction default, the item-count limit, and any error/edge-case behavior. Adequate but with clear gaps an agent would want filled.

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, but it only implies the input is strings and never explains the 'order' (asc/desc) parameter or its default direction. The collation rules describe tool behavior rather than the parameters, leaving the sort-direction parameter undocumented anywhere.

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 (sort) and resource (strings in Persian alphabetical order), even sketching the collation sequence. It is clearly distinct from the sibling set, though it never explicitly names a sibling it should not be confused with (e.g. normalize_persian_text or persian_fuzzy_search).

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 implied by the collation description but there is no explicit when-to-use/when-not guidance or mention of alternatives. An agent can infer the tool sorts string arrays, but nothing tells it when another sibling (fuzzy search, normalization) would be a better fit.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return payload (the list of counts plus reading time) and the fact that reading time rests on an adjustable 180 wpm assumption, which is genuinely useful. It says nothing about input size limits, mixed-script handling, or accuracy caveats beyond that.

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 tight sentences, no filler, with the core purpose front-loaded and the parameter nuance relegated to the second sentence. Every clause earns its place.

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 and no annotations, the description does the work of enumerating outputs and explaining the configurable parameter, which covers what an agent needs to call it. It omits input size constraints and any notes on how mixed Persian/Latin text affects the counts.

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 fully documents wordsPerMinute as an adjustable assumption with a default of 180 — information absent from the schema, which specifies only numeric bounds. The remaining parameter, text, is self-evident from the purpose statement, so only a minor gap remains.

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 the exact resource (Persian/mixed text) and enumerates the specific metrics returned (character, letter, digit, ZWNJ, word, sentence, paragraph counts, reading time), so an agent knows precisely what the tool produces. It does not explicitly distinguish itself from measurement-adjacent siblings such as truncate_persian_text or normalize_persian_text, which keeps it 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The only implicit guidance is that it is an analysis/counting operation, which the agent must infer from the metric list.

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

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

No annotations are provided, so the description must disclose behavioral traits. It gives only the basic conversion and an example, without covering error handling, supported formats (e.g., fractions, negative numbers), or whether the operation is pure. The disclosure is minimal.

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 description plus a compact example. Front-loaded and every element earns its place.

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 simple converter with no output schema, the description explains input and output via the example, but lacks error behavior and edge-case handling. It is adequate but incomplete.

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 0% and the single 'text' parameter has no schema description. The description adds meaning by identifying the expected input as 'Persian number words' and providing an example, but it does not specify constraints or edge-case syntax. Partial compensation warrants a 3.

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 ('Convert') and resource ('Persian number words to a number'), and the example disambiguates the direction from sibling number_to_persian_words. However, it does not explicitly name alternatives or differentiate from other parsing utilities like parse_grouped_number.

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?

No when-to-use guidance, prerequisites, or alternatives are provided. The description simply states the transformation, leaving the agent to infer applicability.

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

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

With no annotations, the description carries the full disclosure burden, and it does describe observable behaviors of the generated code (digit grouping while typing, caret preservation, aria-live Persian words, raw value submission). However, it says nothing about permission/rate concerns or the exact format/content of what is returned as code, so behavioral coverage is helpful but partial.

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 that front-load the deliverable and then enumerate its behaviors, with no filler. Slightly terse for the amount of behavior packed in, but every clause carries information.

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 no annotations, so the description must stand alone for a code-generating tool. It conveys the snippet's behavior well but omits what the response actually looks like (one file? multiple?) and the meaning of three of the four variants, leaving gaps an agent would have to guess at.

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%, and the single enum parameter has four values. The description clarifies only 'core' (returns shared helpers); react/vue/vanilla are left to be inferred from their names. It adds meaning for one of four variants, which is partial compensation for 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 names a specific deliverable: ready-to-use RTL-friendly price input code with defined behaviors (digit grouping, caret preservation, live Persian words, raw value submission). This is clearly distinct from number-formatting siblings like format_number_grouped or price_to_persian_words, but it never explicitly contrasts itself with the similar rtl_starter_snippet, so sibling differentiation is left to inference.

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 explains what the snippet does but never states when to reach for this tool versus the many adjacent helpers (format_number_grouped, price_to_persian_words, rtl_starter_snippet) that it appears to bundle. The only routing-style hint, 'variant core returns the shared helpers,' is more of a parameter note than genuine usage guidance.

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

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

With no annotations and no output schema, the description carries the full burden, but it does disclose a genuinely useful behavioral quirk: toman may carry one decimal digit where tenths represent rials. It says nothing about rounding of longer decimals, negative or zero handling, maximum magnitude, or error 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?

Two tight sentences with the core purpose front-loaded and an inline example doing the work of a mini spec. No filler, no repetition 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?

For a two-parameter pure formatter with no output schema, the example output plus the decimal rule cover the essentials. Gaps remain: behavior for more than one decimal digit, the rial unit path, and edge cases like zero or negative amounts.

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 partially does: the example shows the amount format and a valid unit value, and the decimal/rial rule clarifies amount semantics for fractional toman, but it never explains the rial option, string input expectations, or limits.

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 the specific transformation (amount -> Persian words with a currency unit) and anchors it with a concrete input/output example. It implicitly separates itself from the sibling number_to_persian_words via the 'with unit' framing and the toman example, though it never names that sibling 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?

There is no explicit when-to-use statement, no conditions, and no mention of alternatives such as number_to_persian_words or convert_rial_toman. The currency example implies the domain but leaves the agent to infer when this tool is the right choice.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the tool only detects and suggests (implying non-mutating behavior) and lists the covered pattern families, but it says nothing about return format, whether comments/strings are excluded, severity levels, or false-positive handling.

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?

A single front-loaded sentence: verb and input types come first, then the detection scope, then the action. The parenthetical pattern list is long but earns its place by concretely defining 'LTR-only patterns'. No filler or restatement 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?

With no output schema and no annotations, the description is the only source of behavior, and while it covers what is detected it never describes the shape of the result (findings list, line numbers, per-file grouping) or any limits on input size. For a one-parameter audit tool this is close to sufficient but leaves the agent guessing about the response.

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 single 'code' parameter has 0% schema description coverage, so the description must compensate. It partially does by clarifying that the parameter accepts CSS/HTML/JSX/Tailwind text, which is genuinely useful input-format guidance. It does not, however, say whether code is a file path, raw string, or snippet size limits, leaving real ambiguity.

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 opens with a precise verb+resource ('Scan CSS/HTML/JSX/Tailwind text') and enumerates the exact pattern classes it targets (margin-left, ml-4, text-align:left, float:left, forced ltr, directional icons). It also states the outcome ('suggest logical replacements'), so the agent knows it is an analysis tool rather than a mutator. It does not explicitly differentiate itself from the sibling rtl_convert_css, which is the main gap.

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 word 'suggest' implies a read-only audit step versus the mutating rtl_convert_css/rtl_convert_tailwind siblings, so usage can be inferred. However, there is no explicit when-to-use/when-not guidance, no statement of ordering (audit before convert), and no sibling named. Adequate but clearly improvable given three closely related RTL siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only that a conversion happens, without stating whether the tool is pure, whether it writes files or returns a string, what happens on invalid input, or any other execution 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?

The description is a single front-loaded sentence with no filler. It identifies the action, the input domain, and the output form efficiently.

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 no annotations, so the description should clarify return behavior, error handling, and usage context. Instead it omits these details, making the definition incomplete for an agent that needs to invoke the tool confidently beyond the basic purpose.

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%, with the single required parameter named css and typed only as a string. The description adds that physical CSS and React style objects are accepted, but it does not explain how React style objects should be supplied as a string or what format is expected, leaving a significant 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?

The description states a specific verb and resource: convert physical CSS to logical properties. It also names React style objects as an accepted input form, which distinguishes it from the sibling rtl_convert_tailwind and rtl_audit_css 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?

There is no guidance on when to use this tool versus alternatives such as rtl_convert_tailwind or rtl_audit_css. The purpose implies RTL conversion, but no explicit when-to-use, prerequisites, or exclusions are stated.

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

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

With no annotations and no output schema, the description carries the full behavioral burden. It discloses the direction of the mapping via examples but says nothing about what is returned, whether the operation is idempotent, whether it tolerates mixed class lists or unknown utilities, or how it fails on invalid input.

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 verb and resource, followed by three compact examples that do more work than prose would. Nothing is wasted or buried.

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 pure transformation the description is close to sufficient, but gaps remain: the input format for 'text' is only implied and the return value is never described despite there being no output schema. It is adequate to attempt a call but not to predict the result.

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?

There is a single required parameter 'text' with 0% schema description coverage, so the schema offers no meaning at all. The description's examples imply the parameter is a set of Tailwind utility classes, but it never states whether the input is a class string, a full HTML fragment, or file contents.

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 verb (Convert) and resource (Tailwind physical utilities to logical ones) and backs it with three concrete before/after examples, so the transformation is unambiguous. It stops short of explicitly differentiating itself from the sibling rtl_convert_css, but the Tailwind-specific examples make the boundary inferable.

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?

There is no statement of when to reach for this tool versus rtl_convert_css or rtl_audit_css, no prerequisites, and no note on what it does not handle (e.g. non-Tailwind CSS or arbitrary HTML). Usage is only implied by the examples, and a sibling with a near-identical name exists, so routing guidance is genuinely missing.

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

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

No annotations and no parameters, so the behavioral burden is light and the description says enough to know it is a reference lookup. It does not disclose the size, format, or structure of the returned guidelines, which matters for a 'Full guidelines' payload.

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?

Single sentence, front-loaded with what is returned, and the parenthetical adds the alternative-access detail without padding. Slightly dense but every clause earns its place.

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 zero-argument reference tool with no annotations and no output schema, the description identifies content and audience completely. Only the return payload's shape and volume are unspecified, a minor gap.

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?

Zero parameters with 100% schema coverage, so there is nothing for the description to compensate for. Baseline for a no-param tool 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 resource and its scope: full RTL frontend guidelines for Persian/Arabic UIs. That distinguishes it from sibling converters/auditors (rtl_convert_css, rtl_audit_css), though the verb is implicit rather than front-loaded.

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 — an agent infers 'use this when you need the guidelines.' The parenthetical points to an alternative access modality (prompt and resource), which is mild routing help, but there is no statement of when to prefer this over the rtl_* conversion/audit siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It notes the setup is 'minimal' but does not disclose what is actually returned (code block, multiple files, boilerplate?), whether it is read-only, or whether output depends on anything beyond the framework value.

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 short sentence, well front-loaded, with no filler. The framework enumeration is mild redundancy against the schema enum, but it reads as a fast reference rather than padding.

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 tool this is nearly adequate: the agent knows the input space and roughly what it gets. The remaining gap is the return artifact — a snippet generator should indicate what form the output takes, especially with no output schema present.

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 0% for the single required parameter, so the description must compensate — but it merely restates the enum values already listed in the schema. It adds no meaning about what selecting a given framework produces or how the values differ.

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 the concrete deliverable (a minimal RTL-ready starter setup) and enumerates the target frameworks, which distinguishes it from the audit/convert siblings. The verb is implicit — it never says 'generate' or 'return a snippet' — so the action is inferred from the tool name rather than stated.

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?

No when-to-use guidance, no prerequisite, and no alternative named. With siblings like rtl_guidelines, rtl_audit_css, rtl_convert_css and rtl_convert_tailwind in the same space, the description never explains when a starter snippet is the right pick over those.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose the specific normalizations performed, which is genuine behavioral content. It says nothing, however, about return semantics, idempotency, or whether unspecified content is preserved. Adequate but incomplete for an annotation-free 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?

A single compact sentence that front-loads the primary case (ZWNJ/half-space) before secondary fixes. No filler. The dense domain jargon is appropriate for the audience and costs little.

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 text-transformation tool with no annotations and no output schema, the description should clarify the return value and the relationship to the near-identical normalize_persian_text sibling. Neither is present, so an agent lacks enough to choose confidently.

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, and it does not explicitly describe the input. Still, the single parameter "text" is self-evident given the tool's purpose, so meaning is not lost. Baseline-adequate rather than additive.

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 ("Fix") and the exact resource it operates on: ZWNJ/half-space, می/نمی prefixes, plural suffixes, Persian punctuation and spacing, and Arabic letter variants. This is concrete and actionable. However, it never distinguishes itself from the sibling normalize_persian_text, which shares a nearly identical purpose, leaving ambiguity about which tool to pick.

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?

There is no indication of when to use this tool versus normalize_persian_text or slugify_persian, both of which operate on Persian text as well. No prerequisites, ordering, or exclusions are given. The agent must infer selection purely from the name and the transformation list.

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

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

No annotations are provided, so the description carries the full burden. It does not say whether Persian characters are transliterated, stripped, or percent-encoded, what separator defaults to, or whether the operation is a pure transformation - all relevant behavioral facts for a slug 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?

A single short sentence with the verb and resource front-loaded and no filler. It is efficient, though the economy borders on under-specification.

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, no annotations and 0% parameter documentation, the description should explain the separator behavior and output shape but does not. An agent can invoke it, but cannot predict the result.

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 hints at the 'text' parameter's accepted scripts but says nothing about the 'separator' parameter or the default separator, leaving one of two params completely undocumented.

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 ('Create') and resource ('URL slug') with the input scope (Persian/Latin text). However it does not differentiate itself from close siblings such as sanitize_persian_text or normalize_persian_text, leaving the agent to guess which transformation applies.

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?

There is no when-to-use guidance, no prerequisites and no mention of alternative tools. For a family of text-normalization siblings, this absence is notable.

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

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

With no annotations, the description carries the full burden. 'Any digits' hints that all digit runs in the string are converted, but it does not state whether Arabic-Indic or already-Persian digits are handled, what happens to non-digit characters, or whether the operation is idempotent. For a pure transformer the safety profile is inferable, but the behavioral details are largely missing.

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?

A single front-loaded sentence with no filler. It is appropriately sized, though it is so terse that it leaves nothing to structure beyond the core statement.

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 trivial single-parameter transformer with no output schema, one sentence is close to sufficient, and the return value is self-evident. However, the 0% parameter coverage and the crowded sibling namespace mean the description leaves the agent guessing about scope and edge cases.

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 schema documents only that 'text' is a required string. The description implies the input may contain mixed text and digits but adds no format, length, or encoding details to compensate for the coverage 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?

The description gives a specific verb and transformation: convert digits in a string to Persian digits. It is clear and unambiguous on its own, but it never differentiates itself from adjacent siblings like number_to_persian_words or price_to_persian_words, which the agent must distinguish by name alone.

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?

There is no guidance on when to use this versus the many sibling conversion tools, no mention of input expectations, and no note about alternatives for whole-number or currency conversion. The agent must infer the use case entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that the ellipsis counts toward maxLength, that word boundaries, ZWNJ sequences, surrogate pairs and diacritics are never split, and that the default mode is 'word'. It omits any statement about the return value or behavior when the text is already shorter than maxLength.

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 with no filler, and the preservation guarantees plus the mode default are front-loaded. Density is high, though the parenthetical and the trailing mode clause make the second half slightly list-like rather than immediately scannable.

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 no-annotation, no-output-schema, 0%-coverage four-parameter tool, the description covers the core contract but leaves the ellipsis parameter undefined and never states the return type. It is adequate to call the tool in the common case but not complete for all parameters.

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 for four undocumented parameters. It explains maxLength's ellipsis-inclusive semantics and the mode enum default, but says nothing about the 'ellipsis' parameter (a custom string up to 10 chars) or what 'text' accepts, leaving half the surface ambiguous.

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 ('truncate text to maxLength') and even names the special cases it preserves (ZWNJ-joined words, surrogate pairs, diacritics), which quickly signals a Persian-aware utility. It does not, however, differentiate itself from adjacent text-manipulation siblings like sanitize_persian_text or normalize_persian_text.

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 only usage-like information is that 'word' is the default mode and 'char' is the alternative, which is parameter guidance rather than when-to-use guidance. There is no statement of when truncation is appropriate versus normalizing or sanitizing, and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the Luhn checksum method and the 16-digit Iranian format, which are useful behavioral details, but says nothing about return values, error behavior, or input normalization. That leaves meaningful gaps for an agent invoking it.

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?

A single front-loaded sentence with no filler. Every element (verb, format, algorithm) helps the agent and there is 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?

For a simple validation tool with no annotations and no output schema, the description covers purpose, format, and algorithm. It omits what the tool returns (boolean, error message, etc.) and any prerequisite normalization, which would matter to an agent. Given the lack of structured output documentation, it is adequate but not 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 coverage is 0% and the only parameter is a bare string named 'value'. The description compensates by specifying the expected semantic: a 16-digit Iranian bank card number. However, it does not state accepted formats (e.g., spaces, Persian digits) or whether the Luhn check applies only to digits, so some ambiguity remains.

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 (Validate) and resource (16-digit Iranian bank card number), and adds the Luhn algorithm. This clearly separates it from siblings like validate_sheba or validate_national_id, which validate different identifiers. An agent can tell what the tool does 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?

No explicit when-to-use guidance or alternatives are provided. It does not clarify when to choose this tool versus bank_from_card or other validation tools. The use case is only implied by the name, so routing help is absent.

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

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

With no annotations provided, the description carries the full burden, and it does meaningful work: "Never throws" tells the agent to inspect a result rather than catch an exception, and leap-aware range checking plus min/max/notFuture disclosure describe the validation surface. It does not describe the shape of the "readable reasons" result, so the error contract remains unclear.

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?

A single dense sentence, front-loaded with the tool's function, then the checks, then the non-throwing guarantee. No filler or restated 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?

No output schema and no annotations exist, so the description is the only source of behavioral detail for a 4-parameter nested-object tool. It hints at "readable reasons" but never describes the return payload (valid flag, reason list, message format), which is the key information an agent needs to act on a failed validation.

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% and `notFuture` has no schema description, yet the description supplies its meaning (a not-future-date check) along with min/max bounds and leap-aware range semantics. It does not clarify that min/max accept either {year,month,day} or '1405/07/24' text, but that is already covered by 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 (validation) and resource (Jalali date) and enumerates the checks performed (month/day ranges, min, max, notFuture), which separates it from siblings like parse_jalali_date or jalali_age. It never explicitly names or contrasts with those siblings, 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?

"Form validation" implies the intake-validation use case but there is no when/when-not guidance and no pointer to alternatives such as parse_jalali_date (parsing) or format_jalali_date (output). The agent must infer from the sibling list when to reach for this validator.

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

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

With no annotations, the description carries the full behavioral burden. It adds the useful constraint that the input is 11 digits and checksum-verified, but says nothing about what a validation result looks like, whether Persian digits or separators are tolerated, or how whitespace is handled.

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 verb and the exact identifier, with no padding. Every element earns its place.

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 no annotations, so the description should cover the return contract (boolean vs error payload) and the digit/normalization rules. Neither is present, leaving a simple but under-specified tool for an agent to call blindly.

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 0% and the single 'value' property has no description, but the description partially compensates by defining the expected input as an 11-digit legal-entity ID. It still omits accepted character set (Persian vs Latin digits), separators, and normalization behavior.

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?

Specific verb (validate) + resource (11-digit Iranian legal-entity national ID), with the Persian term and English gloss clarifying the exact identifier type. The 'legal-entity' qualifier implicitly separates it from the sibling validate_national_id, but the sibling is never named, so differentiation is left partly to inference.

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 implied: an agent can guess this applies to company/legal-entity IDs rather than personal national IDs. There is no explicit statement of when to prefer this over validate_national_id, nor any note on prerequisites or failure handling.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that validation is checksum-based, which is useful, but says nothing about the return shape (boolean vs. error detail), accepted input format, or whether any normalization (e.g. Persian digits) happens first.

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?

A single front-loaded sentence with no filler; every clause (verb, resource, method) earns its place.

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 annotations and no output schema, the description should explain what a successful/failed validation returns and what input formats are accepted. Neither is covered, leaving the agent unable to predict the response or the expected argument format.

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% and the single parameter is documented only as an untyped-in-meaning string. The description does clarify that this parameter is the national ID code, adding real meaning, but it omits format constraints (digit count, Latin vs. Persian digits, hyphens).

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 verb (validate), a specific resource (Iranian national ID / code melli), and even the mechanism (checksum). This cleanly separates it from siblings like validate_card_number, validate_sheba, and validate_postal_code without ambiguity.

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?

There is no guidance on when to use this tool versus the other validators, nor any prerequisite or exclusion. The agent must infer from the name alone that this applies only to national IDs and not card or SHEBA numbers.

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

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

No annotations are provided, so the description carries the full behavioral burden and largely fails it. It does not say what 'validate' returns (boolean? message?), whether it throws or reports failure, or whether formatting variations are accepted. The only behavioral hint is the 10-digit length constraint.

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?

A single front-loaded sentence with no filler; every word ('validate', 'Iranian', '10-digit', 'postal code') constrains the operation. Appropriately sized for a one-parameter utility.

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 validator with no annotations, no output schema, and no parameter documentation, the description should at least state the result shape and accepted input format. It leaves the agent guessing at both, which is a material gap for a tool whose entire value is a pass/fail outcome.

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 0% and 'value' is a bare string, so the schema adds nothing. The description partially compensates by defining the expected payload as a 10-digit Iranian postal code, but it gives no detail on accepted formats, separators, or whether digits-only input is mandatory.

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 ('validate') and resource ('Iranian 10-digit postal code'), which is enough to separate it from siblings like validate_national_id or validate_sheba. It stops short of explicitly contrasting with those validators, so it is clear but not sibling-differentiating in prose.

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?

There is no when-to-use guidance, no mention of the other validators in the sibling family, and no stated preconditions (e.g. raw digits vs. spaces/dashes). The intended use is only implied by the tool name and the word 'validate'.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose what validation entails (checksum, length, IR prefix format), what the return value is (boolean vs. structured result), or whether it is a pure read operation.

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?

A single short sentence with the key facts front-loaded and no filler. It is efficient, though its brevity reflects under-specification rather than disciplined conciseness.

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 validation utility with no output schema, the description identifies the input domain but omits the expected input format and the nature of the result. Marginally adequate, but an agent still has to guess on formatting and return shape.

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 0% and the single parameter 'value' is undocumented in both schema and description. The description does not clarify whether the input should include the 'IR' country prefix, spaces, or checksum digits, which matters for correct invocation.

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 (Validate) and resource (Iranian Sheba/IBAN number), which is unambiguous on its own. It does not explicitly differentiate itself from the closely related sibling bank_from_sheba, which also takes a Sheba value, 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?

There is no guidance on when to use this tool versus siblings like validate_card_number, validate_national_id, or bank_from_sheba. The agent must infer the context from the name alone.

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