Zaleso

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

Annotations already mark the operation as read-only; the description adds the output format (words with major/minor unit names and the 'Only' suffix) and the fact that currency determines those unit names. It does not disclose rounding or edge-case behavior, but for a deterministic formatter this is acceptable.

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 the action verb, then the example, then supported currencies and context. The long example earns its place by demonstrating the exact output style. There is no fluff or repetition of schema content.

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

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

With no output schema, the description must convey the return shape, and the example does that effectively. It also covers currency support and the primary use case. Edge cases like rounding, negative amounts, or unsupported currencies are not addressed, but the low complexity of the tool keeps this from being 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?

The schema documents both parameters, so the baseline is 3, but the description adds meaningful semantics: currency is not just an enum but selects the correct unit names (e.g., Naira/Kobo for NGN). The embedded example also reinforces what 'amount' means in practice.

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

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

The description opens with a specific verb and resource — 'Spell a monetary amount in words' — and immediately illustrates the output with a full example. It also lists the four supported currencies and ties the tool to cheque or invoice contexts, which distinguishes it from sibling conversion or generation tools like usd_ngn_convert or qr_generate.

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 usage context — cheques, invoices, specifically the row above the signature line on Zaleso invoices. It does not explicitly name alternatives or exclusions, but the concrete scenarios are enough to guide an agent on when to invoke it.

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

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

The description discloses UTF-8 handling and round-trip safety for accented text, emoji, and non-Latin scripts, which goes beyond the readOnly/idempotent annotations. It also warns against the naive btoa/atob version, adding useful behavioral context. No contradiction 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 main operation is front-loaded, followed by a valuable UTF-8 caveat and an interactive link. The link is arguably optional for an MCP agent, but the overall description is compact and well-structured with no redundant phrasing.

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

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

For a two-parameter, read-only, idempotent transform tool, the description covers the core behavior and input semantics adequately. There is no output schema, but the return value is obvious from the encode/decode framing. It does not spell out invalid-input handling, but that is a minor gap for such a simple operation.

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 both mode and text documented in the input schema. The description reinforces that text may be Unicode but does not add significant parameter-level detail beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Encode text to Base64, or decode Base64 back to text.' This clearly distinguishes base64_convert from its siblings like qr_generate, password_generate, and json_format. The title reinforces the same unambiguous 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 gives clear context for when to use the tool: any time Base64 encoding or decoding is needed. It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough that an agent can select it confidently among the listed 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 the tool read-only, idempotent, and non-destructive, so the bar is lower. The description adds meaningful behavioral detail beyond that: it lists the calculation components, the optional deposit, and the balance due, and it clarifies the boundary with the interactive PDF version. No contradiction 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 compact and front-loaded with the core action, and every sentence contributes useful information. The first sentence is a long enumeration, but it is dense rather than padded, and the PDF pointer is a useful clarification.

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

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

With 8 parameters and no output schema, the description covers the main output concepts and optional inputs, and points to the interactive version for PDF need. It does not give an exact return shape, but the schema handles input semantics well and the annotation set covers safety expectations.

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 restates the roles of discount, tax, and deposit but does not add significant parameter-level detail beyond what the schema already provides, such as defaults, precedence, or formatting behavior.

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

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

The description states a specific verb and resource: 'Compute invoice totals from line items' and then enumerates the exact outputs: per-line totals, subtotal, discount, tax, deposit, and balance due. This clearly distinguishes it from the sibling utilities, which are mostly unrelated conversion or generation 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 context by calling the tool 'Country-agnostic' and noting that the interactive version produces the PDF, which signals that PDF generation is handled elsewhere. It does not explicitly name sibling alternatives, but the context is sufficient for an agent to decide when this tool 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations by stating that invalid input returns the line and column of the error, which helps an agent anticipate failure details. The interactive link is incidental but not contradictory.

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 only two sentences and front-loads the core purpose. The error behavior sentence earns its place. The interactive URL is minor extraneous clutter for an AI agent but does not significantly harm conciseness.

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

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

For a simple pure-transformation tool with no output schema and strong annotations, the description covers the essential behavior and error reporting. It does not spell out the return format, but that is strongly implied by the operation, and the schema fully documents inputs. Minor gap: no explicit mention that mode defaults to format.

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

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

Schema description coverage is 100%, so all parameters (json, mode, indent) are already documented with descriptions and constraints. The description adds no extra parameter-level semantics, which fits the baseline of 3 when the schema carries the burden.

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 operation: "Format (pretty-print) or minify JSON." This goes beyond the title by specifying the exact behavior and also adds the distinctive error-reporting detail (invalid input returns line and column). Among siblings like base64_convert or qr_generate, this tool is unambiguous.

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

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

The description does not explicitly say when to use this tool versus alternatives or when not to use it. Since there are no sibling JSON tools, the usage context is implied: use it whenever JSON formatting or minification is needed. This is adequate but not explicit.

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 mark the tool read-only and idempotent, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: it returns 'the required gross with the full band-by-band working and the statutory source,' and explicitly disclaims authoritative status. This is meaningful context without contradicting the read-only annotation.

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 the core purpose, then explains why the tool exists, then lists what it returns, then adds a caveat and a link. It is slightly longer than strictly necessary — the interactive link and the rhetorical framing could be trimmed — but every sentence contributes to either purpose, usage, or behavioral transparency.

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

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

For a read-only calculator with 100% schema coverage, the description covers the essential context: the calculation direction, the legal basis, the banded-PAYE complication, the return value, and the verification caveat. Since there is no output schema, the brief statement that it returns 'the required gross with the full band-by-band working and the statutory source' is sufficient. Nothing critical is missing.

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

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

Schema description coverage is 100%, so each parameter already carries its own explanation, defaults, and units. The description does not add parameter-level detail beyond noting the PAYE is banded and that gross is derived from take-home, which is more about the tool's approach than about individual parameters. 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 opens with a specific verb and resource: 'Work backwards from a target take-home to the gross salary that produces it.' It also identifies the governing law and tax year, and contrasts itself with rate-based PAYE calculation because 'PAYE is banded.' This clearly distinguishes it from sibling tools like ng_paye_calculate.

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

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

The description gives clear usage context — this is 'the question employers and contractors actually ask' — and explains why a simple rate approach fails. It does not explicitly name ng_paye_calculate as the alternative, but the banding rationale implicitly tells the agent when this tool is needed. The 'Informational only — verify with the tax authority' caveat adds appropriate usage caution.

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 goes well beyond the readOnly/idempotent/destructive annotations by disclosing exactly what the tool returns (take-home, PAYE, effective rate, band-by-band working, statutory source, verification date), which deductions it handles, and that figures are informational and should be verified. This gives an agent a realistic picture of behavior and output before calling it.

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

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

The description is dense but every sentence earns its place: purpose, outputs, handled deductions, statutory basis, and a verification caveat. Key information is front-loaded in the first sentence, with supporting details following logically. The interactive link is a minor extra but relevant for verification.

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 calculator with no output schema, the description sufficiently covers what the agent needs: input semantics are in the schema, outputs are enumerated, deduction rules are summarized, and the legal/verification context is provided. There are no major gaps that would prevent a correct invocation or interpretation of results.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already explains each parameter and default. The description adds useful context about how pension, NHF, and rent relief factor into the calculation, but it largely restates what the parameter descriptions already provide rather than adding new parameter-level meaning.

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

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

The description uses a specific verb ('Calculate') with a precise resource ('Nigeria PAYE income tax and net take-home salary') and adds the governing law and tax year ('Nigeria Tax Act 2025, effective for the 2026 tax year'). This clearly differentiates it from tax siblings like ng_vat_calculate and the reverse-calculator ng_gross_for_take_home.

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

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

The intended use is implicit: use this when you need PAYE and net salary from gross income. However, the description never explicitly states when to choose this tool over the sibling ng_gross_for_take_home, nor does it give exclusion criteria or alternative routing. The usage context is clear but left to inference.

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

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

Beyond the readOnly and idempotent annotations, the description discloses that the rate comes from a verified data layer, is never assumed, and is returned with its source and effective date. It also frames the result as informational, which helps the agent use it appropriately.

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 deliver purpose, data-source behavior, and an important verification caveat without wasted words. The purpose is front-loaded and 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?

For a read-only calculation tool with fully documented parameters and annotations, the description is complete: it explains the modes, the rate provenance, the return contents, and the need to verify with the tax authority. Nothing required for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents mode, year, and amount. The description reinforces the net versus VAT-inclusive distinction but adds no new parameter-level detail.

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

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

The description opens with the exact operations: adding Nigerian VAT to a net amount or extracting VAT from an inclusive amount. It names the resource clearly and distinguishes this tool from sibling tax/salary and conversion tools.

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

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

It provides clear mode-selection guidance: use 'add' when the amount is VAT-exclusive and 'extract' when it is VAT-inclusive. It does not explicitly discuss when not to use the tool relative to siblings, but the mode guidance covers the key decision.

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 mark the operation as read-only and non-destructive. The description adds meaningful behavioral detail by disclosing the cryptographic algorithm (crypto.getRandomValues with rejection sampling) and explicitly ruling out modulo bias, which is significant for a security-sensitive tool. It also states the output contents, going beyond what annotations provide.

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 compact and front-loaded: the core action and security property appear first, followed by the return value. The interactive URL is a minor extra that an API agent does not need, but it does not hurt clarity or distract from the essential 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?

For a stateless generator with a well-documented schema, the description covers the algorithm, the output, and the security guarantee. It could be more precise about the output format or entropy unit, but those details are not required 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?

All three parameters are already fully described in the schema, including defaults for length and symbols and the meaning of excludeAmbiguous. The description adds no additional parameter-level guidance, so the baseline of 3 for high schema coverage applies.

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

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

The description names a specific operation ('Generate') and a precise resource ('a cryptographically secure random password'), and it states what is returned ('the password and its entropy'). None of the sibling tools overlap with password generation, so there is no risk of confusion with alternatives.

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 a clear context: use this tool whenever a cryptographically secure random password is needed. It does not explicitly name when-not-to-use conditions or alternatives, but the sibling list contains no password-generating alternative, so the context is sufficient.

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

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

Annotations already cover read-only and idempotent behavior. The description adds meaningful behavioral context beyond that: 'The code encodes the value directly — no tracking redirect, so it works forever.' This gives the agent useful information about the output's durability and content.

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

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

The core purpose is front-loaded in the first sentence, and the second sentence adds useful behavioral context. The interactive version link is not essential for API agents, which keeps it from a perfect 5, but it is short and does not detract significantly.

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

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

For a simple two-parameter tool, the description covers the essential output format ('SVG image') and the key encoding behavior. Since there is no output schema, it would be slightly stronger to explicitly state the return representation (e.g., SVG string vs. file), but the current wording is sufficient for an agent to understand the result.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description's phrase 'from text or a URL' restates the `text` parameter's purpose without adding new meaning, and it says nothing about `errorCorrection` 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 states a specific verb and resource: 'Generate a QR code as an SVG image from text or a URL.' It clearly distinguishes the tool from its sibling conversion/calculation utilities, which are all unrelated to QR generation.

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 input context ('from text or a URL') and implies the tool is for QR generation when needed. There are no relevant sibling alternatives to exclude, so the lack of explicit when-not guidance is acceptable.

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 state readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the rate is the CBN-published volume-weighted NFEM rate, and the response includes the converted amount, applicable trading date, and CBN source. This helps the agent set expectations without 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?

The description is tight and front-loaded: the core purpose appears in the first sentence, the key rate distinction is explicit, and the return payload is summarized in one clause. The interactive URL is a small, useful addition and does not clutter the definition.

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

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

Given a simple two-parameter tool with complete schema coverage and annotations already covering safety, the description is fully sufficient. It explains the rate source, what the response contains, and how this differs from unofficial rates; no agent-facing gap remains for selecting and invoking 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?

The input schema already documents both parameters completely with types, defaults, enums, and descriptions, so schema coverage is 100%. The description reinforces the conversion concept but does not add meaning beyond what the structured schema provides. This meets the baseline for full schema coverage.

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

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

The description clearly states a specific verb ('Convert'), an exact resource ('USD and NGN at the Central Bank of Nigeria's official NFEM rate'), and immediately distinguishes the result from a parallel-market figure. Among the sibling tools, none overlap with currency conversion, so the tool is uniquely identifiable.

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 establishes a clear use case: convert currency when an official CBN NFEM rate is needed. It explicitly warns that the rate is not a parallel-market figure, providing a helpful exclusion for misuse. It does not name an alternative tool, but the exclusions and specificity are strong enough to guide an agent.

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