Irfan Aslam Tools

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value by listing what is returned (including the Hijri date, which is otherwise a surprise output), but it is silent on input validation failures, calendar-conversion assumptions, and the timezone used for 'today'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence that front-loads the outputs, with no filler. The appended marketing URL is the only element that does not help an agent invoke the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully tells the agent what fields to expect, which is important for a pure-computation tool. However, it omits edge-case behavior (invalid or future dates, leap days, which Hijri calendar variant) that an agent would need to interpret results reliably.

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

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

Schema coverage is 100%, with both parameters documented including the YYYY-MM-DD pattern and the default-today behavior of on_date. The description adds no syntax, formatting, or interpretation detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific computation and enumerates its outputs: exact age in years/months/days, total days, next birthday, and Hijri birth date. That is enough for an agent to separate it from siblings like hijri_gregorian_convert or experience_calculator, though it never explicitly contrasts with them.

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 or when-not-to-use guidance, and no mention of alternatives such as experience_calculator (which also derives an elapsed duration) or hijri_gregorian_convert (which also handles Hijri dates). The purpose implies the use case, but the description offers nothing beyond that implication.

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?

The annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description is not carrying that burden. It adds real behavioral value beyond them: it discloses that output is produced in both Arabic and English simultaneously and that it follows the cheque-form wording convention (فقط ... لا غير / ... only). It stops short of saying exactly what the response payload looks like or how the amount is validated against the stated ceiling.

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 core purpose is front-loaded in the first clause, with supporting detail (currencies, output convention, reference link) after it. The list of seven currencies is somewhat redundant with the enum and the external URL is marginal for an agent, keeping it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only tool this is nearly sufficient, and the mention of the cheque/invoice phrasing hints at the returned string. However, since no output schema exists, the description should say whether both language renderings are always returned and in what structure; that gap leaves an 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?

Schema description coverage is 100% and the amount format example (1235.50, up to 999,999,999,999) plus the SAR default are already in the schema. The description's currency list merely repeats the enum values. This meets the baseline 3 with no added meaning beyond structured fields.

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 transform ("write an amount in words") plus the exact output domain (Arabic tafqeet and English) and the real-world convention it reproduces (Saudi cheques/invoices, فقط ... لا غير / ... only). No sibling tool in the list does numeric-to-text conversion, and the name plus this sentence make the function unmistakable.

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 phrase "as on Saudi cheques and invoices" implies the usage context, which is genuinely helpful, but there is no explicit when-to-use/when-not statement, no prerequisite guidance, and no named alternative. With no near-sibling competitors, the cost of this gap is low, but it is still implied rather than stated 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?

The annotations already establish that this is a safe, read-only, idempotent calculation. The description adds useful behavioral context by naming the Saudi residential tariff structure (21/33 halalas plus VAT) and the option to use a custom rate, though it does not explain how the 21 vs 33 halala tier is selected.

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 dense sentence with the core calculation and tariff context front-loaded, followed by a reference URL. There is no redundant wording or unnecessary preamble.

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 read-only calculator with full schema coverage and safety annotations, the description gives enough context to call the tool correctly. It is slightly incomplete because it does not clarify whether the result is a per-appliance breakdown or an aggregate total, and it leaves tariff tier selection unexplained.

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

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

Schema coverage is 100%, so the input schema already documents appliances, watts, hours_per_day, quantity, days, and price_per_kwh. The description adds tariff context for the custom-rate option but does not add meaning beyond the schema for most parameters, and it does not explain the tariff tier logic.

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 clearly states that the tool computes monthly kWh and cost for appliances from watts, hours per day, and quantity, with Saudi residential tariff or a custom rate. It is specific about the resource and calculation, but it does not distinguish itself from the sibling saudi_electricity_bill, which could also handle electricity cost calculations.

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 intended use is implied by the appliance-level inputs and tariff context, but there is no explicit when-to-use guidance, no exclusions, and no mention of the closely related saudi_electricity_bill alternative. An agent must infer that this is for appliance-level estimates rather than whole-house bills.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the permit-to-work comparison intent, which is useful, but says nothing about what the check returns (pass/fail per gas, which limit was breached) or how partial data 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?

Two sentences, with the operational purpose front-loaded and the reference URL trailing. The URL is arguably promotional rather than functional, but it costs little and the core sentence is tight 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?

There is no output schema, so the description carries the burden of explaining the return value, and it does not — an agent cannot tell whether it gets a boolean, a per-gas verdict, or a list of exceeded limits. For a 5-parameter tool with a nested limits object, that is a meaningful gap even though the input side is well understood.

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 80% and the nested 'limits' object documents each default (o2_min 19.5, o2_max 23.5, lel_max 10, h2s_max 10, co_max 25), so the baseline is 3. The description only restates the four gas readings and the notion of permit limits; it adds no units guidance, no explanation of when to override defaults, and no note that 'limits' is entirely optional.

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 ('Check gas detector readings (O2, LEL, H2S, CO) against permit-to-work limits') and pins the domain to confined space entry. The purpose is unmistakable, though it never names or distinguishes itself from nearby safety siblings such as heat_stress, noise_exposure, or fire_extinguisher_selector.

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 a clear usage context: run it 'before confined space entry' as a pre-entry verification against permit-to-work limits. There are no explicit exclusions or named alternatives, but the trigger condition is concrete enough that an agent knows when to reach for it.

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?

The annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context about next-run listing and time-zone selection, but it does not disclose invalid-expression handling, macro behavior, or detailed return semantics.

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 short and front-loaded, with the core operation stated first. The web-version link is not useful for tool invocation and is minor wasted text, but overall it remains efficient.

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 three-parameter utility, the description covers the core input format, output type, and time-zone scope, while the schema carries parameter details and annotations carry safety semantics. It is nearly complete, though it could say more about invalid-input behavior.

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 parameters are already well documented, including defaults, ranges, and macro examples. The description restates the 5-field format and time-zone option but adds no count or validation semantics beyond the schema, making baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: check a 5-field cron expression and list its next run times. It also names the output and time-zone scope, so the agent can identify the operation 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?

Usage is implied by the description, since the tool is for checking a cron expression and listing next runs. However, it gives no explicit when-to-use guidance, exclusions, or comparison to alternatives, so it is only minimally adequate.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that data is live and covers 24-hour change, but says nothing about refresh cadence, data source, rate limits, or failure behavior for an open-world network tool, and there is no output schema to carry return 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 front-loaded sentence covers resource, assets, currencies and the 24-hour metric, followed by a web reference. The coin enumeration ("and more") is slightly padded but harmless; nothing is buried or repeated.

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 parameters and no output schema, the description carries the burden of saying what comes back, and it does: prices in SAR and USD with 24-hour change for a named coin set. Missing only freshness/refresh details and whether all listed coins are always returned, which are minor for a lookup 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly signals a no-input, call-and-read tool by not implying any filtering or configuration options.

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 (live cryptocurrency prices) with named assets and both quote currencies plus 24-hour change, which clearly separates it from gold_silver_prices_sar and sar_exchange_rates by subject matter. It never names a sibling explicitly, so the differentiation is inferred 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?

"Live prices" implies the tool should be used when current crypto quotes are wanted, which is adequate implied usage. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as gold_silver_prices_sar or sar_exchange_rates for other asset classes.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds one genuinely useful behavioral fact — results come from Cloudflare DoH, so they reflect that resolver's view and may be cached rather than authoritative. It says nothing about what is returned or how NXDOMAIN/no-record cases behave, which matters since there is no output schema.

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 core purpose is front-loaded in a single dense sentence with no filler. The trailing web-version URL is mildly promotional and does not help an agent invoke the tool, which is the only wasted element.

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, idempotent read tool with full schema coverage and rich annotations, the description covers what is needed to call it correctly. The one remaining gap is that, without an output schema, nothing is said about the shape of returned records or failure 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 100% and the record-type enum already lists every allowed value, so the description's type list restates the schema rather than adding to it. The domain format hint (no https:// or path) is already in the schema too, leaving no extra parameter meaning contributed.

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 and resource ("Look up DNS records ... for a domain") and enumerates the supported record types, so an agent knows exactly what the tool does. It does not explicitly differentiate itself from the closely related sibling dns_propagation, which keeps it below 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 explicit when-to-use or when-not-to-use guidance, and no mention of the obvious alternative, dns_propagation, which shares the same problem space. The mention of Cloudflare DNS over HTTPS faintly implies a single-resolver lookup rather than a propagation sweep, but that inference is left entirely to the agent.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral detail: exactly 10 resolvers, named providers (Google, Cloudflare, Quad9) plus country views, and that results are compared rather than merely listed. It does not describe the response shape (agreement summary vs per-resolver rows), which matters since there is no output schema.

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 purpose and the mechanism front-loaded, followed by a web reference. The link to the external web version is marginally useful as a visual cross-check but is not actionable information for an agent, so it is the one slightly expendable element.

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 read-only tool with full schema coverage and no output schema, the description covers purpose, method, and resolver scope adequately. The remaining gap is the return format and whether 'expected' produces a pass/fail verdict, which an agent would need to interpret results correctly.

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

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

Schema description coverage is 100%, with per-field descriptions including the enum default of A and the 'no https:// or path' guidance, so the schema carries the parameter burden. The description only gestures at the concept ('for a record', 'the new IP' is not mentioned at all) and adds no format or matching semantics for the optional 'expected' value beyond what the schema states.

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 ('Check whether a DNS change has propagated') and then explains the mechanism — querying 10 public resolvers and locations and comparing answers. This clearly separates it from the plain lookup sibling dns_lookup, which returns a single resolution rather than a propagation comparison.

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 phrasing 'whether a DNS change has propagated' establishes the trigger condition well: use this after making a change and wanting to confirm it took effect worldwide. It stops short of naming alternatives (e.g. use dns_lookup for a single authoritative answer, whois_lookup for registration data) or stating exclusions, so the agent must infer routing.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add what those do not say. It does: it discloses that an external DNS/MX lookup occurs and, critically, that no email is actually sent — a meaningful reassurance given openWorldHint=true. It omits network latency, failure behavior for malformed input, and rate limits, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The substantive content is front-loaded in one dense sentence that enumerates checks, followed by a short negative-scope note. Every clause earns its place except the trailing web-version URL, which is promotional rather than useful to an agent and is the only real waste. Structure is otherwise clean with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description is the only source of information about results, and it never says what comes back — a boolean, per-check verdicts, a risk grade, or suggested corrections for the typo detection. For a validator whose usefulness depends on interpreting its verdict, that omission matters. The enumeration of checks partially compensates, but an agent cannot know how to read 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?

There is a single required parameter with 100% schema description coverage, so the schema already carries the documentation burden. The description adds no format guidance (e.g., whether display names like 'Name <a@b.com>' are accepted, or how to handle multiple addresses). Baseline 3 is appropriate when the schema does the work and the prose adds nothing extra.

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 ('Check') on a specific resource ('an email address') and enumerates the exact checks performed: syntax, MX records, typo detection, role/disposable detection. This is far more informative than the title alone. It stops short of 5 because it never distinguishes itself from the sibling tool email_security_check or phishing_link_check, which an agent could reasonably confuse with this one.

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 listing the checks performed, an agent can infer this is for pre-send address hygiene rather than deliverability or security auditing. There is no explicit statement of when to pick this over email_security_check, and no stated prerequisites or exclusions. 'Does not send any email' hints at a negative boundary (it is not a verification email sender) but is not framed as 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?

Beyond the read-only, idempotent, open-world annotations, it discloses that DKIM checks target common selectors and that findings include plain-English remediation. It does not explain DNS freshness, resolver behavior, or operational limits, but those are modest omissions for this straightforward diagnostic.

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 first sentence is front-loaded, compact, and informative, listing both the checks and the remediation output. The web-version URL adds no selection or invocation guidance for an MCP agent, preventing a perfect conciseness score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only diagnostic, the description supplies the target, record scope, DKIM selector limitation, and nature of the remediation output, which is sufficient for correct invocation despite the absence of an output schema. Explicit sibling alternatives and public-DNS dependence would improve completeness but are not essential.

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

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

Schema coverage is 100%, and both domain and dkim_selector are already well documented, including domain syntax and custom-selector behavior. The description reinforces the domain scope and common-selector behavior but adds little parameter meaning beyond the schema, so the baseline score 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?

The description uses a specific verb and resource—"Check a domain's email authentication"—and enumerates MX, SPF, DMARC, and DKIM, making the scope clear. It implicitly distinguishes this from general DNS lookup or email-address validation, but does not explicitly contrast those sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The wording clearly establishes the use case: auditing a domain's email-authentication configuration and obtaining fixes for missing protections. It provides no explicit when-not guidance or routing to alternatives such as dns_lookup, email_address_validate, or phishing_link_check.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint false and a closed-world scope, so the safety profile is fully covered. The description adds nothing beyond that: it does not say what happens when decoding malformed Base64/hex input, whether errors are raised or returned, or what the response looks like. With annotations carrying the safety burden, a 3 is appropriate.

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 core capability is front-loaded in a single tight sentence with no redundant wording. The second sentence is a promotional web link that adds no invocation value for an agent, a minor piece of non-earning content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple three-parameter conversion tool with full enum documentation and complete annotations, so the description is nearly sufficient. The remaining gap is decode-failure behavior and the return shape (a string of encoded/decoded text), which matter for a tool that can receive invalid 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 100% and both enums are documented in-schema, including 'Default encode' for direction. The description's format list mirrors the format enum without adding syntax, padding, or charset details beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Encode or decode') plus the resource ('text') and enumerates the five supported formats, so the core purpose is unambiguous. It does not differentiate from nearby siblings such as hash_text or url_slug, which an agent could confuse with this one at a glance, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no routing to alternatives such as hash_text for one-way digests or url_slug for slug generation. The only usage hint is 'Encode or decode', which is implicit in the tool name itself.

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?

Annotations already declare a pure read-only, idempotent, closed-world computation, so safety behaviour needs no further disclosure. The description adds genuine value by saying the tool emits warnings when the visa outlives the Iqama expiry or the planned return, but says nothing about units/currency of the fee or how warnings are presented.

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 front-loaded sentence carries the core purpose, output shape and the useful warning caveat, followed by a reference link that does not obstruct comprehension. Nothing is wasted, though the embedded link is slightly off-task for an agent caller.

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 does the work of sketching the return value (fee, return-by date, warnings), which is the key information an agent lacks. It is nearly complete for a six-parameter calculator; only the currency and the exact shape of the warning output remain unspecified.

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

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

Schema coverage is 100%, so the enum for single/multiple, the 1–24 month range, people count and the date formats are all already documented structurally, establishing a baseline of 3. The description restates the single/multiple distinction and the return-by date but adds no new semantics about how months map to fee tiers or how iqama_expiry changes the result.

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 pairs a specific verb ('Work out') with a specific resource ('Saudi exit re-entry visa fee') and even names the output components: fee for single vs multiple, the return-by date, and expiry warnings. It is clear enough to distinguish from generic calculators, but it never names a sibling such as iqama_dependent_fees, so the boundary between this tool and neighbouring Saudi-fee tools is left implicit.

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 can infer this is the tool for exit re-entry visa costs, and the mention of warnings hints that the optional iqama_expiry and planned_return inputs are worth supplying. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool for related fees.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a genuine behavioral rule that annotations cannot convey: overlapping periods are merged rather than summed, and results are expressed in years/months/days. Minor gaps remain around handling of future dates or invalid ranges.

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: the core behavior is front-loaded and the secondary web-link sentence is clearly separated. The external URL adds little for an agent invoking the MCP tool, but it costs only one line and is not confusing.

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, annotated, non-destructive calculator, the description covers the essentials of input and output. It is still thin on the structural constraints of the jobs array and on edge-case behavior (zero jobs, overlapping vs adjacent ranges, ongoing employment), which the schema alone does not explain.

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 reported as 0% and the only inline hints are 'Start (YYYY-MM-DD)' and 'End, default today'. The description adds nothing about the jobs array shape, the maxItems of 30, ordering requirements, or what the omitted-end default means for ongoing roles, so it does not 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 names a specific computation (total work experience) and its output units (years, months, days) from a specific input (job date ranges). The phrase 'merging overlapping periods' distinguishes it from simpler date tools like age_calculator or working_days, though no sibling is named 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?

Usage is only implied: the agent can infer it should be used when consolidating employment history into a total duration. There is no statement of when to prefer this over age_calculator or working_days, and no mention of preconditions such as valid date ordering or the 30-job cap.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are keyed to two different fire-class standards and include an explicit negative recommendation ('never to use'), which shapes how the agent reads the output.

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 front-loaded sentence that leads with the actionable outcome, followed by a short web-version link. Nothing is redundant, though the URL is marginally useful to an agent invoking the MCP tool.

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 lookup with no output schema and strong annotation coverage, the description is nearly complete: purpose, scope of standards, and the presence of a 'never use' warning are all disclosed. Return shape is not described, but no output schema exists to defer to.

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

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

Schema description coverage is 100% and the single enum is fully enumerated, so the schema carries the load. The description only restates that the input is a 'fire type' with dual European and US class naming, adding little meaning beyond the enum values already supplied.

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 selection task ('which fire extinguisher to use') plus the inverse ('which never to use') and names the two classification regimes covered (European/ISO/GCC and US/NFPA). No sibling in the tool list touches fire safety, so an agent can route to it unambiguously.

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 implies the trigger context (given a fire type, get the right and wrong extinguishers), which is adequate for a single-purpose utility. It gives no explicit when-not-to-use guidance, no note that it is informational rather than a substitute for emergency protocols, and names no alternatives.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: costs are computed from Aramco fuel prices in Saudi Arabia, an own price-per-litre can override the defaults, and the result is split between passengers. It stops short of describing the returned fields (total cost, litres, per-person share).

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 front-loaded sentence that packs purpose, inputs, price source and the passenger split, followed by a short reference link. Nothing is redundant, though the sentence is clause-heavy and the round-trip and unit options go unmentioned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only calculator with full schema coverage and no output schema, the description covers inputs and price source adequately. It never states what the tool returns (total cost, litres consumed, per-passenger share) or how round_trip and unit interact with consumption, which is a real gap for a calculator whose whole value is its output.

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 every parameter including the enums for fuel and unit is already documented in the schema. The description reinforces the fuel enum and the own-price and passenger-split options but adds no formatting or interaction detail beyond that; baseline 3 applies when the schema carries the semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the computed quantity (fuel cost), the domain (car trip in Saudi Arabia), the inputs (distance and consumption) and the price sources (Aramco 91/95/diesel or own price). This implicitly separates it from the sibling saudi_fuel_prices, which returns prices rather than trip costs, though no sibling is named 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?

Usage is implied by the phrase 'fuel cost of a car trip from distance and consumption', which tells an agent the required inputs. There is no explicit when-to-use or when-not-to-use guidance, and no pointer telling the agent to use saudi_fuel_prices when only the price is wanted.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing exactly what the response contains — karat variants, per-gram, per-ounce, per-tola and silver — which matters since there is no output schema. It stops short of stating the data source or how 'live' is refreshed/cached.

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 carries the entire payload, with the returned units and karats listed efficiently. The Arabic search phrase is a reasonable discoverability aid for a Saudi-focused tool, while the appended marketing URL is the one element that does not help an agent invoke the tool.

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 parameters, the description must convey the return contents, and it does so concretely across karats, weight units and both metals. The only meaningful gap is freshness/source semantics for 'live' pricing, which an agent might need in order to trust or caveat the numbers.

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

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

The tool takes no parameters, so the baseline applies and there is nothing for the description to disambiguate or constrain.

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 specific resource (live gold and silver prices) and the exact unit and scope: per gram for 24K/22K/21K/18K, per ounce, per tola, plus silver per gram in SAR. An agent can distinguish this from unrelated siblings like crypto_prices_sar or sar_exchange_rates on the resource alone, though neither alternative is explicitly 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?

Usage is only implied by 'Live gold price' — it is implicitly for current precious-metal pricing in Saudi riyals, with no statement of when to prefer a sibling such as sar_exchange_rates or crypto_prices_sar. For a zero-parameter lookup tool this is acceptable but there are no explicit 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without prose. The description's real contribution is naming the outputs (term GPA, cumulative GPA, rating, needed next-term GPA), which matters because there is no output schema; however it says nothing about grade-letter handling, invalid input behavior, or the 40-course ceiling.

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 packs the scales, the two GPA modes and the two derived outputs, with no filler. The trailing web-version URL is marginal value for an agent but short enough not to hurt scannability.

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 pure read-only calculator with 83% schema coverage and no output schema, the description covers what it computes and what it returns, which is the critical gap to fill. It stops short of explaining how the four optional cumulative/target parameters combine, so an agent may still need to read the schema closely.

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 83%, so the schema already carries most parameter meaning and a baseline of 3 applies. The description only adds that scale selection changes the whole computation and that the target-related output depends on target_gpa, but it does not explain how previous_gpa, previous_hours and next_term_hours interact, which is the least self-evident part of 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?

The description names the resource (GPA) and specifies both modes it handles (term and cumulative) plus the three supported scales (Saudi 5-point, Saudi 4-point, US 4.0), which is specific enough to distinguish it from anything else in the sibling list. It is a noun-phrase summary rather than a leading verb like 'Calculate', but nothing about the purpose is ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer you supply courses to get a term GPA and add target_gpa to get a required next-term GPA. There is no explicit when-to-use, no statement of what happens when previous_gpa is supplied versus omitted, and no guidance on which scale to pick when the user does not say.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds genuinely useful behavior beyond that by stating outputs are returned in 'hex and Base64', but it never explains what the 'all' algorithm value returns (all five digests at once? both encodings?) which is the main behavioral unknown for a tool with no output schema.

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 capability statement is front-loaded in a single clause listing algorithms and encodings, which is efficient. The trailing web-version URL does not help an agent decide or invoke anything and is the one piece of text that does not earn 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?

This is a simple two-parameter tool with full schema coverage and complete annotations, so not much is required. Still, with no output schema the description should say what the response looks like for a single algorithm versus 'all', and it leaves the hex/Base64 selection mechanism unexplained.

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 both parameters are already documented and the baseline of 3 applies. However, the description introduces a discrepancy: it promises hex and Base64 output, yet the schema has no parameter for choosing an encoding, leaving the agent unable to tell whether both are always returned or how to request one.

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 and resource ('Hash text') and enumerates the exact algorithm set (MD5, SHA-1, SHA-256, SHA-384, SHA-512), so the tool's function is unmistakable. It does not explicitly distinguish itself from nearby siblings such as encode_decode, uuid_generate, or password_generate, but the algorithm enumeration does most of that work implicitly.

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 exclusions, and no named alternative. The agent is left to infer that this is the right tool for computing digests rather than, say, encode_decode for reversible transformations. The web-version link provides no selection criteria.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioural context beyond that: the +3 C WBGT adjustment for direct sun and the 1-2 week acclimatisation assumption, which materially affect interpretation of results.

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 that front-loads the purpose and the computed outputs, with the reference URL appended. Efficient, though the clause stacking makes it slightly harder to scan than a two-sentence split would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of signalling what comes back, and naming the ACGIH work-rest regime does that adequately. All parameters are optional and documented, so an agent has enough to invoke it correctly; only the exact return shape remains implicit.

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

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

Schema coverage is 100%, so all six parameters are already documented, establishing a baseline of 3. The description reinforces the mutually exclusive input paths (measured WBGT vs. temperature+humidity) but adds no format or range detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check heat stress for outdoor work') and enumerates exactly what it computes: WBGT from temperature/humidity or a measured WBGT, heat index, and the ACGIH work-rest regime. This is clearly distinguishable from domain neighbours like noise_exposure or confined_space_gas_test.

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?

Scopes usage to outdoor work and clarifies the two input paths (estimate from temp/humidity vs. supply a measured WBGT), which is the key decision an agent faces. It stops short of explicit when-not-to-use or prerequisite guidance, so it is not a 5.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine value by naming the Umm al-Qura calendar, signalling that results may differ from other Hijri conventions. It says nothing about output format, date-range limits, or what happens on out-of-range 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 front-loaded sentence with the calendar qualifier attached, plus a web-version link. No padding, though the URL contributes little for an agent already invoking the tool.

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?

A four-parameter, zero-required conversion tool with no output schema and full annotation coverage – the description states the calendar basis, which is the main non-obvious fact. The mutually exclusive input modes and out-of-range behaviour remain unaddressed, but the schema's own description does partially cover the modes.

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 only 25% – just gregorian_date is documented – and the description adds no parameter meaning at all. It omits that hijri_year (1300-1600), hijri_month and hijri_day must be supplied together as an alternative to gregorian_date, which is the single most important calling constraint here.

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 ("Convert between Gregorian and Hijri dates") plus the exact calendar convention (Umm al-Qura, Saudi Arabia's official calendar), which distinguishes it from generic date tools like timestamp_convert. It does not explicitly say the conversion is bidirectional in one call or name any sibling, 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?

The description never says when to use this tool versus neighbours such as timestamp_convert or ramadan_imsakiya, nor does it explain the two mutually exclusive input modes. Guidance is left entirely to inference from the schema.

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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description usefully discloses the default working-week assumption (48 hours, 6 days) that silently shapes results. It does not disclose rounding behavior or what the response contains, which matters because there is no output schema.

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 plus a reference link, with the core capability front-loaded and the default assumption immediately after. The web-version URL is not strictly needed for tool selection but is short and clearly separated, so it 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 five-parameter, read-only calculator with full schema coverage and clear annotations, the definition covers purpose and default assumptions adequately. The one gap is that it never says whether the result is a single converted figure or a full breakdown across all five periods, which an agent would want to know.

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 all five parameters are already documented, and the baseline is 3. The description reinforces the meaning of days_per_week and hours_per_week by explaining the Saudi 48-hour/6-day default, but adds no new detail on amount, per, or unpaid_weeks beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Convert') and resource ('pay') plus the full set of supported units (hourly, daily, weekly, monthly, yearly), which clearly separates it from siblings like saudi_net_salary or saudi_overtime_pay that compute a different thing. It stops short of explicitly naming a sibling it is not, so it lands at 4 rather than 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 mention of 'Defaults to the Saudi 48-hour, 6-day week' implies the tool is aimed at Saudi payroll context, which is useful routing signal. However there is no explicit when-to-use/when-not statement and no named alternative (e.g. use saudi_net_salary for take-home pay), so usage must be inferred.

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?

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds useful behavior beyond that: it performs an outbound fetch of an arbitrary URL and returns status, timing, full header set, and remediation advice for six named missing headers. It stops short of disclosing error handling, timeouts, or redirect 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 core capability is packed into one front-loaded sentence that names the output fields up front, which is efficient. The trailing external URL is mildly extraneous but cheap and does hint at an interactive alternative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing return values, and it does so concretely by listing status, timing, headers, and per-header remediation. For a single-parameter read tool this is nearly complete; only failure modes and the format of the 'fixes' are left unspecified.

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 exists and schema description coverage is 100%, so the schema already tells the caller it accepts a 'URL or domain.' The description adds nothing about format expectations, scheme assumptions, or domain-only input handling, so it sits at the baseline for a fully documented single 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?

The description uses a concrete verb ('Fetch a URL') plus a detailed enumeration of what is reported: status, response time, all headers, and missing security headers with fixes. That is far more specific than a name restatement. It does not, however, differentiate itself from adjacent siblings such as http_status_code, website_health_check, or seo_page_check, so an agent must infer the boundary.

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 statement of when to use this instead of website_health_check, seo_page_check, or http_status_code, and no prerequisites or exclusions. The only routing hint is the external web-version link, which is a browser alternative rather than a sibling-tool alternative.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, which fully covers the safety profile of a lookup. The description contributes genuinely new behavioral scope by disclosing extended Cloudflare 52x coverage and an SEO interpretation, but says nothing about output shape or handling of out-of-range codes.

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, front-loaded with the core capability and followed by a reference link. The URL is mildly extraneous for an agent but costs almost nothing and no sentence 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 single-parameter, fully documented lookup with rich annotations and no output schema, the description covers what the tool does and the scope of codes it understands. The only real omission is when an agent should prefer it over related diagnostic tools.

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

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

Schema description coverage is 100%, with type, 100-599 range, and example values already documented, so the baseline is 3. The description pushes slightly beyond that by signalling that non-standard Cloudflare 52x values are in scope, which meaningfully widens the perceived valid input domain.

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 ('Explain an HTTP status code') and narrows the scope with 'including Cloudflare 52x codes' and 'what it means for SEO'. That separates it from diagnostic siblings like http_headers_check or seo_page_check, though it does not name any 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 statement of when to use this tool versus alternatives such as http_headers_check, redirect_chain, or seo_page_check, and no exclusions or prerequisites. The SEO phrase hints at a use case but leaves 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?

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful domain context by naming the calculation standards/bases, but it does not say which base is applied by default, whether both are returned, or what happens when required inputs for a metric are omitted.

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 metric list is front-loaded and the input basis follows immediately. The trailing web link is mildly promotional and contributes little for an agent already inside the tool, but overall there is no meaningful 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?

Given zero required parameters and no output schema, the description covers the essentials by enumerating the returned metrics and the standards used, which substitutes for an undocumented output shape. The main remaining gap is that it never explains the input combinations each metric requires, leaving an agent to infer that e.g. fatal accident rate needs hours plus fatalities.

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 every parameter is already documented in the schema, including the 2000-hours-per-worker convention. The description's only added semantic signal is the reference to the 200,000-hour and 1,000,000-hour bases, which does not map to specific parameters or clarify which combination feeds each metric. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Calculate') and enumerates the exact metrics produced (TRIR, LTIFR, LTIR, severity rate, fatal accident rate), which makes it unmistakable against siblings such as risk_matrix or noise_exposure. An agent knows precisely what domain computation this tool performs without inspecting 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?

Usage is implied by 'from hours worked and injuries' and by naming the OSHA 200,000-hour and IOGP 1,000,000-hour bases, which hints at the applicable reporting context. However, there is no explicit when-to-use/when-not guidance, no statement of which inputs pair with which metric, and no routing to alternatives.

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?

Annotations already declare this a read-only, idempotent, closed-world, non-destructive operation, so the safety profile needs no restating. The description adds real domain context the annotations cannot: the SAR 400 per-dependent monthly default and the note that the employer normally pays the worker's own Iqama and work permit (hence the optional flag). It stops short of describing what the computed output 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 that leads with the purpose and then lists cost components, plus a link that is clearly separable from the instructions. No filler, though the URL occupies sentence-final space that could otherwise clarify the return value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only calculator with full schema coverage and no output schema, the agent has enough to invoke it: currency, the cost components included, the default rates, and the employer-pays caveat. The main remaining gap is the shape of the result (line-item breakdown vs. single total), which the description leaves 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 100%, so every one of the nine parameters is already documented, and the baseline of 3 applies. The description supplies one extra datum the schema omits, the SAR 400 monthly dependent levy default that dependent_levy_sar overrides, but adds nothing about months, trip_months, or travellers_per_trip beyond the schema text.

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: budget the yearly family cost of living in Saudi Arabia, naming the concrete components (dependent levy, exit re-entry visas, optional own Iqama and work permit). An agent can tell this is a fee total calculator, but the description does not explicitly distinguish it from the exit_reentry_visa sibling, which covers one of the same components in isolation.

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 context is implied by 'with family' and 'yearly', so an agent knows to reach for this for household budgeting rather than single-visa lookups. However there is no explicit when-to-use/when-not guidance and no pointer to exit_reentry_visa for the narrower case, leaving the choice 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is handled. The description adds the header-row requirement for CSV input and the array-of-objects constraint for JSON, but says nothing about error behavior on malformed input, how nested objects are handled, or delimiter effects.

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 conversion sentence is front-loaded, precise, and free of filler. The second sentence is a marketing URL that consumes roughly half the definition without helping an agent invoke the tool, which keeps this below a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-mode conversion tool with full schema coverage and strong annotations, the description covers the core contract adequately. With no output schema, though, it should at least indicate what the return value looks like (CSV string vs JSON string) and how invalid or ragged input is 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 100%, so the schema already documents all three parameters, making 3 the baseline. The description reinforces the accepted input formats but never mentions the delimiter parameter or its default, so it adds almost nothing the schema doesn't already say.

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 concrete verb (convert) with both resources named (JSON array of objects, CSV with header row) and makes the bidirectional nature explicit. The one gap is that it never distinguishes itself from the sibling json_format_validate, which an agent could reasonably confuse with a plain format/validate task.

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 format constraints – 'JSON array of objects' and 'CSV (with a header row)' tell the agent what input shape qualifies, which is genuinely useful. However, there is no explicit when-to-use versus json_format_validate, and no statement of what happens when the input doesn't match those shapes.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: on invalid input it returns the error position rather than throwing or returning a generic failure. It says nothing about size limits or how the success payload is shaped.

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 carries the whole functional definition, front-loaded with the verb and resource, with defaults and error behavior trailing. The trailing marketing URL is not needed for tool selection but 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?

This is a simple, fully-annotated, single-string-input utility with complete schema coverage. Since no output schema exists, the description usefully states what comes back — formatted JSON, or the parse error position. Enough context to invoke it correctly without guessing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including defaults and the pretty/minify enum. The description only echoes the style outcome ('pretty-printed or minified') without adding meaning about indent behavior or sort_keys, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a concrete verb and resource (validate JSON) plus the two result modes (pretty-printed / minified) and error reporting. An agent can tell immediately what this does. It does not reference the nearest sibling (json_csv_convert), so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the tool name and description — you call it with a JSON string to check validity or to reformat. There is no explicit when-to-use / when-not-to-use statement and no routing hint toward json_csv_convert for format conversion, so guidance is only implicit.

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?

Annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context beyond that: it discloses the security-relevant limitation that signature verification is not performed and lists the decoded output categories.

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 compact sentences, front-loads the core action, and includes only useful information. The web version link is a minor extra but does not dilute the definition.

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 decoder with no output schema, the description sufficiently explains what will be returned and what will not be done. It does not describe invalid-token or parse-error behavior, but the essential context is 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 description coverage is 100%, and the single token parameter is already well documented as 'header.payload.signature'. The description does not add syntax or format guidance beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Decode a JSON Web Token') and states exactly what parts are surfaced: header, payload, issued/expiry times, and expiration status. This distinguishes it clearly from sibling utilities such as encode_decode or hash_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?

It gives clear context for use and an important exclusion ('Does not verify the signature'), which prevents misuse for security validation. It does not explicitly name alternatives or say when to choose a different tool, keeping it just below the top score.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds domain context (the 4:1 rule equates to about 75.5 degrees, and roof_access extends the ladder 1 m above the support point), but it says nothing about what the result contains or how it is presented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence front-loads the rule and the degrees equivalent before the two use modes. The trailing web-version URL is mildly extraneous for an agent but does not obscure the core meaning.

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 calculator with no output schema, the description covers inputs adequately but leaves the return values (angle in degrees? required base distance? ladder length?) unexplained. An agent can invoke it, but cannot predict the shape of the answer.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces that base_m is for angle-checking and roof_access relates to stepping onto a roof, but adds no new syntax, ranges, or defaults beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete subject (ladder safety by the 4:1 rule) and the two computations it performs: deriving base distance and ladder length from a height, or checking the angle from height plus base distance. It is clearly distinct from siblings such as sling_angle, though it never uses an explicit verb like 'calculate'.

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 implicitly tells the agent which inputs map to which mode (height alone vs. height plus base distance), which is useful selection guidance. However, there are no explicit when-to-use or when-not-to-use statements, and no sibling alternatives are named.

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?

Annotations already declare this a read-only, idempotent, non-destructive, closed-world calculation, so the safety bar is low. The description adds value beyond them by stating which figures are produced and that fees feed into the APR rather than the instalment, and by linking an external reference implementation. It stops short of describing rounding, currency, or ordering of results, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The computable outputs are front-loaded in a single dense sentence, followed by the reference URL, with no filler. It is information-dense rather than wasteful, though the one-sentence packing of outputs, rate models, and the SAMA check makes it slightly harder to scan than a short bulleted form would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing results and does so by naming the three returned figures. Combined with full schema coverage and read-only annotations, an agent has enough to invoke it correctly. It omits currency/unit conventions and the exact shape of the SAMA check result, which is the remaining shortfall.

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

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

Schema coverage is 100%, so the baseline is 3 for the six documented parameters. The description adds meaning on top: it explains that the flat model is the Saudi-bank norm, that fees affect APR specifically, and that monthly_salary triggers the 33.33% deduction check — context the schema's terse field descriptions do not carry.

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 set (calculate) and concrete outputs — monthly instalment, total profit, real APR — plus the domain (loan / Islamic personal finance). It distinguishes the two supported rate models (flat vs reducing) and flags the SAMA salary check, so an agent knows exactly what this tool computes and that no sibling tool covers this function.

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 real selection context: flat rate is noted as common in Saudi banks, and the SAMA one-third salary check is tied to providing a salary. That steers the agent on rate_type and monthly_salary. There is no explicit when-not-to-use statement or named alternative, but no sibling overlaps this calculation, so the gap is minor.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description needn't repeat it. The description adds the useful behavioral fact that lookups run in both directions against a reference table, but omits what happens on a miss (error vs. empty result) and there is no output schema to fill that 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?

The core sentence is front-loaded and contains zero waste. The trailing 'Web version' URL does not help an agent select or invoke the tool and is the only element that fails to earn its place, keeping it just short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only lookup with clean annotations and no output schema, the description gives enough to call it correctly in either direction. The one real gap is the return shape for the reverse lookup — whether multiple extensions come back as a list — which an agent would need in order to parse results.

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

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

Schema description coverage is 100% and the `query` description already lists accepted forms (pdf, .webp, image/png), so the baseline is 3. The description reinforces the dual interpretation of a single parameter, which is mildly useful, but adds no format, casing, or leading-dot rules beyond what the schema states.

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 plus resource — 'Find the MIME (Content-Type) for a file extension, or the extensions for a MIME type' — and explicitly captures the bidirectional nature of the lookup. An agent immediately knows the tool's scope without touching the schema, and no sibling tool offers this capability, so differentiation is a non-issue.

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 two lookup directions imply usage context (feed an extension or a MIME type), so an agent can infer when to call it. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of behavior for unknown inputs, and no routing to an alternative. Since no sibling overlaps, this is minimum-viable rather than deficient.

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?

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description usefully adds the computational basis (both OSHA and NIOSH criteria with exchange rates), but says nothing about the 12-exposure ceiling, what happens with total hours over 24, or the units of the returned dose.

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, front-loaded sentence covers computation, inputs, units, and standards; the trailing URL is minor filler that does not obstruct comprehension. Nothing essential is 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?

With no output schema, the description at least names the two return values (daily dose and 8-hour TWA), which is the minimum an agent needs. It still leaves output units (percent dose vs. dB), the 12-item cap, and edge-case behavior unstated for a tool whose result depends on those specifics.

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 reported at 0% for the single top-level parameter, so the description must carry meaning: it establishes that levels are in dBA and durations are per-level, which maps to the dba/hours fields. It does not explain the maxItems=12 limit, whether hours must sum to a workday, or how overlapping exposures are handled.

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?

"Daily noise dose and 8-hour TWA from noise levels (dBA) and durations" names a specific computation and its inputs, plus the governing standards (OSHA 90 dBA/5 dB, NIOSH 85 dBA/3 dB). An agent can tell this apart from neighbors like heat_stress, though no sibling is named 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?

Usage is only implied by the purpose: an agent infers this is the tool for occupational noise dose rather than heat stress. There is no statement of when to use it, when not to, or which standard to prefer for a given jurisdiction.

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?

The annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the quote basis (futures, per barrel) and both currencies, which is useful, but says nothing about data freshness, source, or update cadence, which is what a 'latest price' tool actually needs to disclose.

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 core sentence is front-loaded and efficient, stating commodity, basis, and units in one pass. The trailing 'Web version' URL is a light promotional addition that does not help an agent invoke the tool, so a small amount of space is not earned.

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 input schema fields and no output schema, the description carries the burden of telling the agent what comes back, and it does name the two currencies and the per-barrel unit. What remains missing is recency (how 'latest' is refreshed) and the shape of the response, so it is good 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline is 4. The mention of USD and SAR per barrel is the only semantic detail, and it applies to the output rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Latest Brent and WTI crude oil futures prices,' with units (US dollars and Saudi riyals per barrel). That is enough to distinguish it from the sibling price tools (saudi_fuel_prices, gold_silver_prices_sar, crypto_prices_sar), though it never explicitly contrasts itself with them.

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 can infer this is the tool for current crude benchmarks, with no when-not-to-use guidance and no named alternative. For a zero-parameter lookup the cost of that gap is low, but no routing guidance is given.

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 annotations already declaring readOnlyHint=true and destructiveHint=false, the description still adds meaningful behavior: generation happens on the server, secrets are not stored, output is cryptographically secure, and the estimated entropy is returned. The 'not stored' guarantee is exactly the kind of context annotations cannot express; it loses a point for not clarifying the exact response 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?

The core capability and the security/storage guarantees are front-loaded in the first two sentences with no wasted wording. The trailing 'Web version' link is mildly promotional but short enough not to distract.

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 four-optional-parameter, no-output-schema tool, the description covers purpose, security properties, storage behavior and the returned entropy value, which is most of what an agent needs. The remaining gap is the unsupported passphrase mode and the exact format of the returned password list.

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 count, length, symbols and exclude_ambiguous are already fully documented with defaults and ranges, making 3 the baseline. The description adds no parameter-level meaning beyond the schema and never reconciles the promised passphrase mode with the missing mode parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Generate strong random passwords ... or passphrases') plus the differentiator of server-side, cryptographically secure generation, which separates it from siblings like uuid_generate or hash_text. However, it advertises a passphrase mode that has no corresponding parameter in the schema, which slightly muddies what the tool actually does.

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 resource name (you generate passwords when you need a credential), but there is no explicit when-to-use guidance and no routing against the nearest alternatives such as uuid_generate for identifiers or hash_text for digests. Nothing tells the agent when this tool is the wrong 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavior beyond that — no note on the unit/format of the returned value or rounding behavior — and spends part of its budget on an external web link, which is not agent-relevant.

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 core content is a single tight sentence with the operation list front-loaded, which is well-structured. The trailing 'Web version' URL does not earn its place in an agent-facing definition and slightly dilutes it.

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 pure, side-effect-free arithmetic tool with three fully documented parameters and no output schema, the description covers everything needed to invoke it correctly. The only gap is that return value format (number vs. formatted string with % sign) is unspecified, though that is minor for this tool class.

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

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

Schema description coverage is 100% and the schema's mode enum description already states each formula verbatim, so the description largely restates structured data. It adds only marginal value by labeling the modes with real-world scenarios (discounts, raises), which is why this sits at the baseline rather than higher.

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 (percentage maths) and enumerates each supported operation with formulas ('X% of Y', 'X is what % of Y', 'change from X to Y', add/subtract a percentage). This makes it trivially distinguishable from numeric siblings like gpa_calculator, loan_calculator, or zakat.

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 concrete use contexts ('discounts, raises') that map to the add_percent/subtract_percent modes, so an agent can pick a mode from the user's phrasing. It does not, however, name an alternative tool or state when this tool is the wrong choice, so it stops short of full routing 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that it follows redirects to the real destination and lists what signals it looks for, but says nothing about output shape, how findings are scored, timeout/network failure behavior, or whether a warning is a verdict or a heuristic. With openWorldHint set, the lack of any note about network failures or fetch limits is a gap, but the description does add real context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense sentence front-loads the purpose and enumerates the signals in a parenthetical, followed by a short note on redirect following and a web link. There is no filler and the key information comes first.

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 read-only check with full schema coverage and no output schema, the description covers purpose, signals inspected, and redirect semantics well enough to invoke correctly. What's missing is any indication of result format or what a finding looks like, which matters somewhat for an agent deciding whether to act on the 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 100% — both url and follow_redirects are documented, including the default for follow_redirects. The description reinforces the follow-redirect behavior but adds no syntax, format, or edge-case meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (check) and resource (a suspicious link) and enumerates the exact signals it inspects — look-alike Saudi brands, risky TLDs, IP addresses, punycode, shorteners — plus redirect following. This clearly distinguishes it from siblings like redirect_chain, url_slug, or http_status_code, which share the URL domain but do different work.

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 name and the schema hint ('The link from the SMS, WhatsApp or email'), which tells the agent this is for user-received suspicious links. However, there is no explicit when-to-use/when-not-to-use statement and no routing to related siblings such as redirect_chain or ssl_certificate_check for deeper checks.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only that common service ports are checked on public hosts; it does not disclose timeout behavior, whether the check is TCP connect, or what the response contains.

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 first sentence is front-loaded and precise, listing the scope and example ports efficiently. The second sentence is a web link that adds little for an agent invoking the tool, making the description slightly longer than necessary.

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 two-parameter read-only tool with rich annotations and no output schema, the description covers the core purpose adequately. It is still incomplete regarding return values (open/closed, latency, banner info) and operational behavior such as timeout or blocking detection.

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

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

Schema coverage is 100%, with both host and port documented in the input schema. The description adds a list of common port numbers, which gives useful examples for choosing the port value, but does not add syntax or constraints beyond the schema's 1–65535 range.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: check whether a service port is open on a public host. The port list and 'public host' scope make the purpose clear, but the description does not explicitly differentiate it from sibling tools like website_health_check or ssl_certificate_check.

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 'public host' constraint implies the tool is not for private/internal addresses, which is useful implied guidance. However, there is no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as dns_lookup or website_health_check.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the whole-month granularity, the Umm al-Qura calendar basis, the current-or-next-Ramadan selection rule, and the Saudi-city restriction. It stops short of describing the response shape or how 'next Ramadan' is resolved when one is underway.

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 states the resource, the scope and the calendar, then a reference URL is appended. No filler, no repetition of the tool 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, the description carries the burden of describing returns, and it does so by naming the four daily time fields and the per-day coverage. Minor gaps remain around output structure (one entry per day?) and how the current/next Ramadan boundary is decided, but an agent has enough 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 coverage is 100% and the single enum already lists all twelve cities with the riyadh default, so the description has little to add on the parameter. It mentions 'a Saudi city' but adds no semantics beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (Ramadan imsakiya timetable) and enumerates the exact fields returned: imsak, fajr, maghrib (iftar) and isha. It scopes the output to 'every day of the current or next Ramadan' by the Umm al-Qura calendar, which differentiates it from the daily-prayer sibling saudi_prayer_times.

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 temporal scope ('current or next Ramadan') implicitly tells the agent when this tool applies, but there is no explicit guidance on when to pick it over saudi_prayer_times, nor any stated exclusions or preconditions. 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?

Annotations already declare read-only, idempotent, open-world and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: a 10-hop cap and the fact that every hop's status code and location are surfaced, which matters for an open-world network call. It does not say what happens when the cap is hit or how timeouts 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 core behavior and the 10-hop constraint are front-loaded in a single efficient sentence. The trailing web-version link is minor filler but small enough not to distract.

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 fetch tool with full schema coverage and complete annotations, the description covers purpose, the hop limit and the shape of what the agent will see. With no output schema, a sentence on truncation behavior at the 10-hop limit would have closed the remaining 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?

There is a single required parameter with 100% schema description coverage ('URL to check'), so the schema already carries the meaning. The description implies the URL is the redirect origin but adds no format, normalization or edge-case guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action and resource: follow a URL's redirects hop by hop and report each status code and location. The hop-by-hop framing and mention of chains, loops and 302-vs-301 implicitly separates it from the single-status-code sibling, though no sibling is named 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 phrase 'to find chains, loops and 302s that should be 301s' gives a clear use context (redirect/SEO auditing). It does not state exclusions or name alternatives such as http_status_code or website_health_check, so it stops short of full when-not 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real value by disclosing what comes back: match positions, capture groups, and an optional replacement result. It does not cover behavior on invalid patterns (error vs empty result), which is the main remaining 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?

A single front-loaded sentence states the operation and its outputs with no filler. The trailing web-version URL does little for an agent deciding how to invoke the tool, so it is the one mildly wasteful element.

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 carry the return-value burden, and it does so by listing matches with positions, capture groups, and replacement output. Given a simple four-parameter tool with fully documented schema fields and safe annotations, this is nearly complete, missing only error behavior for malformed patterns.

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 each parameter is already documented in the schema, making 3 the baseline. The description only lightly reinforces semantics by calling the replacement result optional and by pinning the regex flavor to JavaScript; it adds no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Test') and resource ('a JavaScript regular expression against text') and even previews the output (matches, positions, capture groups, optional replacement). The 'JavaScript' qualifier usefully distinguishes the regex flavor, and no sibling tool overlaps with regex testing, so no sibling routing sentence is needed.

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 purpose: an agent can infer it should call this when it needs to check a pattern against text. There is no explicit when-to-use or when-not guidance, and no mention of alternatives such as hash_text or text_stats for adjacent text-processing needs.

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?

Annotations already declare a safe, deterministic read (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely new behavioral information by disclosing what the tool returns, the numeric score, the risk band, and the required action, which matters since no output schema exists. It does not state the band thresholds themselves, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence carries the purpose, inputs, and returns with no filler. The trailing URL is extraneous for an agent invoking a tool but does not obscure the core content, so it is a small blemish rather than a structural problem.

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, describing the response was this description's obligation, and it does so (score, band, required action). The main remaining gap is that it never explains what the tool does if only one of the two optional residual parameters is provided, or what the "required action" strings look like.

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 every parameter including the optional residual_severity and residual_likelihood is already documented in the schema. The description's "before and after controls" frames the residual pair semantically but adds no new detail about ranges, formats, or what happens if only one residual value is supplied. Baseline 3 applies when the schema does the heavy lifting.

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?

"Rate a hazard on a 5x5 risk matrix: likelihood x severity" names a specific verb and resource, and the sentence goes on to enumerate the exact outputs (score 1-25, band, required action). Sibling tools are all unrelated calculators/validators, so no differentiation is needed; an agent can tell immediately what this does.

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 phrase "before and after controls" implies the expected workflow (a base rating plus an optional residual rating), which is useful context for when to supply the extra parameters. However, there is no explicit when-to-use/when-not guidance, no statement about prerequisites, and no named alternative tool.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description's extra burden is lower. It still adds useful behavior beyond them: it reaches out to a live site, reports an allow/deny verdict per user agent, and returns declared sitemaps as a side output. It does not say what happens when robots.txt is missing or unreachable, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence front-loads the fetch-and-test purpose and appends the secondary sitemap output without waste. The trailing web-version URL is non-functional for an agent but small enough not to disrupt the structure.

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 read-only tool with full schema coverage and complete annotations, the description supplies what is needed: what it fetches, what question it answers, which crawlers are supported, and that sitemaps are included in the response. Only error/empty-robots.txt behavior is unaddressed, and with no output schema that is a minor residual 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 100%, so both parameters are already documented, making 3 the baseline. The description adds modest value by naming concrete crawler identities (Googlebot, Bingbot, GPTBot, ClaudeBot) and stating 'any user agent' is accepted, expanding on the schema's terse 'Crawler, default Googlebot', but it gives no format hints for the URL/path argument.

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 specific verb and resource ('Fetch a site's robots.txt') and states exactly what is computed from it ('test whether a crawler ... may crawl a path'), plus a secondary output ('lists the sitemaps it declares'). That is clearly separable from neighbors like sitemap_validate, seo_page_check, and http_headers_check, which do not evaluate crawl directives.

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 phrasing ('test whether a crawler ... may crawl a path'), so an agent can infer this is the tool for crawl-permission questions. However, there is no explicit when-to-use/when-not guidance and no reference to adjacent siblings (e.g. sitemap_validate for the sitemap list itself, or http_status_code for reachability).

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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the rate is today's mid-market rate, which tells the agent the data is a live external fetch and is not a buy/sell or historical quote. It does not disclose the rate provider, caching/freshness window, or failure behavior when a currency is unsupported.

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 purpose is front-loaded in a single efficient sentence, which is good. But the 25-code parenthetical is bulky and the trailing 'Web version:' URL serves no decision or invocation need for an agent, adding length without adding callable meaning.

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?

All three parameters are optional with defaults documented in the schema, and the external-fetch nature is signalled by openWorldHint. However, with no output schema, the description should say something about the return shape — whether it yields a single converted amount or a per-currency map for the array input — and that is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description earns a bump by enumerating the supported currency codes — information the schema lacks entirely since no parameter has an enum. The enumeration is only tied to the 'to' list, however, leaving it ambiguous whether the same set applies to the 'from' currency code.

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 — 'Convert Saudi riyals to or from other currencies' — plus the rate basis ('today's mid-market rate'). This clearly separates it from sibling price tools like crypto_prices_sar, gold_silver_prices_sar and oil_prices, which report prices rather than perform conversion.

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 purpose statement; there is no explicit 'use this when...' guidance and no named alternative or exclusion. An agent can infer that this is the tool for SAR currency conversion, but nothing tells it whether a different tool should be preferred for historical rates or non-SAR base currencies.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral substance beyond that: which tariff vintage is applied, that VAT is 15%, that the fixed fee keys off breaker size, and that a 2026 comparison figure is included in the result. It stops short of describing the returned structure or currency, but that is a minor residual gap against an otherwise well-covered annotation set.

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 padding, with the tariff year and computed components front-loaded before the link. The trailing web-version URL is a small promotional addition but is plausibly useful for the human-readable equivalent, so it does not materially hurt.

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 five parameters, full schema coverage and no output schema, the description carries only the burden of explaining what is produced — and it does name the components (slab rates, fixed fee, VAT, 2026 comparison). It omits return shape details such as whether a per-slab breakdown or a single total is returned, and never states the currency of the result explicitly, which is the main remaining gap for a calculator with no output schema.

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

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

Schema description coverage is 100%, with enum values and defaults already documented per parameter, so the schema does the heavy lifting and a baseline of 3 applies. The description adds only indirect meaning — that breaker drives the fixed fee and that VAT is 15% — rather than clarifying any individual parameter such as how sector changes the slab table or what fixed_fee_sar overrides.

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 ("Estimate") plus a specific resource ("Saudi Electricity (SEC) bill") scoped to the 2027 tariff, listed components (slab rates, breaker-based fixed fee, 15% VAT) and a comparison output. This clearly distinguishes it from siblings like saudi_water_bill or saudi_vat without the agent needing to open 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?

Usage is implied by the tool name and the "Estimate a bill" framing, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., vs saudi_vat for tax-only questions or saudi_water_bill for utilities generally). The agent must infer the boundary 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behaviour, so the description need mainly add domain behaviour. It does: the award follows Articles 84/85 and is reduced on resignation, which tells the caller the result actually changes with the 'reason' parameter. It stops short of noting assumptions (e.g. wage basis, exclusion of unpaid leave) that affect the returned figure.

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 gives the verb, the resource, the legal basis, and the key special case with zero filler. The trailing web-version URL is mild promotional ballast rather than instructional content, which keeps it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter, no-output-schema calculation tool, the description covers the purpose and the one behavioural twist but says nothing about the result (presumably an SAR amount plus service duration and a breakdown). An agent can call it correctly, but cannot predict the shape of what comes back.

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

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

Schema description coverage is 100%, so the schema already explains monthly_wage, the date formats, and the reason enum. The description adds only indirect meaning, that choosing resignation triggers the statutory reduction. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (calculate) and resource (end-of-service award/gratuity) and anchors it to Saudi Labor Law Articles 84 and 85, which is far more specific than the name alone. It does not explicitly distinguish itself from near neighbours like saudi_final_settlement or saudi_gosi_contribution, so an agent must infer the boundary from the legal citation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the legal reference and the mention of a resignation reduction signal the domain, and the 'reason' enum gates the two cases. There is no statement of when to prefer this over saudi_final_settlement or saudi_leave, and no mention of eligibility prerequisites such as minimum service length under Article 85.

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?

The annotations already establish a safe, read-only, idempotent operation, while 'Estimate' and the component list add useful context about the calculation. However, the description does not disclose the legal or formulaic basis, rounding conventions, or limitations of the estimate.

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 substantive sentence is front-loaded, compact, and informative. The web-version URL adds little value for tool selection or invocation, but it does not create significant 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?

Together with the rich schema and annotations, the description is sufficient for basic selection and invocation. For a legally sensitive payroll calculation without an output schema, it leaves meaningful gaps around calculation assumptions, the effect of reason, and the form of the returned estimate.

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?

With 89% schema description coverage, the schema already explains nearly all parameters, and the description mainly reinforces how several optional amounts contribute to the settlement. It does not compensate for the undocumented reason parameter by explaining how termination versus resignation changes the calculation or what happens when it is omitted.

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 and resource—estimating a full Saudi final settlement—and itemizes its components. The inclusion of leave, unpaid salary, notice pay, and deductions distinguishes it from narrower siblings such as saudi_end_of_service.

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 clearly establishes the context for use: a comprehensive final-settlement estimate rather than a single payroll component. It does not explicitly state when not to use it or route agents to saudi_end_of_service or other siblings for narrower calculations.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered by structured data. The description adds little beyond annotations: it says prices are 'current' but gives no refresh cadence, data source, or what is returned when litres is omitted. The external web link is redundant for invocation and not behavioral context.

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 front-loaded sentence states the resource, products, currency and the optional cost behavior with no wasted wording. The trailing web-version URL is marginally useful for humans but not for tool selection, slightly diluting an otherwise tight definition.

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 optional-parameter read-only tool with full annotation coverage and no output schema, the description covers what is needed to call it correctly. Minor gaps remain around data freshness and the default response when litres is absent, but nothing blocks correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: passing litres yields a computed trip/fill-up cost rather than just a price table, which clarifies the purpose of 'Optional litres to price.' The minimum-0 constraint is left to the schema, appropriately.

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 (Aramco retail fuel prices in Saudi Arabia), enumerates the products covered (petrol 91, petrol 95, diesel) and states the unit (SAR per litre). It is clearly distinguishable from generic siblings like oil_prices or crypto_prices_sar, though it never explicitly routes the agent away from the nearby fuel_trip_cost tool.

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 'Current' and the optional trip/fill-up cost framing, which tells the agent this is the lookup to use before a cost calculation. There is no explicit when-to-use/when-not statement and no named alternative (e.g. fuel_trip_cost) for full trip calculations.

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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds that output is split between employee and employer shares and that new-law rates apply to post-2024 registrations, but it does not say what the response contains, whether rates are annual-updated, or how defaults are applied — and with no output schema, that gap is real. Adequate but not rich.

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 front-loaded sentence carrying purpose, scope, and the new-law caveat, plus a reference link. No padding or restatement of the title. The URL is defensible as a source reference though it consumes space an agent cannot act on.

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 six-parameter financial calculator with no output schema, the agent still does not know the shape of the result — whether it returns separate employee/employer amounts, totals, a rate breakdown, or currency-formatted strings. The domain concept itself is well framed, but the missing return expectation leaves a meaningful hole.

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

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

Schema description coverage is 100% and every parameter including the two enums is fully documented, so the baseline is 3. The description only echoes the first_registered distinction already spelled out in that parameter's schema description; it adds no syntax, unit, or interaction details (e.g., how housing_in_kind substitutes for housing_allowance) beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (Calculate), a specific resource (monthly GOSI social insurance contributions), a scope (employee and employer, Saudi Arabia), and a notable variant (new-law annuity rates for registrations from 3 July 2024). No sibling tool covers GOSI, so an agent can route here unambiguously from the name plus this sentence.

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 'calculate ... contributions' and the new-law qualifier gives one meaningful selection condition, but there is no explicit when-to-use framing, no mention of related siblings (saudi_net_salary, saudi_end_of_service, saudi_final_settlement) that also concern payroll totals, and no note on when the tool is inappropriate.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real value by disclosing the verification method (mod-97 check digits) and that a bank is resolved from the code. It does not say what the result looks like (boolean vs object with bank name), and with no output schema that gap remains.

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 front-loaded sentence carries the format, algorithm and bank-lookup behavior. The trailing marketing URL for the web version adds little for an agent caller, but it is short and does not obscure 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 one-parameter validator with no output schema, the description should say what comes back (validity, detected bank, formatted IBAN). It hints at bank identification but never specifies the response shape, leaving an agent to guess the return contract.

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

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

Schema coverage is 100% and the property already documents space tolerance with an example. The description still adds the non-obvious structural constraint (SA + 22 digits), which tells the agent what input is acceptable beyond the schema wording.

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 ('Check a Saudi IBAN'), pins the exact expected format (SA + 22 digits), and adds a second capability (identify the bank from its code). An agent can distinguish it from generic validators like email_address_validate or json_format_validate 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?

The 'Saudi IBAN (SA + 22 digits)' constraint implicitly scopes use to Saudi accounts only, which is light when-to-use guidance. It never names an alternative or says what to do for non-Saudi IBANs, and there is no when-not-use statement.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is to add context. It contributes the legal basis and the amendment date, which is genuinely useful for trusting the ruleset, plus a web version for verification. It does not disclose what is returned (days of balance, SAR pay amounts, or date ranges) despite there being no output schema.

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-loads the resource and the three modes, followed by a reference URL. Every clause earns its place, though the trailing link is of marginal use to an agent invoking the tool.

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 8 parameters, only 1 required, and no output schema, the description leaves the return shape unspecified — an agent cannot tell whether it will receive a day count, a SAR amount, or eligible dates. Mode-to-parameter mapping is well handled by the schema, so the remaining gap is primarily the undisclosed result form.

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 88%, with each parameter already tagged by mode (annual/sick/maternity), so the baseline is 3. The description adds legal article context that explains why each mode exists but no additional meaning about parameter interaction — e.g. that monthly_wage applies to both annual and sick but not maternity is only in 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?

The description names a specific resource (Saudi Labor Law leave) and enumerates three distinct computation modes with legal anchors: annual leave balance (Art. 109), sick leave pay (Art. 117), maternity leave dates (Art. 151, Feb 2025 amendment). This clearly separates it from payroll-adjacent siblings such as saudi_end_of_service, saudi_final_settlement, and saudi_overtime_pay. It stops short of 5 because the operative verb ('calculates') is only implied.

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 three listed modes map directly onto the kind enum, so an agent can infer which mode to request, but there is no explicit when-to-use framing or steering toward alternatives. Nothing tells the agent when to prefer this over saudi_final_settlement (which also touches accrued leave) or when a mode is inapplicable.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds genuine context beyond that: what the calculation includes (GOSI deduction, expat levy for non-Saudis) and that it returns both employee-side and employer-side figures on monthly and yearly bases, which partially compensates for the missing output schema.

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 with the core purpose front-loaded and no filler; the embedded web-calculator link is supplementary rather than distracting. It could be slightly tighter, but 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 9-parameter read-only calculator with no output schema, the description conveys what comes back (net salary, monthly and yearly employer cost) and what the headline cost component is (expat levy). It stops short of naming the assumptions or rate regimes that drive the result, which an agent might want for verification.

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 every parameter including the two enums (nationality, first_registered) is already documented with its default and units. The description adds no extra meaning about individual inputs such as how first_registered affects the GOSI rate, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and a clearly bounded resource: net take-home salary in Saudi Arabia after GOSI, plus total monthly and yearly employer cost including the expat levy. That scope distinguishes it from siblings such as saudi_gosi_contribution (contribution only) and hourly_to_salary (generic conversion) without the agent needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the scope statement — you would call it when you want take-home pay and employer cost together — but the description never explicitly says when to prefer it over saudi_gosi_contribution, saudi_final_settlement, or saudi_end_of_service, nor does it state any 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered and the bar is lower. The description adds the legal basis and computation rule, which is genuinely useful context, but says nothing about rounding, currency of the result, or how total_monthly_wage affects the premium.

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 rule and formula are front-loaded in a single efficient sentence. The trailing link to an external web calculator is not needed for tool invocation and slightly dilutes an otherwise tight definition.

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 should say more about the returned value, and it doesn't specify currency (implied SAR) or rounding. Otherwise, for a simple four-parameter calculation tool with full schema coverage and read-only annotations, it supplies enough to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including monthly_hours defaults and Ramadan guidance. The description's formula explains how basic_salary and overtime_hours combine, adding some meaning, but it does not clarify the role of total_monthly_wage or monthly_hours beyond what the schema states.

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 resource ('Calculate overtime pay') plus the governing rule (Saudi Labor Law Article 107) and the exact formula. It is clearly distinct from generic pay tools, though it never names a sibling such as saudi_net_salary or saudi_final_settlement to route the agent 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?

Usage is only implied: the Article 107 framing signals this applies to overtime hours beyond normal working hours in Saudi Arabia. There is no statement of when to prefer this over hourly_to_salary or saudi_net_salary, and no prerequisites or exclusions are given.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the exact calculation convention (Fajr 18.5°, Isha 90 min after Maghrib, 120 in Ramadan), which lets an agent judge whether results match a user's expectation, plus a reference web version for cross-checking.

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 and method front-loaded and no filler. The external URL is marginally useful rather than essential, 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?

There is no output schema, so the description should say what comes back (prayer names, formatted times, which timezone) and it does not. For a tool with five optional parameters and no required inputs, the missing return-shape and city/coordinate conflict rule leave real 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 coverage is 60% and the description adds little per-parameter meaning: date default, city enum and utc_offset default are all already in the schema descriptions. Its one contribution is reinforcing the city-versus-coordinates choice, and it says nothing about precedence if both are supplied, nor about the undocumented latitude/longitude fields.

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 (prayer times / مواقيت الصلاة) and its scope (a Saudi city or arbitrary coordinates) plus the calculation convention used. It does not differentiate itself from the closely related sibling ramadan_imsakiya or hijri_gregorian_convert, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the phrasing 'for a Saudi city or any coordinates' signals two input modes, but there is no explicit statement of when to prefer this tool over ramadan_imsakiya, nor any precondition or exclusion. An agent can guess the context but is given no routing rule.

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?

Annotations already declare read-only, idempotent, closed-world behaviour, so the safety profile is covered. The description adds genuine domain context the annotations cannot: the rules follow the February 2025 amendment, and Eid days and sick leave are excluded from the probation count. It stops short of describing the return shape, but that is a minor gap here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the resource and the three outcomes, then a reference link. Nothing is padded, though the marketing URL is non-essential and the sentence is dense enough that the three modes blur together slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should signal what comes back; it implies a computed date for each mode, which is adequate for a stateless calculator. For a 6-parameter tool with full schema descriptions and strong annotations, the remaining gap is only the exact return format, so it is close to 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 100%, so the schema already documents each parameter including the 30/60-day notice split in 'who_ends'. The description adds meaning on top by clarifying that sick_days and Eid holidays do not count toward probation, which tells the agent what to feed in rather than just the field name.

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 (Saudi Labor Law dates) and three concrete computed outcomes: probation end, last day of notice, fixed-term contract end. This maps directly onto the 'kind' enum. It does not explicitly distinguish itself from neighbouring payroll tools like saudi_end_of_service or saudi_final_settlement, 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?

Usage is implied by listing the three compute modes, but there is no explicit 'use this when...' framing, no mention of which mode selects which parameter combination, and no exclusions pointing to sibling tools. An agent must infer mode selection from the enum 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuinely non-redundant behavior: the rate is fixed at 15% and the operation is bidirectional, which the agent needs to interpret results. It does not say whether the response contains only the VAT amount or also the gross/net totals, which is a remaining 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?

A single front-loaded sentence covers purpose, both directions, and the 15% rate with zero padding. The trailing web-URL clause is promotional rather than operationally useful, which is the only thing keeping it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter deterministic calculator with full schema coverage and rich annotations, the description supplies everything needed to select and call it: the fixed rate, the two modes, and the meaning of the input amount. The absence of return-value detail is a minor gap only, since the operation is a trivial arithmetic transform.

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

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

Schema coverage is 100%: both `mode` (with its add/remove enum and default) and `amount` (SAR, minimum 0) are documented in the schema itself. The description restates the mode semantics in prose but adds no format, rounding, or edge-case detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: adding or extracting 15% Saudi VAT on a price, with both directions (net→VAT and VAT-inclusive→net) spelled out. It is clearly distinct from generic siblings like percentage_calculator or zakat by naming the exact tax and rate, though it never explicitly names an alternative tool.

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 stated through the two supported scenarios: a net price (add VAT) versus an already VAT-inclusive price (extract VAT), which maps directly onto the two modes. No explicit exclusions or redirection to sibling calculators (e.g. zakat, percentage_calculator) are given, so it stops short of full when/when-not 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?

Beyond the read-only and non-destructive annotations, it explains that the result is an estimate and discloses the tiered-rate calculation, wastewater at half the water rate, meter-size fees, and 15% VAT. It does not cover rounding, multi-home calculation behavior, or the level of detail returned.

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 purpose, tariff date, and main calculation components are front-loaded in one compact, information-dense sentence. The web-version URL is concise but adds little value for tool selection or invocation by an agent.

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?

Together with the fully described schema and its defaults, the description provides enough context to invoke this straightforward calculator correctly. With no output schema, some additional detail about the returned estimate or breakdown, rounding, and extra_homes behavior would make it more 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 100%, but the description adds useful computational meaning: meter size affects fixed fees, consumption is subject to tiered rates, and sewer-connected wastewater is charged at half the water rate. It does not explain how extra_homes changes the estimate, so it does not fully document every parameter's effect.

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 and resource: estimating an NWC residential water bill under the tariff effective 1 January 2027. Its water, wastewater, meter-fee, and VAT scope clearly distinguishes it from siblings such as saudi_electricity_bill and generic financial calculators.

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 residential NWC scope and tariff effective date give clear temporal and customer-context guidance for when to use it. It does not explicitly exclude commercial properties, other providers, or pre-2027 bills, but those boundaries are strongly implied.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the breadth of what is fetched and analyzed, including cross-cutting indexability signals (robots meta plus X-Robots-Tag). It still does not say whether redirects are followed or how unreachable pages are reported.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.