Qiniso

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

No annotations are provided, so the description carries the full burden. It explains locale-specific formatting (symbol position, separators) and gives an example, but does not specify return format or edge cases. Acceptable for a non-destructive formatting 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 plus an example, with no wasted words. Front-loaded with the imperative 'USE THIS'. Every part is informative.

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

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

The tool has three parameters and no output schema. The description explains the core functionality and provides a clear example. It does not describe all possible locales or currencies, but is sufficient for the task.

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 description adds valuable context: locale defaults from currency, currency defaults to GBP, and the example clarifies usage. This goes beyond the schema's property descriptions.

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

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

The description clearly states the verb 'format' and the resource 'money amount', with an explicit example showing input and output. It is distinct from sibling tools which are all validation 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 description indicates when to use ('before showing it in a price, invoice or email') but does not explicitly state when not to use or provide alternatives. However, siblings are all validation tools, so no confusion.

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

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

With no annotations provided, the description carries full burden. It discloses supported scope (~200 countries, default GB, subdivision) but omits what the tool returns (e.g., boolean or holiday name). This is a moderate gap for a simple lookup 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, no wasted words. The first sentence front-loads purpose and context; the second adds critical parameter details. Every sentence earns its place.

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

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

Given the tool's simplicity and 100% schema coverage, the description is largely complete. It covers usage context, parameter meanings, and scope. The missing return value description is a minor gap but does not hinder understanding for typical use.

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 description adds meaningful context to all three parameters: explains the required 'date' format, the default for 'country', and how 'subdiv' narrows results with examples. This goes beyond the schema's generic descriptions, enhancing understanding.

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 defines the tool's purpose: checking if a date is a public/bank holiday for business-day deadline calculations. It specifies the verb 'check', resource 'date', and distinct context 'business-day deadlines', distinguishing it from sibling tools like 'next_holiday' and various validators.

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 explicitly states when to use the tool ('when computing business-day deadlines, delivery SLAs or next working day'), providing clear context. It doesn't exclude alternatives or specify when not to use, but the guidance is strong for its intended use case.

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

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

With no annotations, the description carries full burden. It explains the core functionality and parameter defaults, but omits details on return value format, error behavior (e.g., no holiday found), and potential limitations (e.g., date range restrictions).

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 concise sentences, front-loaded with 'USE THIS', and includes key details without extraneous text. Every sentence serves a purpose.

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

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

While the description explains what the tool does and how to use parameters, it fails to mention the output shape (e.g., returns a date string). Given no output schema, this omission reduces completeness for an agent.

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 value by clarifying that country codes are ISO (with examples) and that subdivision narrows to a region. This enriches understanding beyond the bare schema descriptions.

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

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

The description clearly states the tool finds the next public/bank holiday on or after a date, with a concrete use case ('to find the next working day'). It distinguishes from sibling 'is_holiday' by emphasizing forward-looking search rather than checking a specific date.

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

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

The description begins with 'USE THIS', explicitly guiding when to apply the tool, and provides an example context. However, it does not explicitly mention alternatives like 'is_holiday' for checking a single date, leaving some ambiguity.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool works for UK or US addresses only, returns a confidence flag, and outputs structured components. It does not detail failure modes or rate limits, but for a simple parsing tool it provides adequate 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?

The description consists of two focused sentences, front-loaded with a clear imperative ('USE THIS'). Every sentence contributes essential information: purpose, use cases, constraints, and 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?

Given the tool's simplicity (one param, no output schema, no annotations), the description covers purpose, use cases, constraints, and return structure. It could mention error behavior, but overall it is sufficiently complete for an agent to decide when to use it.

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 a single parameter described as 'The free-text address.' The description adds value by specifying that the input should be a UK or US address, which goes beyond the schema's generic description.

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

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

The description specifies the verb 'extract' and the resource 'structured {country, postcode, city, state}' from free-text addresses, clearly distinguishing it from sibling tools which are primarily validation/formatting tools. No other address-parsing sibling exists.

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

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

The description explicitly states when to use: 'when onboarding a user, running a KYC/fraud check, or storing an address' and advises against manual string splitting. It does not explicitly exclude non-UK/US addresses or mention alternatives, but the use cases are 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?

No annotations are present, so the description fully bears the burden. It discloses that the tool returns 'valid:false' for impossible dates, which is key behavioral information. However, it lacks details on other potential behaviors like error handling or format preferences.

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 consists of two efficient sentences. The first sentence front-loads the purpose and usage context, while the second adds critical behavioral detail. No unnecessary words 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?

The tool has a simple input schema with no output schema. The description mentions a return field ('valid:false') for impossible dates, which is adequate for a parse tool. It does not detail all return values, but given the tool's straightforward nature, this is sufficient.

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

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

The schema already describes both parameters with 100% coverage. The description adds value by explaining the locale values ('en-GB' vs 'en-US') and their meaning for day-first vs month-first interpretation, which goes beyond the schema's basic description.

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

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

The description clearly states the tool's purpose: interpreting human-written dates into ISO 8601, especially ambiguous numeric dates. It uses a specific verb ('interpret') and resource ('date'), and distinguishes itself from sibling tools that are primarily validation-focused.

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 explicitly advises to 'USE THIS' for ambiguous dates and explains the locale parameter's role in disambiguation. It provides clear context for when to invoke this tool, though it does not explicitly state when not to use it or mention 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?

With no annotations, the description fully explains behavior: GB returns historical/temporary rates, US returns 0 for national but state rates available. It highlights date-sensitivity. Could mention what happens with invalid dates or missing state for US, but overall good.

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

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

Three short sentences, no filler. The first sentence commands attention with 'USE THIS'. Every sentence carries essential information. Very 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?

Given 3 optional params, no output schema, and a moderately complex domain (tax rates differ by country/date), the description covers purpose, usage, and key behaviors. It could mention the return format or what happens if no rate exists, but it's still very 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 description adds crucial semantics: default country is GB, date defaults to today, state is for US sales tax. It also gives usage guidance ('Always pass invoice date for GB'). This significantly enhances understanding beyond 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 clearly states it retrieves VAT/sales tax rates for GB and US. It specifies the exact resource (tax rate) and the verb (retrieve/get) implicitly. It distinguishes from siblings by being the only tax-related tool among validation/formatting 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?

Explicitly says 'USE THIS before calculating VAT or sales tax' and warns against relying on memory. It provides clear context for GB (date-sensitive, must pass invoice date) and US (no national VAT, pass state code). No alternatives are needed as it's the sole tax 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?

With no annotations provided, the description fully discloses the tool's behavior: it validates structure using Verhoeff and leading-digit rules, and explicitly states it does not perform a lookup. This is transparent about both capabilities and limitations.

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 extremely concise (two sentences) and front-loaded with the imperative 'USE THIS'. Every sentence adds meaningful information without redundancy or waste.

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

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

The description explains what the tool does and its limitations, which is sufficient for an agent to decide when to use it. However, it lacks explicit mention of the output format (e.g., boolean, error message), which would be helpful since no output schema is provided. Still, the core context is well covered.

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 input schema already describes the 'aadhaar' parameter well (100% coverage), but the description adds value by noting that spaces are ignored, which is not in the schema description. It also provides context about what checks are performed on the parameter value.

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

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

The description clearly states that the tool verifies the format and checksum of an Indian Aadhaar number using the Verhoeff algorithm and leading-digit rule. It distinguishes itself from sibling validation tools (e.g., validate_btc_address, validate_card) by specifying the unique Aadhaar-specific checks.

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 explicitly tells the agent when to use this tool ('USE THIS to verify...') and includes an important caveat ('never assume 12 digits are valid'). It does not provide direct exclusions or alternatives, but the sibling tool list implies that other validation tools cover different identifier types.

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

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

With no annotations, the description carries full burden and excels. It explicitly states that validation is structural only, not verifying whether the number is actually issued. It also mentions handling the born-from-2000 rule, a specific behavioral detail. This transparency helps the agent understand limitations.

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 sentences, concise and front-loaded. The first sentence commands usage, the second provides technical details. Every word is necessary; no fluff 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?

For a validation tool with one parameter and no output schema, the description is complete. It covers what the tool does, what it checks, and its limitations. The agent has all necessary information to decide when and how to use it.

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

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

Schema coverage is 100% for the 'nrn' parameter, but the description adds significant meaning: it identifies the number as Belgian National Register Number, specifies the checks performed, and notes that punctuation is ignored. This goes beyond the schema's basic description.

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

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

The description clearly specifies the tool's purpose: verifying a Belgian National Register Number. It explicitly mentions the type of number, the checks performed (11-digit form, mod-97, born-from-2000 rule), and that it validates structure only. This distinguishes it from sibling validation tools for other countries or formats.

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 starts with 'USE THIS to verify... before relying on it,' providing clear guidance on when to use. It does not explicitly state when not to use it, but the context of sibling tools (many validate_* for specific formats) implies it is only for Belgian NRN. No alternative tools are mentioned, but the usage context 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?

No annotations are provided, so the description carries full burden. It discloses that validation is structural only, not issuance confirmation. While it covers the key behavioral trait, it lacks details on return value or error handling, but for a simple validation tool, this is adequate.

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 sentences long, front-loaded with 'USE THIS', and contains no unnecessary words. Every sentence adds 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 simple validation tool with one parameter and no output schema, the description is reasonably complete. However, it does not mention what the tool returns (e.g., boolean or result object), which would be helpful for an agent to interpret the 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 coverage is 100% and the schema already describes the parameter format. The description does not add significant semantic meaning beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states the tool validates a Dutch BSN and specifies the checks performed (8-9 digit form and 11-test). It distinguishes itself from other sibling validators by naming the specific standard.

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 explicitly tells when to use the tool ('verify a Dutch BSN before relying on it') and what it does not do ('does NOT confirm the number is issued'), providing clear context for when to rely solely on 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?

With no annotations, the description carries the full burden. It discloses the validation algorithms (Base58Check, double-SHA256, Bech32/Bech32m) and return fields (type and network). It does not mention any destructive effects (none expected) or rate limits, but for a read-only validation tool this is sufficient. It could be slightly more detailed about return format.

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 three sentences, front-loaded with the imperative 'USE THIS to verify...'. Each sentence adds essential information: purpose, validation specifics, and practical tip. No unnecessary words.

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

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

For a simple tool with one parameter and no output schema, the description covers the validation scope, return fields, and a usage hint. It is missing an explicit statement about the return format (e.g., JSON structure), but the agent can infer the return includes type and network based on the description. Given the low complexity, this is nearly 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 schema already covers the parameter with 100% coverage, so baseline is 3. The description adds value by specifying the address formats (P2PKH, P2SH, SegWit, Taproot) and the return information (type and network), which supplements 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 clearly states the tool's purpose: verifying a Bitcoin address before sending or storing. It specifies the exact checks performed (Base58Check, Bech32/Bech32m) and the return information (address type and network), distinguishing it from sibling validation 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 description explicitly says 'USE THIS to verify a Bitcoin address before sending funds or storing it' and advises not to assume validity. It also provides a specific insight: 'A bad checksum means a mistyped address.' This gives clear when-to-use guidance and interpretation of results.

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?

Without annotations, the description fully discloses behavior: Luhn check, brand detection, length check, and explicitly states what it does NOT do (real/active/funds). No contradiction.

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 'USE THIS', no wasted words. Ideal for quick agent comprehension.

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

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

No output schema, but the description covers input and behavior. Missing return format hint, but given simplicity, it is mostly 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?

With 100% schema coverage, the description adds value by noting that spaces and dashes are ignored, which is not in the schema description. Could be slightly more detailed about format, but sufficient.

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 the tool validates payment card number structure, checks Luhn checksum, detects brand from BIN, and checks length. It distinguishes itself from other sibling validation tools by specifying its scope.

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

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

Explicitly instructs to use before assuming validity, and clarifies that it does not verify real/active/funds. Provides clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description fully carries the burden. It transparently discloses that the tool validates structure and check digit, not registration, and mentions the check character may be 'X'. No contradictions.

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 sentences, front-loaded with a clear directive. Every sentence is essential, with no unnecessary words 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?

For a simple validation tool with one parameter and no output schema, the description covers input format, validation scope, and limitations comprehensively. No 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 100% for the single parameter. The description adds value by reinforcing the format (18 characters, 17 digits + check) beyond the schema's description, which also covers it. This provides useful context for the agent.

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 it verifies a Chinese Resident Identity Card number, specifying the standard (ISO 7064 MOD 11-2) and the scope (structure validation only). It distinguishes this tool from siblings targeting other country-specific IDs.

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 explicitly says 'USE THIS to verify' and warns against guessing the check character. It also clarifies limitations (structure only, not registration). However, it does not explicitly state when not to use this tool or suggest alternatives, though the sibling list implies context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the algorithm (mod-11 check digits) but does not specify whether the check is local or remote, or mention any side effects, permissions, or return format. Adequate but has gaps.

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 sentences with no wasted words. It front-loads the imperative 'USE THIS' and conveys the purpose and key behavior efficiently.

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

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

For a simple one-parameter validation tool with no output schema, the description is mostly complete: it tells what it does, how it works, and when to use. It does not mention the return value, but given the typical nature of validation tools, this is a minor omission.

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 a clear description for the 'cnpj' parameter. The tool description adds the fact that validation uses mod-11 check digits, but does not add substantial meaning beyond the schema. 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 clearly states the verb 'verify' and the specific resource 'Brazilian CNPJ (company registration number)', and distinguishes it from sibling validation tools like validate_cpf and validate_aadhaar by specifying the country and entity type.

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 explicitly says 'USE THIS' for verifying CNPJ, provides context for onboarding Brazilian businesses, and implies it should be used instead of trusting raw input. However, it does not mention when not to use or list alternatives like validate_cpf for individuals.

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

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

No annotations provided, but description fully discloses that it validates structure only and does not confirm registration. No contradictions.

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, purpose first, no extraneous information. Efficient and readable.

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

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

For a simple validation tool with one parameter and no output schema, the description covers input constraints, validation scope, and limitations completely.

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 description for 'code' parameter. Description adds 'mod-26 check character' and emphasizes format, adding value beyond 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?

Description clearly states it verifies an Italian Codice Fiscale by checking format and check character, and distinguishes from registration confirmation. Verb 'verify' and specific resource 'Codice Fiscale'.

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?

Directs to use before relying on the code, and advises against guessing the check letter. Does not explicitly state when not to use or name alternatives, but the scope 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?

The description discloses the validation algorithm (mod-11 check digits and rejection of all-identical sentinels), providing useful behavioral insight beyond the 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 description is concise with two sentences, front-loaded with the imperative 'USE THIS', and contains no unnecessary words.

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

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

While the description lacks return value details, for a validation tool with no output schema, the algorithmic explanation and use case provide sufficient context for an agent to understand what the tool does.

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 describes the parameter adequately. The description does not add additional parameter-level details beyond what is 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 explicitly states 'verify a Brazilian CPF (individual taxpayer ID)' with a clear verb and resource, distinguishing it from sibling validators like validate_cnpj.

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 advises to call this before relying on a CPF and specifies the context (KYC/onboarding), but does not explicitly mention when not to use or alternative tools.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool checks the check digit and returns the expected digit on failure. However, it does not specify the return value on success (e.g., boolean, or null, etc.), leaving important behavioral details ambiguous.

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 sentences, front-loaded with a direct instruction ('USE THIS'), and every clause adds value. No redundant information.

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

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

For a simple, single-parameter validation tool with no output schema or annotations, the description covers the core behavior and failure case. It would benefit from noting success return format, but it is still adequate for agent decision-making.

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% (the single parameter 'cusip' has a clear description). The tool description adds no additional parameter semantics beyond the schema, so 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 clearly states that the tool verifies a CUSIP by checking the mod-10 check digit, and it specifically contrasts with simple 9-character acceptance. This is a specific verb-resource pair that distinguishes it from other validation 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 description explicitly says 'USE THIS to verify a CUSIP... instead of trusting 9 characters', which gives clear context for when to use it. It does not mention when not to use it or alternatives, but the sibling tools are all different identifier validations, so usage is well 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?

Describes the validation algorithm (mod-23 check) and output type (DNI/NIE), but lacks details on error handling, authentication, or side effects. With no annotations, the description carries the burden and is adequate but minimal.

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

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

Two concise sentences with an imperative start; no unnecessary words.

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

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

Covers the core functionality and algorithm sufficiently for a simple validation tool, but lacks explicit return format details (e.g., object structure) since there is 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 coverage is 100% and the description adds value by explaining the algorithm and return type, going beyond the schema's parameter description.

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

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

Clearly states the verb 'verify' and specific resource 'Spanish DNI or NIE', distinguishing it from sibling validation tools for other identifiers.

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

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

Explicitly advises using this tool before relying on the ID and warns against guessing the control letter, providing clear usage context. No explicit exclusions for other ID types.

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

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

With no annotations, the description carries full burden. It discloses that it catches invalid labels and made-up TLDs, and returns the TLD and whether it is known. This is adequate for a simple validation tool, though it could clarify if any network requests are made.

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 'USE THIS', uses two sentences, and contains no fluff. Every sentence adds value, making it highly 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?

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description covers all necessary aspects: purpose, input, output, and examples. It is complete for the complexity level.

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 a single parameter. The description adds example ('example.com') and explains the purpose, which reinforces the schema but does not add significant new semantic meaning beyond the schema description.

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

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

The description clearly states the tool verifies domain structure and TLD validity, with examples of invalid TLDs. However, it does not explicitly differentiate from sibling validators like validate_tld or validate_url, leaving some ambiguity.

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

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

The description provides clear when-to-use guidance ('instead of assuming a domain is legitimate') and explains what it catches. It does not explicitly mention when not to use it or reference alternatives, but the context is appropriate.

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

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

With no annotations, the description carries full burden. It discloses validations (local part, domain per RFC subset, TLD flagging) and explicitly states deliverability is not checked. This is transparent but could be enhanced by noting case handling or whitespace trimming.

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 no wasted words. The 'USE THIS' imperative front-loads purpose. Extremely concise yet informative.

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 single-parameter tool with no output schema, the description covers purpose, validation scope, and limitations. However, it does not specify the return format (e.g., boolean, errors), which would improve completeness.

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 the 'email' parameter. The description adds context about the validation performed but does not add new semantics 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 clearly states the tool validates email syntax and TLD, distinguishing it from siblings like validate_domain or validate_tld. It uses specific verb 'check' and mentions RFC standards, making the purpose unambiguous.

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

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

The description explicitly says 'USE THIS to check... before saving or sending — instead of trusting raw input,' providing clear usage context. It also explicitly states what it does NOT check (deliverability), helping avoid misuse.

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?

Without annotations, the description fully explains behavior: validates format and EIP-55 checksum, returns correctly-checksummed form. Warns about irreversible loss from wrong characters, which is critical safety information.

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 concise, front-loaded sentences. Every sentence adds value: usage guidance, behavioral details, and consequence. No redundancy or fluff.

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

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

For a simple validation tool with no output schema, the description covers purpose, usage, behavior, and consequences. Lacks explicit return format or error handling, but sufficient for correct invocation.

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

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

Schema coverage is 100%, so the parameter is already well-documented. The description adds a warning about consequences of wrong characters, but does not introduce new technical meaning beyond the schema definition.

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 the verb 'verify' and the resource 'Ethereum address', with specific context 'before sending funds or storing it'. It distinguishes itself from sibling validation tools by focusing on Ethereum-specific checksums and format.

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

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

Explicitly instructs when to use ('USE THIS to verify an Ethereum address before sending funds or storing it') and warns about consequences of not using it. The directive 'never trust that a 0x… string is correct' provides clear guardrails.

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

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

With no annotations, the description discloses key behaviors: checks 11-digit form and mod-11 control digits, and clarifies it only validates structure. It does not cover auth needs or rate limits, but for a read-only validation tool, this is adequate.

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 concise sentences, front-loaded with 'USE THIS', and every sentence adds value without redundancy.

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

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

For a simple validation tool with one parameter and no output schema, the description is mostly complete: it explains purpose, validation logic, and limitations. It could mention the return type (e.g., boolean) but that is minor.

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 schema has 100% parameter description coverage, so baseline is 3. The description adds meaning by explaining what validation is performed (mod-11 checks) and the scope (structure only), enhancing parameter understanding.

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 it verifies a Norwegian fødselsnummer, checking structure and control digits, and specifies what it does not do (registration check). It is specific but does not differentiate from siblings like validate_personnummer or validate_ssn.

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 advises using it before relying on the number and notes it does not confirm registration, providing context. However, it lacks explicit guidance on when not to use or alternatives among sibling validation tools.

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

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

No annotations provided, so the description carries full burden. It discloses that the tool checks the mod-10 check digit, returns the issuing country, and validates structure only (not registration). This is sufficient behavioral context for a validation tool, though it could mention idempotency or return format.

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, no wasted words. The key actions and constraints are front-loaded with 'USE THIS'. Every sentence adds value: usage instruction, validation details, and limitation.

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

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

No output schema exists, but the description hints at the return value (issuing country). For a simple validation tool, this is mostly complete. However, it does not specify whether the return is a boolean or full result object, which could be improved.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema: it mentions 'spaces and dashes are ignored', which is already in the schema's parameter description. No additional parameter semantics are provided.

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 the tool's purpose: 'verify a GLN' (Global Location Number) before relying on it. It specifies the format (13-digit GS1 mod-10), the check performed (check digit), and what it returns (issuing country). This distinguishes it from sibling validation tools like validate_gtin or validate_iban.

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 explicitly says 'USE THIS to verify a GLN before relying on it', providing clear guidance on when to use the tool. It does not explicitly mention when not to use or list alternatives, but the context of sibling tools (many validation functions) and the specific focus on GLN makes the usage context 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?

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that validation is structural only, does not confirm registration, and explains return details (barcode type, country). It does not mention any side effects, permissions, or rate limits, but these are not expected for a simple validation 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?

The description is a single, well-structured paragraph of three sentences. It is concise with no redundant information, and the imperative 'USE THIS' at the beginning captures attention immediately. Every sentence is informative and earns its place.

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

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

Given the simple input (one string) and no output schema or annotations, the description is fairly complete. It explains input formatting, expected output (barcode type, country), and limitations. It could explicitly state the return format (e.g., JSON object), but it's implied by typical API conventions. Overall adequate for the tool's complexity.

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

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

Schema description coverage is 100% for the single parameter 'gtin'. The description adds value beyond the schema by specifying that spaces and hyphens are ignored, and lists the accepted formats (EAN-8, UPC-A, EAN-13, GTIN-14). This extra context helps the agent understand input requirements.

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 the verb 'verify' and the resource 'product barcode'. It explicitly handles GTIN/EAN/UPC formats, check digit verification, and returns barcode type and issuing country. It also distinguishes itself by stating what it does not do (confirm real product registration), making its purpose unambiguous.

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

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

The description opens with 'USE THIS to ... before trusting it, instead of guessing the check digit,' providing explicit usage guidance. It clarifies structural validation only, but does not explicitly mention alternatives for real product lookup. However, the context of sibling validation tools (e.g., validate_email, validate_phone) implies that this tool is specific to barcodes.

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

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

With no annotations, the description carries full burden. It discloses that the tool validates structure only and checks the mod-31 check character, which is good behavioral context. No side effects are mentioned, but implicitly it is read-only.

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 that are direct and free of unnecessary words. It front-loads the action and provides all critical information efficiently.

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

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

The tool is simple with one parameter and no output schema. The description fully explains what it does, what it validates, and its limitation to structural validation, making it complete for the given context.

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 a clear example. The description adds meaning by explaining the composition of the HETU and confirming it validates structure only, going beyond the schema's parameter description.

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

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

The description clearly states the tool verifies a Finnish HETU personal identity code and specifies it checks the structure including DDMMYY, century sign, individual number, and mod-31 check character. It is specific and distinguishes from guessing the check character.

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 explicitly says 'USE THIS to verify... before relying on it — do not guess the check character,' providing clear when-to-use guidance and a warning. It does not, however, discuss when not to use or compare to sibling validation tools.

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

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

No annotations are provided, so the description must disclose behavior. It explains the validation steps (country, length, checksum) and what is returned (country, check digits, BBAN). It does not mention side effects or authorization, but as a validation tool, this is reasonable. No contradictions with 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?

The description is concise with two sentences, front-loading the action ('USE THIS') and providing essential details without extraneous text.

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

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

Given the simple input (one string) and no output schema, the description adequately covers when to use and what it returns. However, it does not detail the output format or possible error cases, which could be helpful for completeness.

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 schema provides 100% coverage for the single parameter, but the description adds significant value by explaining the validation logic and return values (country, check digits, BBAN), which go beyond the schema's minimal description.

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

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

The description clearly states the tool's purpose: verify an IBAN by checking country, length, and checksum, and returning components. It distinguishes itself from sibling validation tools by specifying IBAN and providing concrete use cases (payment, payout, invoice).

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 explicitly advises when to use the tool ('whenever a user supplies a bank account for a payment, payout or invoice') and contrasts it with guessing. It lacks explicit when-not-to-use or alternatives, but the guidance is clear for the intended context.

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?

Without annotations, the description carries full burden. It discloses scope (Luhn check, IMEISV recognition, TAC return) and boundaries (does not check real device status). However, it does not describe the return format or error handling, which would be expected for a validation 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?

The description is two sentences, front-loading the usage directive and then providing key details. Every sentence adds value without unnecessary words.

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

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

Given no output schema, the description should explain return values. It mentions returning the TAC but not the full structure (e.g., boolean success, error messages). For a simple tool it is adequate but lacks completeness on 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?

The schema description covers the parameter fully (format, allowed forms). The description adds context (Luhn check, TAC) but does not add significant parameter-specific 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?

The description clearly states the tool validates an IMEI by checking the Luhn check digit and recognizing IMEISV, returning the TAC. It distinguishes from sibling validation tools by explicitly stating what it does NOT do (check real device status).

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 explicitly advises using this tool to verify an IMEI before relying on it, and warns against assuming validity. It implies when not to use (when needing blocklist/status checks), but does not name specific alternative tools among siblings.

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

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

No annotations are provided, so the description carries the burden. It discloses the strict validation rules (RFC 791/4291, rejects leading zeros, supports compressed IPv6) and states it returns the version. It does not mention error behavior, but the core behavior is transparent.

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 no waste. The first sentence gives an imperative usage instruction, the second provides technical specifics. Information is front-loaded and every sentence is valuable.

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

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

The description covers the tool's purpose, validation details, and return of version. However, without an output schema, it could specify the exact return format for valid vs invalid addresses. Still, sufficient for a simple one-parameter 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 schema describes the parameter as 'The IPv4 or IPv6 address to validate.' The description adds context about validation standards but not additional syntax details, so it meets the baseline of 3.

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

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

The description clearly states it validates IPv4 and IPv6 addresses against RFC standards, and distinguishes from sibling tools by focusing on IP addresses. The verb 'validate' and resource 'IP' are specific and unambiguous.

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

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

The description explicitly advises to use this tool before relying on an IP address, providing a clear use case. It does not list alternatives but the sibling tools are all for different validation types, making the context clear. The strict standards are detailed, aiding proper usage.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool checks prefix and check digit and returns the expected check digit on failure, but does not describe behavior on success (e.g., returns true or void) or error conditions.

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 sentences with no wasted words. The first sentence is an imperative call to action, and the second explains the verification logic and return behavior. Front-loaded and 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?

The description lacks information about the success return value (e.g., boolean) and overall response format. While it explains failure behavior, the lack of output schema means the description should compensate, which it does only partially.

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 a clear description of the isbn parameter. The tool description adds context about what verification is performed (prefix and check digit), providing 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?

The description clearly states the tool verifies ISBN-13 book identifiers, specifying it checks the 978/979 prefix and mod-10 check digit. It distinguishes from trusting raw digits and implicitly differentiates from sibling validate_isbn10 by specifying ISBN-13.

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 explicitly says 'USE THIS to verify an ISBN-13 book identifier instead of trusting that 13 digits are correct,' providing clear context for when to use. However, it does not mention when not to use (e.g., for ISBN-10) or list alternatives explicitly.

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 description explains the mod-11 check digit check and X handling. Without annotations, it carries full burden; it could mention return type but is sufficient for expected validation behavior. No contradictions.

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 concise sentences, no fluff, front-loaded with purpose and usage differentiation. Every sentence adds 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 simple single-parameter validation tool with no output schema, the description is complete. It covers purpose, input format, algorithm, and sibling differentiation.

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 'hyphens/spaces ignored', which is useful context beyond the schema's description. Parameter is well-defined.

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 the tool verifies ISBN-10 identifiers and explicitly distinguishes from validate_isbn for 13-digit ISBNs. It also mentions the check digit algorithm, which adds specificity.

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 provides explicit guidance on when to use this tool ('instead of trusting 10 characters') and when not to ('For 13-digit ISBNs use validate_isbn'), with a sibling tool reference.

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?

Without annotations, the description carries the full burden. It discloses that the tool checks format and Luhn digit and returns country code, but does not describe error behavior or return format (e.g., what happens on invalid input). This is adequate but leaves some behavioral uncertainty.

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 three sentences long, front-loaded with an imperative instruction, and contains no unnecessary words. Every sentence adds value: usage directive, explanation of checks, and invocation context.

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

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

For a simple validation tool with one parameter and no output schema, the description covers purpose, usage context, and what the tool checks. It lacks details on the return value format beyond 'returns the country code,' but is otherwise sufficiently complete for correct agent usage.

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 input schema provides a detailed description of the 'isin' parameter (12-character ISIN with example), achieving 100% coverage. The description adds no additional parameter-level information beyond reinforcing the purpose, so it meets the baseline but does not enhance 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 the tool validates an ISIN by checking format and Luhn check digit, and returns the country code. It uses specific verb ('verify') and resource ('ISIN'), and distinguishes from sibling validation tools by naming the specific identifier type.

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 explicitly says 'USE THIS to verify an ISIN' and 'Call this when a user supplies a security/instrument identifier,' providing clear context for use. It does not mention when not to use it or alternatives, but the context is sufficient for correct selection among sibling tools.

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?

Discloses the validation algorithm (mod-11 check digit) and the behavior on failure (returns expected digit). Despite no annotations, the description provides sufficient transparency about the tool's operation.

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

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

Two concise sentences that front-load the purpose and add necessary technical detail without waste. Every sentence is informative and 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?

Covers validation algorithm and failure response. Lacks explicit success behavior and return format, but as a simple validation tool with no output schema, the description is reasonably 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% with a clear description of the 'issn' parameter. The tool description repeats the schema's parameter description but adds no new semantic value, leading to a baseline score of 3.

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

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

Explicitly states the verb 'verify' and the specific resource 'ISSN' (serial/journal identifier). Distinguishes from sibling validators by naming the ISSN standard and the mod-11 check digit algorithm.

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?

Cues usage with 'USE THIS to verify an ISSN before relying on it', providing clear context. Does not explicitly exclude alternatives, but the sibling set of diverse validators makes the scope self-evident.

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

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

With no annotations provided, the description carries the full burden. It discloses the validation algorithm (check digits per ISO standards). While it doesn't detail side effects, permissions, or error cases, for a validation tool this is sufficient and adds value beyond a tautology.

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 sentences: the first delivers an imperative usage guideline, the second provides technical detail. Every phrase earns its place with no redundancy or verbosity.

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 the tool's simplicity (one parameter, no output schema, validation function), the description covers the essential purpose and behavior. It does not describe return values, but for a boolean validator this is implicit. The context from sibling tools is consistent, and the description is complete enough for correct use.

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 input schema has one parameter with a description and example. Schema description coverage is 100%, so baseline is 3. The tool description adds context about the check digit standards but does not significantly enhance understanding of the parameter itself beyond what the schema already provides.

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 specifies the action (verify an LEI), the resource (Legal Entity Identifier), and the standards checked (ISO 17442 / ISO 7064 MOD 97-10). It clearly distinguishes from sibling validators by focusing on LEI specifics.

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 includes a strong usage directive: 'USE THIS to verify... before relying on it — do not assume a 20-character code is valid.' This tells when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, though sibling tools cover other identifier types.

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?

Although no annotations are provided, the description reveals the core algorithm ('Checks the mod-11 check digit') and implies input normalization ('spaces ignored' mentioned in parameter schema). It lacks detail on output format but is sufficient for a validation 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?

Extremely concise: two sentences that front-load the imperative 'USE THIS' and pack essential information (when to use, what it does) without any filler words.

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

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

For a single-parameter validation tool with no output schema, the description covers purpose, usage context, algorithm, and parameter format. It lacks explicit return type, but typical validation tools return a boolean, which is implied.

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 parameter schema already describes the 'nif' field as a 9-digit string with spaces ignored, achieving 100% coverage. The description reinforces the 9-digit requirement and adds the mod-11 context, adding value 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 clearly states the tool's purpose: to verify a Portuguese NIF (tax number) using mod-11 check digit. It distinguishes itself from the sibling 'validate_dni' by specifying it's for Portuguese tax ID, not Spanish.

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

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

Explicitly tells when to use (before invoicing or onboarding) and provides a warning ('never assume 9 digits are valid'). It also directs to an alternative tool for Spanish tax ID.

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?

Without annotations, description reveals algorithm (ISO 7064 MOD 11-2, 'X' allowed) and accepted inputs (bare ID or URL). Adequate for read-only validation, but does not describe return format or how failures are communicated.

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 efficient sentences with imperative lead-in. Every word adds value; no fluff.

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?

Single-parameter tool with no output schema. Description explains what and how, but lacks explicit indication of return type (boolean, error, etc.) which would be helpful for complete context.

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 covers parameter fully with example. Description adds key behavioral details: check digit algorithm, allowance of 'X', and acceptance of URLs, enriching 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?

Description explicitly states 'verify an ORCID researcher identifier' with specific function (checks ISO 7064 check digit) and input formats. Clear verb+resource with unique scope among sibling validators.

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?

Imperative 'USE THIS' plus rationale 'instead of trusting 16 digits' gives clear when-to-use context. Does not explicitly contrast with sibling validators but implies reliability.

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

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

With no annotations provided, the description fully discloses the tool's behavior: it validates structure (10- or 12-digit form), checks the Luhn check digit, and explicitly states it does not confirm registration. These details give the agent a clear understanding of the tool's capabilities and limitations.

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 three sentences long, front-loaded with a clear imperative, and contains no redundant or unnecessary information. Every sentence serves a purpose: stating the tool, its input requirements, and its limitations.

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 no output schema, no annotations, and a simple single-parameter input, the description provides all necessary information: what it validates, how it validates (Luhn), and what it does not cover (registration). It is complete for the tool's complexity.

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

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

The schema has 100% coverage for the single parameter, describing it as '10 or 12 digits; +/-/spaces ignored.' The description adds the Luhn check context but does not supplement the parameter format beyond what the schema already provides. Baseline 3 is appropriate as the description adds minimal extra meaning for the parameter itself.

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 the tool's purpose: verifying a Swedish personnummer. It specifies the exact resource (Swedish personnummer), the action (verify), and distinguishes it from many sibling tools that validate other identifiers (e.g., validate_email, validate_iban). The imperative 'USE THIS' reinforces the specific purpose.

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 advises when to use the tool ('before relying on it') and cautions against assuming validity. It also explicitly states what it does NOT do ('does NOT confirm the number is registered'). However, it does not mention when to avoid using this tool or alternatives for registration confirmation, which could improve clarity.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions the algorithm but omits return format, side effects, or whether it is read-only, leaving gaps for an AI agent.

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 clear action verb and purpose; front-loaded 'USE THIS' directive. No wasted words.

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

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

For a simple validation tool, the description is fairly complete, covering purpose and usage context. Lacks return value details, but output schema is absent, so some inference is acceptable.

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 already describes the parameter as an 11-digit string ignoring spaces/dashes. The tool description adds no further parameter insights, so baseline 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 clearly states the tool validates a Polish PESEL number using a mod-10 check digit, which is distinct from sibling validation tools for other identifiers.

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

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

Explicitly directs to use for verification before relying on a PESEL and for KYC/onboarding, but does not specify when not to use or provide alternative tools.

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

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

No annotations provided, so the description carries full burden. It explains that 'valid' means conforms to numbering plan, not live/reachable, and lists return formats (E.164, national/international, line type). Minor miss: doesn't explicitly state if the tool is read-only or has destructive effects, but phone validation is inherently safe.

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 usage instruction and critical constraints. No redundancy, every word adds 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?

Despite no output schema, the description covers return formats and result meaning. For a simple validation tool with 2 parameters, this provides complete contextual information for the agent to select and use 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 has 100% coverage for both parameters. The description adds value by emphasizing the region parameter's importance and explaining the semantics of 'valid' beyond the schema's description. Baseline is 3 due to coverage, and the extra context raises it to 4.

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 'check a phone number is correctly formatted... and normalise it to E.164', using a specific verb and resource. It distinguishes from sibling tools by focusing on phone number validation and normalization, unlike other validation tools in the sibling list.

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

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

Explicitly says 'USE THIS to check... before saving, dialling or texting' and includes a critical caution: 'You MUST pass the ISO country the number ACTUALLY belongs to... don't reuse an unrelated country field.' This provides clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description fully discloses behavior: it validates a 9-digit checksum using (3,7,1) mod-10 and does not check real-world existence. This is transparent about both capabilities and limitations.

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

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

Three sentences, front-loaded with imperative 'USE THIS', and every sentence adds essential information: usage context, algorithm, and limitation. No wasted words.

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

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

Given the tool is simple with one parameter and no output schema, the description covers purpose, validation method, and limitation. It could optionally mention return type, but the context from siblings likely suffices. Complete enough for effective use.

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 baseline is 3. The description adds context about US routing numbers and the algorithm, but the parameter's format (9-digit) is already in the schema. Some added value, but baseline 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 clearly states the tool validates US bank routing/ABA transit numbers for payment/direct deposit. It specifies the checksum algorithm and explicitly notes what it does NOT check, distinguishing it from sibling validation 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 description gives clear guidance on when to use ('before relying on it for a payment or direct deposit') and notes the limitation (does not check real bank/account). However, it does not explicitly mention when not to use or suggest alternatives, but the context of sibling tools implies it's for routing numbers only.

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?

Describes the specific checks performed (Luhn, DOB) and the data returned (DOB, gender, citizenship). No annotations exist, so description carries full burden; it adequately discloses non-destructive, read-only behavior.

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

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

Two concise sentences with no redundant information. The imperative 'USE THIS' immediately front-loads the key guidance.

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?

Provides sufficient detail for a simple validation tool: input format (13-digit), processing logic (Luhn, DOB), and output fields (DOB, gender, citizenship). Lacks mention of error handling but is usable overall.

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 100% schema coverage for the sole parameter, the description adds modest context (13-digit number, checks performed) but does not significantly enhance understanding beyond what the schema already provides.

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?

Description clearly states the tool verifies a South African ID number, checks Luhn checksum and date-of-birth validity, and returns encoded data. Distinguishes from sibling validation tools which target other ID formats.

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

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

Explicitly recommends using this tool before relying on an SA ID number. Does not list when not to use or provide alternatives, but the sibling context makes it clear it is for SA ID validation only.

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

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

With no annotations, the description discloses the key validation logic (no-vowels alphabet, weighted mod-10 check digit). Does not mention return type or behavior on failure, but is transparent about the checks performed.

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 concise sentences, front-loaded with the action instruction. No wasted words, effectively communicates purpose and method.

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 one parameter, no output schema, and no annotations, the description fully covers the tool's purpose and behavior. Provides all necessary context for an agent to decide to use it.

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 already describes the single parameter with example value. Description adds context about what a SEDOL is and the validation checks, enhancing semantic understanding 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?

Clearly states the tool verifies a SEDOL (LSE securities identifier) and describes the specific checks performed (no-vowels alphabet, weighted mod-10 check digit). Distinguishes from sibling validation tools targeting other identifiers.

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

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

Explicitly instructs to use this tool when verifying a SEDOL before relying on it. Implicitly clear from sibling list that it's the correct tool for SEDOLs, but lacks explicit when-not-to-use or alternative tool references.

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

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

With no annotations, the description discloses key behaviors: checks mod-10 check digit, validates structure only, returns extension digit and GS1 prefix country. It does not mention side effects (none) or permissions, but the read-only nature is implied.

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, no fluff. The imperative 'USE THIS' front-loads the purpose. Every sentence adds value without redundancy.

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

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

For a simple validation tool with one parameter and no output schema, the description covers purpose and behavior. However, it lacks details on error behavior (e.g., return value for invalid SSCC) and the exact output format for the extension digit and country.

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 a clear description for the single parameter 'sscc': 'The 18-digit SSCC; spaces and dashes are ignored.' The description adds context about GS1 and check digit validation but does not provide additional semantic meaning beyond what the schema already offers.

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 'verify an SSCC' with specific actions: checking the GS1 mod-10 check digit and returning extension digit and country. It distinguishes from sibling validation tools by naming the specific identifier type.

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 explicitly says 'USE THIS to verify an SSCC... before relying on it', providing clear when-to-use guidance. No exclusions or explicit comparisons to alternatives are mentioned, but the sibling list implies each tool is for a different identifier.

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

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

With no annotations, the description fully discloses behavioral traits: structural validation, algorithmic checks, and the limitation of not confirming registration. No contradictions.

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, no fluff, front-loaded with purpose and usage directive.

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?

Describes purpose, usage, and limitations adequately for a simple validation tool. Could optionally mention return type but not required.

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 has 100% coverage for the single parameter. The description adds context about checks but doesn't meaningfully extend parameter semantics beyond the schema description.

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

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

The description clearly states the tool validates a Turkish TCKN, distinguishes from mere length checks by mentioning algorithmic and leading-digit rules, and is distinct from sibling validators.

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 explicitly says 'USE THIS' for verification before relying, and clarifies it does NOT confirm registration, providing when-to-use and exclusion 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?

Discloses the authoritative source (IANA root-zone list) and return behavior (valid:false for non-delegated). No annotations present, so description carries full burden; it adequately describes side-effect-free 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?

Three sentences with zero waste. Front-loads purpose and usage, then adds behavioral details. Highly 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?

Complete for a simple validation tool with one parameter. Covers purpose, usage, data source, and return semantics. Could mention case sensitivity, but not a major 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?

Parameter description in schema is 100% covered and clear. Description adds value by explaining data source and return behavior, beyond what schema provides.

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?

Clearly states 'check whether a top-level domain is real' with a specific verb and resource. Distinguishes from sibling tools like validate_domain by focusing on TLDs.

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

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

Explicitly instructs when to use ('before trusting a domain or link') and when not ('do NOT guess'), with examples of ambiguous TLDs.

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

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

No annotations are provided, so the description carries the full burden. It discloses the parsing standard and TLD check, and lists return fields (protocol, hostname, port, path, TLD known). It does not mention error behavior or failure modes, but for a simple validation tool this is adequate.

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 'USE THIS,' every sentence adds value. No wasted words.

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

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

For a tool with one parameter and no output schema, the description explains purpose, behavior, and return values. It is complete for an agent to use 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 parameter is already well-documented in the schema. The description adds context (must be absolute) and an example, but does not significantly improve understanding beyond what the schema provides. Baseline 3.

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

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

The description clearly states the tool verifies a URL before fetching or storing, specifying the WHATWG parsing standard and additional IANA TLD check. This distinguishes it from other validation tools in the sibling list.

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

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

The description explicitly says 'USE THIS to verify a URL before fetching or storing it,' which is a clear when-to-use. It does not mention when not to use or alternatives, but the sibling list implies other tools are for different entities.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool checks the canonical form and returns version, variant, and whether it is the nil UUID. It does not mention error behavior for invalid inputs, but the core behavior is well-described.

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

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

The description is two sentences with no wasted words. It front-loads the action and example, then details checks and returns. Every sentence adds 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?

Given the simple input (one string parameter) and no output schema, the description adequately explains the return value (version, variant, nil UUID). It could mention error handling for completeness, but overall covers the essential context.

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 schema covers 100% of parameters with a basic description. The tool description adds value by explaining that the parameter is validated for canonical form and used to extract version/variant, going beyond the schema's 'The UUID string to validate.'

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 the tool's purpose: validate a UUID and read its version/variant. It provides a concrete example (distinguishing v4 from v7) and specifies what is checked (canonical form, returns version/variant, nil UUID). This distinctly differentiates it from sibling validation 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 description begins with 'USE THIS to verify a UUID... instead of guessing', giving explicit guidance on when to use the tool. It implies alternatives are other validation tools, but does not explicitly exclude them. The context is sufficient for an agent to decide.

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

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

With no annotations, the description discloses that it only checks format+checksum and not live registration, and covers EU/EFTA+UK. It does not mention any side effects or permission requirements, but since it's a read-only validation, the limitations are adequately stated.

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 efficient sentences with no fluff. The imperative first sentence immediately conveys action and context. The second sentence provides a critical limitation. No wasted words.

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

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

Given the simplicity of the tool (validation with two parameters, no output schema), the description covers input format, geographic scope, and limitations. It could optionally mention the return type, but the context is sufficient for an agent to invoke the tool 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 covers 100% of parameters, but the description adds context by explaining two usage modes (prefix in vat vs separate country code) and provides an example. This adds meaning beyond the schema's property descriptions.

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

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

The description clearly states the tool verifies EU/EFTA VAT number format and checksum, specifies geographic coverage (EU/EFTA+UK), and contrasts with just trusting the appearance. However, it does not explicitly differentiate from sibling validation tools, but the purpose is specific enough.

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 explicitly says when to use ('before invoicing or onboarding') and when not to use (it does not confirm live registration), and even suggests an alternative (VIES lookup). This provides excellent 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?

Despite no annotations, the description fully discloses the validation logic: checks the allowed alphabet (no I/O/Q) and the ISO 3779 check digit in position 9, and indicates it returns the expected check digit when validation fails.

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, no wasted words. Front-loaded with the imperative 'USE THIS' and clear structure: purpose, validation specifics, and output behavior.

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 tool with one required parameter and no output schema, the description covers what it does, what it validates, and what it returns on failure. No 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 100%, baseline 3. The description adds meaning by explaining the validation steps and return behavior, elevating beyond mere schema details.

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 explicitly states it is for verifying a vehicle VIN before acting on it, and distinguishes from many sibling tools by focusing on VIN validation. It specifies the checks: allowed alphabet and check digit.

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 when-to-use guidance: 'USE THIS to verify a vehicle VIN before acting on it — do not assume a 17-character string is a valid VIN.' This instructs the agent to always validate before using a VIN.

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