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?

Beyond the readOnly/openWorld annotations, the description discloses the rate mechanism in detail: NFEM volume-weighted average for USD versus CBN selling rate for other currencies, the guarantee that it is never a parallel-market figure, and the three return fields (amount, rate, trading date, source). This is exactly the kind of behavioral context annotations cannot carry.

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 and rate-source caveat, and the closing link to the interactive version is useful rather than filler. It is dense but every sentence carries information; the em-dash clause is slightly heavy but not wasteful.

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 no-output-schema tool it compensates well by describing the return payload and the rate provenance. Minor gaps remain — no mention of rounding/precision or how unsupported amounts are handled — but nothing critical to 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 coverage is 100% so the schema already documents defaults, enums and date format. The description adds real value by explaining why the to/from pair matters: USD resolves via NFEM while other currencies use the selling rate, which is semantic information absent from the enum alone.

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+resource (convert amounts between NGN and USD/GBP/EUR and others) and scopes it precisely to the CBN official rate, distinguishing it from any parallel-market conversion. The title and first sentence together make the tool's function unmistakable against siblings like ng_vat_calculate or invoice_totals.

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

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

It gives clear context for when to reach for this tool (official CBN rates, latest or a past invoice date) and explicitly excludes parallel-market figures, which is a useful negative constraint. However, it never names an alternative tool or states when NOT to use it beyond the parallel-market caveat, so it stops short of full routing guidance.

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