SweKit - Swedish validators

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact, that the result depends on the Swedish holiday calendar and that days may be subtracted, but it does not explain edge-case behavior (whether the start date counts, how mode affects the holiday set).

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

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

A single sentence with the core operation front-loaded, followed by the calendar qualifier and an example. Nothing is padded or redundant.

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

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

For a three-parameter, no-output-schema tool with full annotation coverage, the description is adequate but thin: it never states the return value (presumably a YYYY-MM-DD date) and does not clarify what distinguishes bank mode from work mode, which is the only non-obvious parameter choice an agent must make.

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

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

Schema description coverage is 100%, with date format, the integer/negative convention and the bank/work enum all documented in the schema. The description's parentheses restate the subtraction case already covered by 'integer, may be negative', adding no syntax or format detail beyond the schema.

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

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

The description gives a specific verb (add/subtract) and resource (business days to a date) and pins down the holiday calendar as Swedish, which cleanly separates it from count_business_days and swedish_holidays. It stops just short of naming the sibling it complements, so it is clear but not fully differentiated.

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

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

Usage is only implied through the parenthetical example ('payment due dates'), which hints at a finance context but never states when to choose this over count_business_days or swedish_date_info. No exclusions or prerequisites are given.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful boundary semantics ("after from" and "up to and including to") and the Swedish business-day scope, but says nothing about the mode parameter or how Swedish holidays/weekends are treated.

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

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

A single front-loaded sentence with no filler. It states the action, the scope, and the range boundary 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 and annotations cover the safety profile, but the description omits any explanation of the mode enum values and gives no return-value clarification. For an agent choosing between bank and work modes, the definition is only minimally complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds boundary semantics for from/to, but does not explain the mode parameter ("bank or work") beyond what the schema already says, leaving a meaningful parameter semantic gap.

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

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

The description gives a specific verb ("Count") and resource ("Swedish business days") plus a clear range boundary. It distinguishes itself from the sibling add_business_days by verb, but does not explicitly name or contrast that alternative.

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

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

The description implies usage (count business days between two dates) but provides no explicit when-to-use guidance or alternatives to add_business_days, swedish_holidays, or swedish_date_info. The context is clear enough to infer basic use, but not enough to route confidently 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, and the deterministic generation behavior is consistent with them. The description adds the algorithmic context (check digit plus optional length digit), but gives no information about return format or how errors are reported, which matters since there is no output schema.

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

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

A single front-loaded sentence that wastes no words; purpose and output are stated immediately with no filler.

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

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

For a small two-parameter generator the purpose is complete and safety is covered by annotations, but with no output schema the description never states the format of the returned reference, which an agent needs to use the result.

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

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

Schema coverage is 100%, with the schema documenting both base ('digits') and length_digit ('true' to add length digit), so the schema does the heavy lifting. The description adds only a marginal example ('such as an invoice number') and restates the optional length digit, so it stays at the baseline.

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

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

States a specific verb and resource ('Generate a Swedish OCR reference') and elaborates on exactly what is produced (check digit, optional length digit) from a base number. The generate-vs-validate verb split cleanly distinguishes it from the sibling validate_ocr.

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

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

The phrase 'such as an invoice number' implies the intended input context, so usage is inferable, but there is no explicit when-to-use/when-not guidance and no pointer to the complementary validate_ocr sibling. Adequate but with clear gaps.

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

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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description need not restate safety. It does add genuine value by disclosing what is returned (bank name, BIC, IBAN id, account type), which matters because there is no output schema, though it says nothing about behavior for unknown or non-Swedish clearing numbers.

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

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

One sentence, zero waste, front-loaded with the action and resource and then the payoff. Nothing needs trimming and nothing important is buried.

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

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

For a simple one-parameter read-only lookup, the description plus annotations plus the 100%-documented schema cover almost everything. The only remaining gap is error/edge behavior for unmatched clearing numbers, which is minor and partly inferable from the closed-world annotation.

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

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

Schema coverage is 100% and the single parameter is fully documented as 'first 4 digits of the account number'. The description adds the connecting context that this value is a Swedish clearing number, but no format or validity constraints, 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?

States a specific verb ('Look up') and resource ('Swedish clearing number') and even enumerates the returned fields (bank name, BIC, IBAN id, account type), which an agent can use to distinguish it from the validate_* siblings. It does not explicitly name an alternative such as swedish_account_to_iban, so it stops short of a 5.

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

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

Usage is implied by the purpose - call it with a clearing number to get bank metadata - but there is no explicit when-to-use or when-not guidance, nor any routing to related siblings like swedish_account_to_iban or validate_bankgiro.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds real value beyond that by naming the validation authority (Bankgirot checksum rules) and data source (official Bankinfrastruktur clearing table), and by enumerating the returned fields in the absence of an output schema.

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

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

A single dense sentence that front-loads the primary action (validate) ahead of the secondary one (convert), with no redundant or filler clauses. Every phrase earns its place.

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

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

With no output schema, the description correctly compensates by listing the return fields (bank, BIC, account type, IBAN), and parameters are fully covered by the schema. What is still missing is failure behavior for an invalid account or unknown clearing number, which an agent would want before calling 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 description coverage is 100%, so all three parameters are already documented, including the optionality of 'number'. The description only echoes the clearing+account concept the schema already covers, adding no syntax, format, or validation detail of its own.

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

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

States a specific verb pair (validate + convert) on a specific resource (Swedish national bank account / IBAN) and names the mechanism (Bankgirot checksum rules, official Bankinfrastruktur clearing table). This distinguishes it from siblings like validate_iban and lookup_clearing_number, which only validate or only look up respectively.

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

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

Usage is implied by the validate-and-convert framing, but there is no explicit when-to-use guidance or exclusion, e.g. whether to use this versus validate_iban or lookup_clearing_number first. The routing to alternatives is left entirely to the reader.

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

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

Annotations already cover read-only, idempotent, and closed-world traits, so the bar is lower. The description adds genuine behavioral context beyond the annotations by specifying that mode=bank treats midsommarafton, julafton, and nyårsafton as non-business days, though it does not clarify what mode=work does differently.

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

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

Two dense sentences with zero filler: the first lists the returned information, the second front-loads the key mode behavior. Every phrase earns its place and the critical mode detail follows immediately.

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

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

With no output schema, the description usefully names the return fields (weekday sv/en, ISO week, holiday names, business-day status), and annotations cover the safety profile. Minor gaps remain, such as which holiday set is used and the work-mode default behavior, but nothing essential to invoking it is missing.

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

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

Schema coverage is 100%, making 3 the baseline, but the description earns extra credit by defining what the bank enum value means operationally (specific eve days treated as non-business). It adds meaning beyond the schema's bare 'bank or work' and 'YYYY-MM-DD' 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 enumerates the concrete outputs (weekday in sv/en, ISO week, holiday names, business-day status) for a date, which is a specific verb-resource statement. It does not explicitly differentiate itself from siblings like swedish_holidays, add_business_days, or count_business_days, so it falls short of a 5.

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

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

There is no explicit guidance on when to use this tool versus the many sibling date tools (swedish_holidays, add_business_days, count_business_days). The mode=bank explanation implies its business-day context but does not route the agent between alternatives or state exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and determinism are covered elsewhere. The description contributes one genuinely useful behavioral detail — '(computed)' — implying results are derived rather than fetched from a fixed holiday table, but says nothing about how observances vs. eves are labeled in the output.

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

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

A single tightly written sentence that front-loads the verb and resource with zero filler. Every phrase carries information.

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

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

For a read-only, single-parameter tool the description is close to sufficient, but 'year' is not a required parameter and the description never says what happens when it is omitted (current year? all years?). That is a real gap an agent could trip on.

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

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

Schema coverage is 100% for the single 'year' parameter and the schema already documents its 1900-2200 range. The description only implies 'for a year' without adding format, default, or out-of-range behavior, so the baseline 3 applies.

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

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

The description gives a specific verb ('List') and a well-scoped resource ('Swedish public holidays, eves and observances for a year'), so an agent knows exactly what it returns. It does not, however, distinguish itself from the closest sibling, swedish_date_info, which could plausibly overlap.

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

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

There is no explicit when-to-use guidance and no mention of alternatives, despite swedish_date_info sitting in the same sibling list as a potential overlap. A caller must infer the use case entirely from the noun phrase.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=false). The description adds one genuine behavioral fact beyond them: the tool also *formats*, not just validates, implying output normalization. It does not say what the formatted result looks like or how invalid input is reported.

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

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

A single front-loaded sentence with zero filler; the verb and resource appear immediately. It is arguably a touch terse given the dual validate/format behavior it advertises.

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

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

With no output schema, the description is the only source for return behavior, and 'validate and format' leaves ambiguous what is returned on success versus failure and in what format. For a single-parameter utility this is acceptable but not complete.

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

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

Schema description coverage is 100% and the single parameter carries its own example ('e.g. 5402-9681'), so the schema does the documentation work. The description adds no extra parameter meaning, which is the baseline case for a one-param tool.

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

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

States a specific verb pair ('validate and format') and a specific resource ('a Swedish bankgiro number'), so the agent knows exactly what domain object is being checked. It does not explicitly distinguish itself from the sibling validate_plusgiro, but the resource noun does the differentiation.

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

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

There is no explicit when-to-use, when-not-to-use, or mention of the alternative validate_plusgiro, so guidance is only implied by the tool name. For a self-evidently scoped validator that is adequate but not helpful.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world). The description adds real value beyond them by naming the validation algorithm (ISO 13616 mod-97 + country length) and disclosing that bank identification only applies to Swedish IBANs, setting correct expectations. It stops short of describing the return shape or failure behavior.

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

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

A single front-loaded sentence that names the action, the standard, and the conditional bank feature with zero 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?

There is no output schema, so the description should ideally indicate what a validation call returns (e.g., valid/invalid plus bank details for Swedish IBANs). It hints at bank identification but leaves the return shape unspecified, a notable gap for a validator.

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 single 'value' parameter and its spaces-allowed tolerance are already fully documented. The description adds nothing parameter-specific beyond the baseline.

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

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

States a specific verb (validate) and resource (IBAN), plus a secondary capability (bank identification for Swedish IBANs). This clearly distinguishes it from siblings like validate_ocr, validate_bankgiro, and validate_personnummer, which validate entirely different 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?

The scope ('any IBAN' vs Swedish-only bank lookup) implies when to use it, but there is no explicit when-to-use guidance or mention of alternatives such as swedish_account_to_iban, which also deals with IBANs. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral substance beyond that: it discloses the actual validation rule (Luhn check digit) and the nuance that the length digit is optional, which tells the agent what inputs will pass. It still omits how failure is signalled (boolean vs error), so it falls short of a 5.

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

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

A single sentence that front-loads the verb and resource, then parenthetically supplies the two details that matter (Luhn, optional length digit). No filler or restatement of the name.

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

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

For a one-parameter validator with no output schema, the description should say what a call yields (valid/invalid boolean, error vs false) and any input-format constraints. It covers the validation rule well but leaves the return semantics entirely unspecified, which is a real gap given the absence of an 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?

With 1 parameter and 100% schema description coverage, the schema already documents 'value' as 'OCR digits'. The description adds only the domain framing (Swedish OCR payment reference) and does not specify accepted format or expected length beyond the optional-length-digit note, so it meets the baseline without exceeding it.

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

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

States a specific verb (validate) and a specific resource (Swedish OCR payment reference), and names the algorithm (Luhn check digit, optional length digit). This clearly separates it from the sibling validators (validate_bankgiro, validate_iban, validate_personnummer, validate_plusgiro) without needing to open any schema.

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

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

The domain-specific name and the algorithm note imply when this tool applies (validating a Swedish OCR reference), but there is no explicit statement of when to use it versus generate_ocr or the other validate_* siblings, and no preconditions are given. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that the tool returns a legal form hint and the derived Swedish VAT number, which is useful behavioral context absent from structured data (no output schema). It stops short of describing error behavior or output shape in detail.

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

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

One sentence, front-loaded with the verb and resource, and no wasted words. The parenthetical alternative and return description are integrated 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 read-only validation with one parameter and no output schema, the description supplies the input alternative and the return contents. It is sufficient for correct invocation, though it could state invalid-input behavior or error format to be fully complete.

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

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

Schema coverage is 100% and the single parameter has an example ('556036-0793'). The description adds that the input may also be an SE...01 VAT number, going beyond the schema's example and clarifying accepted formats. This is meaningful additional semantics for the only parameter.

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

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

States a specific verb (Validate) and resource (Swedish organisationsnummer, with an SE...01 VAT number alternative). The resource is unambiguous and distinct from sibling validate_personnummer, so an agent can select it without opening the schema.

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

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

The description does not say when to use this tool versus sibling validate_* tools, nor does it list prerequisites or exclusions. Usage is only implied by the resource name; no explicit routing guidance is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying that it checks format/Luhn/date/age/gender and explicitly warns that it does not prove the person exists, which is important scope information not present in 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?

Two tightly written sentences with zero waste. The core purpose is front-loaded, followed immediately by the key limitation, making the description easy to scan and act on.

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

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

For a single-parameter, read-only validator with full schema coverage and clear annotations, the description provides enough context to call it correctly: it names the ID types, lists the checks performed, and warns about the format-only limitation. It does not explain the return shape, but with no output schema and low complexity, this is a minor gap.

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

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

Schema description coverage is 100% and the single parameter's format is illustrated by the example in the schema. The description adds that the value can be a personnummer or samordningsnummer, but does not provide additional syntax or parsing rules beyond what the schema example already conveys, so the baseline 3 applies.

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

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

The description states a specific verb (Validate) and resource (Swedish personnummer or samordningsnummer), and it lists exactly what aspects are checked (format, Luhn checksum, birth date, age, gender). This distinguishes it from sibling validators like validate_orgnr and validate_iban without needing to inspect their schemas.

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

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

The description implies usage by naming the target ID types, but it does not explicitly say when to choose this tool over sibling validators or provide any exclusions beyond the note that it does not prove existence. The guidance is adequate but leaves the agent to infer routing from the tool name and sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that the tool both validates and formats, which is useful beyond the annotations, but it does not explain what formatting means or what the result contains.

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

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

A single, front-loaded sentence with no wasted words. It communicates purpose immediately and is appropriately sized for a simple one-parameter validator.

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 this is adequate for selection, but with no output schema the description leaves unclear what validation and formatting actually return or how failures are represented. It is minimally complete rather than fully informative.

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 single 'value' parameter is already documented in the schema with an example ('123456-6'). The description adds no syntax, normalization, or input constraints beyond the schema, so the 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 states a specific verb pair ('Validate and format') and a precise resource ('Swedish plusgiro number'). The resource itself distinguishes it from sibling validators like validate_bankgiro and validate_orgnr, though no sibling is named explicitly.

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

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

There is no guidance on when to use this tool versus alternatives such as validate_bankgiro or lookup_clearing_number, and no prerequisites or exclusions are stated. The sibling list implies a domain-specific validator, but the description itself provides no routing guidance.

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