AgentStall: Africa and global data for agents

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the call is free of charge and the response surfaces pricing currency (USDC), payment network, and a sample result — exactly the information an agent needs to judge whether a paid tool is usable.

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 very short sentences, front-loaded with the cost fact and then the payload contents, with zero filler. Minor deduction: the fragment "Free." has no subject, leaving it momentarily ambiguous whether the catalog or the listed tools are free.

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

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

For a zero-parameter, read-only lookup with no output schema, the description covers what matters — cost and returned fields. It stops short of describing the catalog's shape (how many entries, whether payment details include addresses or amounts), which an agent planning a purchase flow would want.

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

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

There are zero parameters, so the baseline is 4; the schema is a closed empty object and nothing is required of the caller. The description correctly spends no space on parameters and instead explains the response payload.

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 ("Lists every paid tool") and details the fields returned: price in USDC, payment network, and an example result. This clearly separates it from the za_* utility siblings, though it never explains what a "stall" is, so the noun in the name stays slightly opaque.

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 leading "Free." is an implicit usage cue — this catalog costs nothing while the tools it enumerates are paid — but there is no explicit when-to-use statement, no mention of calling it before paying, and no exclusions relative to any sibling. The guidance is implied 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 readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context beyond that: data sources (registry WHOIS/RDAP and DNS), the specific signals returned, a regional focus on African banks, tax authorities and mobile money, and a concrete pricing model ($0.005 USDC per call via x402 on Base mainnet). It does not cover failure modes such as an unregistered domain or rate limits.

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 and data sources are front-loaded before use cases and pricing, and every sentence contributes information. The opening sentence is dense with enumerations but not padded, so the length is justified by the breadth of the lookup.

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 multi-source lookup tool with no output schema, the description adequately enumerates what comes back—registry data, DNS, email security and risk flags—plus the pricing model. The main missing piece is how this tool relates to the overlapping domain- and email-security siblings.

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

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

Schema description coverage is 100% and the single parameter's schema already gives examples ('example.com' or a full URL with path). The description adds no further parameter-level meaning, so the baseline of 3 for high-coverage schemas 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 states a specific verb and resource ('WHOIS / RDAP domain lookup') and enumerates the returned data: registrar, dates, age, status, nameservers, DNSSEC, DNS records, email security grade, and risk flags. It does not differentiate from closely related siblings such as za_official_domain_check or za_email_security, leaving the agent to infer which lookup to use.

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

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

It names three contexts ('phishing triage, vendor due diligence and research'), which gives implied usage guidance. However, it offers no when-not-to-use conditions and never references the overlapping sibling tools, so selection among alternatives is left to inference.

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

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

Annotations already cover readOnly, idempotent and closed-world behavior, so the description's added value is real: it discloses the data provenance (open daily dataset, mid-market, updated daily) and an explicit per-call cost of $0.002 USDC via x402 on Base mainnet, which materially affects whether an agent should call it. It does not cover rate limits, failure modes, or what happens when an unknown currency code is supplied.

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 and scope are front-loaded in the first clause, and the pricing note is placed last where it belongs. The long currency enumeration earns some of its space because it signals African-market coverage, but it is the one portion an editor could trim.

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

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

For a zero-required-parameter read-only lookup with no output schema, the description supplies what matters: currency coverage, data-source caveat, update cadence, and cost. The only material gap is that it does not hint at the response shape (a rate map keyed by symbol) or the default symbol set, though the schema's default note partly covers the latter.

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 three parameters (base, amount, symbols) are already documented in the input schema. The description restates 'any base currency, optional amount conversion' but adds no syntax, formatting, or default-behavior detail beyond what the schema provides; 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 gives a specific verb and resource (exchange rates and conversion) with explicit scope: 150+ currencies, any base, optional amount. It also distinguishes itself from a sibling by stating the rates are mid-market reference rates from an open daily dataset, 'not official central-bank fixings' — which separates it from za_sarb_rates without the agent needing to open either schema.

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

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

It names concrete use cases (pricing, invoices, reports) and implicitly excludes official-fixing use cases by noting the source is not central-bank fixings. There is no explicit 'use X instead when Y' routing statement, which keeps it below a 5, but the context is clear enough to select the tool confidently.

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 readOnly/idempotent annotations, the description discloses that weekends and public holidays are skipped, that skipped holidays are listed in the result, that local weekend conventions vary (Fri-Sat in SA/EG), and critically that calls cost $0.002 USDC via x402 on Base mainnet. The payment/metering detail is high-value context the annotations do not cover. It stops short of describing edge behavior (invalid country, out-of-range days).

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

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

Front-loaded with the core action and scope, then behavior, then use cases, then cost. Dense but each clause carries information; the pricing sentence is slightly awkward at the tail but is not filler.

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

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

For a three-parameter tool with full schema coverage and no output schema, the description covers what the tool does, what it returns (the skipped holidays), localization caveats, and the payment requirement. Only the error/failure modes are unaddressed.

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 meaning beyond the schema: 'adds or subtracts' explains that a negative 'days' value subtracts, and it reinforces country scope (220+ vs. the 11 verified calendars listed in the schema). The date-format and range details are left to the schema, which already handles them.

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 pair ('adds or subtracts working days') and resource ('business days from a date'), with scope quantified as 220+ countries and weekend/holiday-skipping behavior. It clearly differs from siblings like za_count_business_days and za_is_business_day by what it does to a date, though it never names those siblings explicitly.

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

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

Concrete use cases are supplied ('net 5 business days', notice periods, SLAs, delivery estimates, legal deadlines), which gives an agent a clear signal for when to reach for this tool. However, no when-not-to-use guidance or explicit routing to the sibling counting/checking tools is provided.

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

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

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds genuinely new behavior: a paid call at $0.001 USDC via x402 on Base mainnet, which an agent must know before invoking. It stops short of describing the shape of the returned record.

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

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

Front-loaded with the resource and the two operating modes; the ten-bank enumeration is long but earns its place by signaling exact coverage. The pricing clause is placed last, which is appropriate. Slight redundancy between 'for EFT payments' and 'completing payment details'.

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, no-output-schema lookup tool this is nearly complete: it names the domain, the banks, the two modes and the cost. The only real omission is what a lookup returns (bank name, universal code, or both), which an agent must discover by calling.

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

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

Schema coverage is 100% and the single parameter is already documented as an optional bank name or code. The description adds the key semantic the schema omits: that omitting the parameter yields the full list ('list all'), which tells the agent how to use the default case.

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 (South African universal branch codes) and an explicit verb pair ('Look up one bank or list all'), then enumerates the covered banks. No sibling tool covers branch codes, 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?

Gives a concrete use context: EFT payments and debit orders, and 'completing South African bank payment details'. It does not name exclusions or alternatives, but no sibling overlaps this domain, so the gap is small.

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, closed-world, so the bar is lower; the description still adds value by disclosing that weekends and public holidays are excluded, that local weekends are supported, that excluded holidays are returned, and that each call costs $0.002 USDC via x402 on Base mainnet — a pricing/authorization detail absent from all structured fields.

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

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

Core behavior is front-loaded in the first sentence, followed by scope, use cases and price. It is a bit padded — the country/calendar lists repeat what the country parameter description already provides — but no sentence is wasted in a way that misleads.

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 calculator with fully described parameters and no output schema, the definition covers what is counted, what is excluded, that excluded holidays are listed, and the cost of calling. Only the explicit routing against sibling date tools is missing.

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

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

Schema coverage is 100%, so the schema already documents from (exclusive), to (inclusive, within 5 years) and country codes. The description only restates country breadth ('220+ countries', verified African calendars) without adding format or edge-case semantics for the date parameters 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?

Opens with a concrete verb and resource: 'counts the business days between two dates in any of 220+ countries, excluding weekends and public holidays.' That is distinct from the sibling za_add_business_days (which shifts a date) and za_is_business_day (single-day check), though neither 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?

It supplies use cases ('SLAs, turnaround times, leave days and deadlines measured in business days'), which implies when the tool fits, but it never states when to prefer a sibling such as za_is_business_day or za_add_business_days, nor any exclusions or prerequisites.

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

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

With readOnly/idempotent annotations already covering safety, the description still adds real context beyond them: the data source ('from public DNS'), the response contents (score, A-F grade, spoofing-risk narrative, remediation list), the freshness of scorecards ('daily-updated'), country coverage, and non-trivial cost/access details ('$0.003 USDC per call (x402, Base mainnet)'). That price and payment-rail disclosure is exactly the kind of behavior an agent must know before invoking. It does not say what is returned for an unregistered or malformed domain, 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?

Two sentences, front-loaded with the primary capability and the secondary scorecard mode appended. Nearly every clause carries information (record types, output shape, cost, coverage). Minor waste in wordy phrasing such as 'says how easily fake email could be sent in the domain's name' where 'spoofing risk' would do, and the price clause sits in the same block as the capability 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?

There is no output schema, and the description does the required work by describing what comes back for both modes (score/A-F grade, spoofing assessment, fixes, ranked scorecards). Cost and data provenance are stated, which matters for a paid, read-only lookup. The one unexplained case is a call with no parameters at all — since no parameters are marked required, an agent has no way to know whether that errors or returns a default scorecard.

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 per-parameter meaning is already supplied; baseline is 3. The description adds only marginal semantic value — it names the subject matter of sectors ('banks, governments, regulators and telecoms') and roughly the country footprint, but it does not explain the sector/country interaction or that sector defaults to 'all'. Its 'and 6 more African countries' is also slightly out of step with the 12 codes listed 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 first clause names a concrete verb and resource ('DMARC and SPF checker for any domain') and enumerates the record types graded, so an agent immediately knows the capability. It also distinguishes two distinct return modes (single-domain check vs. country scorecard). It does not, however, contrast itself with the plausible siblings domain_intel or za_official_domain_check, so an agent choosing between domain-lookup tools gets no routing help.

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 clearly frames two usage contexts: 'for any domain' for the checker, and 'Also returns daily-updated email security scorecards ranking banks, governments, regulators and telecoms' for the aggregate mode. The schema descriptions reinforce the either/or ('Leave empty when checking a domain... For a ranked scorecard instead'). What is missing is any exclusion guidance — nothing says when to prefer za_official_domain_check or domain_intel over this 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 declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context not in annotations: the per-call price ($0.01 USDC, x402 on Base mainnet), which matters for invocation, and the liability caveat ('triage guidance, not legal advice') which signals the output is indicative. It does not spell out output structure beyond the summary sentence, but that is acceptable 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?

The description is front-loaded with scope and jurisdiction list, then moves to outputs, caveat and price in a sensible order. The country enumeration partially duplicates the schema's country-code parameter, and the specific regulatory acronym list is dense, but each clause carries signal. No filler sentences.

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 must indicate returns, and it does: notifiable parties, deadline and computed due time. Payment mechanics and the non-legal-advice caveat are disclosed, which an agent needs before calling a paid x402 endpoint. The only gap is that conditional parameter interplay (sector only for ZA, material/classified_at only for financial institutions) is left entirely to the 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 every one of the 9 parameters documented in detail, including conditional applicability ('Financial institutions: ...', 'South Africa only', 'ISO 8601; no offset = UTC+2'). The description adds no parameter-level meaning beyond that, so the baseline 3 applies. It also does not state that all parameters are optional or that country drives which other fields matter.

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

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

The description names the resource precisely (data breach and cyber incident reporting obligations across 11 named jurisdictions) and states what it returns: notifiable regulators/parties, the legal deadline (e.g. 72 hours) and a computed due time from discovery. It also names the specific regimes (POPIA, FSCA/PA, NDPA, ngCERT, Kenya DPA), which no sibling tool covers. The verb is nominal rather than imperative, but an agent can still tell exactly what the tool produces.

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 rather than stated: an agent infers it is for post-incident triage, and the closing line frames it as 'triage guidance, not legal advice,' which is a useful scope limit. There is no explicit when-to-use/when-not-to-use framing and no named alternative, though no sibling appears to overlap. The default values (country ZA, role responsible_party, sector general) live in the schema rather than the description.

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, and closed-world behavior, but the description adds substantial value: it specifies the return content (reason, next/previous business days), documents local weekend handling (Friday–Saturday in Saudi Arabia, Egypt, Israel), observed holidays, verified calendars for named countries, and even the per-call price.

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 function is front-loaded, and every clause adds useful information. However, the description is one long sentence with many clauses, so readability could be improved by splitting it into two or three sentences.

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 fully explains what the tool returns and covers important edge cases like non-standard weekends and observed holidays. Nothing essential for an agent to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents date format and country code examples. The description adds no parameter-specific syntax or constraints beyond what the schema provides, making the 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?

States a specific verb ('Checks whether a date is a business day'), the resource (a single date), and scope (220+ countries). It also clarifies the result includes the reason and adjacent business days, which distinguishes it from sibling tools like za_count_business_days or za_add_business_days.

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 use cases (payment, settlement, delivery dates) but does not explicitly say when to choose this over za_count_business_days or za_add_business_days, nor does it state when not to use it. Usage is implied rather than directed.

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, closed-world), and the description adds genuinely new context: the paid x402/Base mainnet cost of $0.001 USDC per call and the specific classification vocabulary returned. It omits what happens on an unparseable or non-SA number, which leaves a real gap for a tool marketed as validation.

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 the first sentence, with use cases and pricing following. Dense and largely waste-free, though the pricing clause is bolted on rather than integrated.

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 mostly does: it lists both output formats and the classification categories including area lookup for major cities. The missing piece is error/invalid-input behavior, which matters for a validation tool.

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

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

Schema coverage is 100% and the single 'number' parameter already carries an example. The description's phrase 'any common format' reinforces tolerance of varied input syntax but adds no format rules beyond what the schema shows, so baseline 3 applies.

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

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

States a specific verb and resource: formatting (to E.164 +27 and local) plus classification (mobile, landline with city area, toll-free, VoIP, premium-rate). This clearly distinguishes it from the sibling validators, which target ID numbers, tax numbers, company numbers and domains rather than phone numbers.

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

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

Names concrete contexts where the tool is the right pick: cleaning contact lists, SMS/WhatsApp messaging, form validation. It does not name an alternative tool or state exclusions, so it falls short of the explicit when/when-not routing a 5 requires.

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, openWorldHint=false), and the description adds genuinely new operational context: the check flags lookalikes, typosquats, brand names in unofficial domains and newly registered domains, spans roughly 130 tax authorities and 11 African countries, and carries a per-call cost of $0.005 USDC via x402 on Base mainnet. That pricing and authentication detail is exactly the kind of behavior an agent needs before deciding to call a paid endpoint.

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

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

It is effectively one long but well-ordered sentence that leads with the core purpose and then layers scope, detection capabilities and pricing. The brand examples (SARS, KRA, M-Pesa) are repeated between the title and the description, which is mild redundancy, but nothing is padded or wasted.

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

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

For a one-parameter read-only lookup the description covers scope and cost well, but with no output schema it never describes what a call actually returns — a verdict, a confidence flag, the matched official domain, or a list of anomalies — which leaves the agent unable to anticipate the response. Country coverage is also fuzzed as 'South Africa and 10 other African countries', so the boundary of applicability is only approximate.

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 and schema description coverage is 100%, so the schema already defines `url` and supplies examples. The description restates that it accepts a link or domain but adds no format constraints, normalization rules, or handling of bare domains versus full URLs beyond what the schema shows, 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 and resource — a phishing URL and fake-website check that compares a link or domain against official domain lists — and enumerates the covered sectors and regions. It does not, however, distinguish itself from the sibling domain_intel, whose name suggests overlapping domain-reputation functionality, so an agent cannot fully rule out the alternative from the text alone.

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

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

Usage is only implied: the tool is clearly framed as a link-safety check for African banking, tax and mobile-money domains, so an agent can infer the right call context. There is no explicit when-not-to-use statement, no mention of when to prefer domain_intel, and no guidance on what to do with the verdict.

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 that the tool is read-only, idempotent, and closed-world. The description adds meaningful behavior beyond that: pricing and payment rail, data provenance from Nager.Date and date-holidays, verified African calendars with observed days and declared Islamic holidays, and the returned date/name fields. It does not mention rate limits or error behavior, so it stops short of full transparency.

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 the first sentence, and the remaining sentences add coverage, data-source, use-case, and pricing context. It is somewhat list-heavy and repeats coverage information across geographic enumerations, but the structure remains readable and no sentence is entirely irrelevant.

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 full schema coverage and annotations, the description supplies the main missing context: payment cost, geographic scope, verified calendar distinctions, and returned fields. It would be stronger if it explicitly noted the year-range limitations or routed agents to related business-day tools, but it is broadly 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%, and the schema already documents the year ranges, ISO country codes, default country, and verified-country list. The description only broadly restates country and year coverage, adding no parameter-level syntax or constraints beyond the schema. It even says 'any country and year,' which is looser than the schema's explicit ranges, but the schema carries the precise 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?

The description clearly states a specific resource and scope: public holidays for a country and year, returning dates and English names. It is easy to distinguish from validation or business-day tools by subject matter, but it does not explicitly contrast itself with siblings such as za_is_business_day or za_count_business_days.

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

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

The description gives implied use cases such as scheduling, payroll, and deadlines. However, it does not state when to use this tool instead of related siblings, nor does it mention exclusions or conditions for choosing holiday listings over business-day 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 openWorldHint=false, so safety is covered; the description adds genuinely new behavioral context beyond them. It discloses the cost model ($0.005 USDC per call, x402 on Base mainnet) and that every value carries an as-of date, which matters for freshness judgments. It does not state whether responses are cached or how stale the underlying SARB data can be, keeping 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?

It is front-loaded with the resource and data series before the use cases and the price disclosure, and every clause carries information. The single dense sentence listing rates and currencies is slightly hard to scan, but there is no filler or repetition.

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

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

With no parameters, no output schema and read-only annotations, the description only needs to say what comes back and under what terms, and it does both by enumerating the series and the per-call price. The remaining gap is the response shape — whether rates and FX come back as one combined object or separate blocks — which matters slightly more given there is no output schema to fall back on.

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 there is no parameter semantics to explain and the baseline of 4 applies. The description correctly avoids inventing or implying any filtering inputs, matching the empty 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 specific resource and enumerates the exact data series returned (repo rate, prime lending rate, CPI, PPI, ZAR per USD/GBP/EUR/JPY) plus the authoritative source (SARB). That is far more precise than a tautology. It stops short of a 5 because it never contrasts itself with the sibling `exchange_rates` tool, so an agent must infer which one to pick for FX data.

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?

"Useful for loan and interest calculations, pricing in rand and economic context" implies the intended use cases but gives no explicit when-to-use rule and no when-not-to-use rule. The presence of the sibling `exchange_rates` tool makes the absence of routing guidance a real gap, since an agent could reasonably call either for rand rates.

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 annotations (readOnly, idempotent, closed-world), the description discloses two real behavioral traits: deadlines are pre-shifted to the previous business day per SARS rules, and each call costs $0.005 USDC via x402 on Base mainnet. It omits the response shape (e.g., whether entries carry labels/types), 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?

Coverage is front-loaded in one sentence listing the deadline types, followed by a short audience note and a pricing note; every clause carries information. No filler or repetition of the schema.

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

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

For a read-only, two-optional-parameter query with no output schema, the definition covers scope, date handling, business-day shifting and cost. The only meaningful gap is that it never indicates what a returned deadline entry looks like (date plus obligation label), which would help an agent use the 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 schema already documents defaults, the YYYY-MM-DD format and the 400-day cap for 'from'/'to'. The description only restates 'between two dates' and adds no date semantics 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?

States a specific resource and scope: SARS tax deadlines returned between two dates, and enumerates the covered obligation types (EMP201, VAT201, IRP6, EMP501, filing season). This clearly separates it from siblings like za_public_holidays or za_add_business_days without needing 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?

Gives concrete usage context ('payroll, bookkeeping, accounting and tax compliance reminders in South Africa'), making the applicable scenario obvious. It does not name alternatives or exclusions (e.g., when to prefer za_public_holidays or za_add_business_days), so it stops short of 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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the authoritative data source, the covered year range with 'special school holidays' as a distinct data category, and per-call pricing on x402/Base mainnet, which an agent needs before invoking a paid tool.

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

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

Two sentences, front-loaded with the resource and scope before the use cases and the billing note. The pricing sentence is short and earns its place as operational detail; nothing is padded 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 only two optional parameters and no output schema, the description carries the burden of explaining returns, which it does at a category level (term dates, holidays, special holidays, boolean school-day result). An agent could decide and invoke correctly, though it does not say how terms and holidays are structured in 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%, so both the 'date' (YYYY-MM-DD, school-day check) and 'year' (2026-2027, defaults to the date's year or current year) parameters are already fully documented. The description restates the two capabilities but adds no format, precedence, or combination semantics beyond the schema, so the baseline 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 first sentence names a specific resource (South African public school term dates and holidays for 2026-2027) plus the source (Department of Basic Education) and the conditional lookup ('whether a given date is a school day'). It is clearly distinct from services like za_public_holidays or za_is_business_day, though it never names those siblings to make the distinction explicit.

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

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

Usage is implied through use-case framing ('useful for family travel, childcare, events and education planning in South Africa') rather than stated as when-to-use rules. It gives no exclusions or routing guidance, e.g. it never says to use this instead of za_is_business_day or za_public_holidays when the question is about business vs school days.

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, closed-world), and the description adds meaningful context beyond them: data freshness (updated every 3 hours), source provenance (National Treasury eTenders portal), and a paid access requirement ($0.005 USDC per call via x402 on Base mainnet). The payment detail is important operational context an agent would otherwise miss. It stops short of describing pagination limits or failure modes, so not a 5.

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

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

Front-loaded with the resource and scope, followed by filters, return fields, freshness, and cost — a logical order with no filler. Slightly dense as a single run-on sentence, but every clause carries information.

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

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

With no output schema, the description compensates by enumerating the returned fields (tender number, description, buyer, procurement method, dates, document links). Combined with the freshness and pricing notes, an agent has enough to decide and invoke correctly; only pagination/result-volume behavior is unaddressed.

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 every parameter including defaults and ranges. The description only summarizes the filter dimensions (keyword, closing date, category, buyer) without adding syntax or format detail 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?

States a specific verb and resource — searching open South African government tenders and RFQs from the National Treasury eTenders portal — and names the exact coverage (national/provincial departments, municipalities, SOEs). No sibling tool in the list does anything similar, 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?

Gives clear context for when the tool applies (open tenders/RFQs from SA public bodies) and lists the filtering levers an agent would use. It does not state exclusions or point to an alternative, but no sibling overlaps, so the practical guidance is sufficient.

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/closed-world, so the description focuses on what annotations cannot convey: it discloses a per-call price and payment rail ($0.002 USDC, x402, Base mainnet) and explicitly limits scope to offline format validation with no registry status check. It does not describe the negative-result shape (what an invalid number returns), 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?

Front-loaded with the core action and format, followed by scope limit, use cases, and pricing in a tight sentence chain. Dense but every clause carries information; the pricing clause could be considered boilerplate but is operationally relevant.

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, non-destructive validation tool with no output schema, the description covers input format, decoded outputs, scope limitation, and cost — enough to call it correctly. Only the shape of a failed validation is 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?

Only one parameter and schema coverage is 100%, so the baseline is 3. The description restates the expected format YYYYY/NNNNNN/NN, which is a modest enrichment over the schema's single example value, but adds no further semantics such as tolerance for spaces or slashes.

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 ('validates a CIPC registration number') plus the exact format pattern (YYYY/NNNNNN/NN) and what it returns (registration year and entity type). The resource is clearly distinct from the sibling validators za_validate_id_number and za_validate_tax_number, so an agent can route correctly 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?

Gives concrete usage contexts (supplier onboarding, invoices, tender paperwork) and an explicit exclusion: 'Format check only, not a CIPC status lookup.' It does not name an alternative tool for status lookups, so it stops short of full when/when-not routing, but the boundary of applicability is clear.

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 openWorldHint=false, yet the description still adds three traits the agent could not infer: there is no Home Affairs registry lookup, the input number is not stored, and each call costs $0.005 USDC via x402 on Base mainnet. Those scope, privacy and billing facts are exactly the context an agent needs before invoking a paid KYC check.

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

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

Three front-loaded sentences: capability first, scope limitation second, use cases and price last. Every clause carries information — encoding details, limitation, privacy, cost — with no filler or repetition of the title.

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

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

There is no output schema, so the description compensates by enumerating the decoded return fields (date of birth, age, gender, citizenship status). Combined with the scope, privacy and pricing disclosures, nothing material is missing for a one-parameter, read-only validation tool.

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

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

Schema coverage is 100% and the single parameter is already described as a '13-digit SA ID number', so the baseline is 3. The description adds meaning by explaining what the number encodes (date of birth, citizenship digit, Luhn checksum), which tells an agent the expected format and what validation will actually test.

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 ('validates' a '13-digit SA ID number' and 'decodes date of birth, age, gender and citizenship status'), and the 'Structural check only, with no Home Affairs lookup' clause separates it from sibling validators like za_validate_company_number and za_validate_tax_number. An agent can distinguish it from every sibling without opening a schema.

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

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

It states clear usage contexts ('KYC and onboarding forms', 'catching typos'), which gives an agent a concrete trigger. It stops short of naming an alternative or an explicit when-not condition, but the 'structural check only, no Home Affairs lookup' caveat effectively rules out use cases where registry verification is required.

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 read-only, idempotent, closed-world behavior, and the description adds what really matters here: format-only validation with no registry query, no data stored, and a per-call price of $0.002 USDC via x402 on Base mainnet. The cost/payment requirement is behavior an agent must know before calling, and it is disclosed plainly.

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

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

Front-loaded with what is validated, followed by limit, use cases, and price. Every sentence carries distinct information and nothing is repeated from the schema.

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

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

For a single-parameter, read-only validation tool this is nearly complete: input shape, validation depth, limits, use cases, and cost are all covered. Without an output schema, the exact response shape (e.g., validity flag plus detected type) is only partially implied by 'says which type it is.'

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 schema already says spaces, dashes and slashes are ignored. The description adds the 10-digit length constraint and clarifies that either a VAT or income tax number is accepted and the type is identified in the response, which is useful meaning 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?

Specific verb+resource: validates a South African 10-digit SARS VAT or income tax reference number and reports which type it is. The scope is clearly distinct from sibling validators like za_validate_id_number and za_validate_company_number, and the check method (format plus modulus-10 check digit) is 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?

Gives concrete usage contexts (invoices, supplier onboarding, form validation) and an explicit exclusion: this is a format check, not a SARS registration lookup. It does not name an alternative tool for a real registry lookup, but the when-not guidance is clear.

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