Sulato Business Tools

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data and the description does not contradict it. What the description adds is content scope — the returned material covers positioning, website, pricing, and trial instructions — which is genuinely useful for deciding whether a call will answer the user's question. It does not describe output format or length, which for a documentation-style tool is a modest remaining gap.

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

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

Two short sentences, front-loaded with the topic list, which is the most decision-relevant part. The second sentence repeats 'Official information about Sulato Business' verbatim from the first, which is mild redundancy, though the bilingual phrasing serves the Vietnamese target audience.

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

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

For a zero-parameter, read-only, non-destructive info tool with full annotation coverage and no output schema, the description supplies everything needed to decide to call it: what content it returns and for which product. Nothing about invocation is missing; only the response shape is unspecified, which is acceptable at this complexity.

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

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

The tool takes zero parameters, so there is no parameter meaning for the description to add; baseline 4 applies. The description correctly implies no inputs are needed to retrieve the information.

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

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

The description names the resource (Sulato Business) and enumerates the exact content the tool surfaces: what it is, what it can do, website, pricing, and how to try it. That makes the verb+resource unmistakable and clearly separates it from the calculator siblings (calculate_vat, build_quote, vietqr_payload), which do computation rather than return product information. It stops short of 5 only because it never states the operation form explicitly (returns a document/text vs. performs an action).

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

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

Usage is implied rather than stated: an agent can infer this is the tool to call when a user asks about Sulato Business itself, its pricing, or trial signup. There is no explicit when-to-use or when-not-to-use rule, and no mention of the alternative path (e.g., using the calculator siblings once the user is actually working inside the product). Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond that: it discloses the return artifact ('bảng markdown sẵn để gửi khách') and that the total is spelled out in words, which tells the agent the output is a finished document rather than structured data. It does not state rounding or total-reconciliation behavior, so it stops 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?

Two tight sentences, front-loaded with what the tool produces, then the return format. The Vietnamese and English sentences are largely duplicative, which costs a little, but the duplication is defensible for a Vietnamese-market tool and nothing else is wasted.

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

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

For a 6-parameter generator with no output schema, the description covers purpose, covered domains and the return format, which is what an agent needs to select and call it. Missing are the constraints the schema holds silently (VAT allowed values, payment percentages summing to 100, 100-item cap), which the description could have surfaced but does not.

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 83%, so the schema already documents vat_rate, unit_price, valid_days, payment_schedule and the party names. The description restates the parameter concepts (line items, discounts, VAT, milestones) but adds no new syntax, default, or constraint information beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource: it builds a Vietnamese quotation ('Lập khung báo giá tiếng Việt') and enumerates the substance it covers (line items, quantity, unit price, discount, VAT, payment milestones, amount in words). The second sentence distinguishes it from the calculator siblings by naming the concrete output artifact, a markdown table ready to send to the customer.

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: an agent can infer it should call this when a customer-facing quote document is wanted rather than a bare number. There is no explicit when-not to use it (e.g., versus calculate_vat or calculate_selling_price for single computations), and no prerequisites or exclusions are 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 establish readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. Beyond that the description usefully adds that rounding is always upward and that VAT is optional rather than required, but it says nothing about what exactly is returned (pre-VAT vs VAT-inclusive figures) or about the margin<100 boundary.

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

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

Front-loaded with the core operation, single logical sentence per language, no filler. The full Vietnamese/English duplication roughly doubles the length, which is defensible for a bilingual tool but does cost some economy.

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 should clarify what the tool returns, and it only hints that a VAT-inclusive price accompanies the base price. For a five-parameter calculation tool with two output variants, that leaves the agent guessing about the response shape.

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 every parameter, including the margin/markup enum meaning, the round_to default of 1.000 đ, and the allowed VAT rates. The description adds only the VND currency context and does not elaborate on round_to or vat_rate 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?

States a specific verb+resource: compute selling price from unit cost, with the two calculation methods (margin/markup), rounding up, and optional VAT in VND. It clearly distinguishes itself from calculate_vat (which only computes tax) by framing VAT as an optional add-on, though siblings build_quote and simulate_referral_commission are not addressed.

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 by the purpose statement — there is no explicit when-to-use or when-not-to-use guidance, and no routing to calculate_vat or build_quote even though both overlap with pricing/tax work.

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 annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered and carries little burden. The description adds the rate whitelist and VND scope as useful context, but it does not say what the tool returns and does not address rounding for integer VND amounts during extraction. That leaves a real gap for a calculation tool.

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

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

The definition is two compact clauses, front-loaded with the core operation and then the currency and locale qualifier. It wastes little, though the bilingual duplication repeats the same content without adding new meaning.

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 three-parameter calculator with rich annotations and 100% schema coverage, it is mostly adequate. But with no output schema, the description should say what is returned (net, VAT amount, gross) and how fractional extract results are rounded, and it omits both.

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, with enums for vat_rate and direction. The description restates the direction semantics and the currency and adds no format or edge-case detail beyond the schema, which puts it 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?

The description names a specific verb pair and resource: add VAT to a net price or extract VAT from a gross price. It adds the domain (Vietnam, VND) and the allowed rates 0/5/8/10, which separates it cleanly from siblings such as build_quote and calculate_selling_price.

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 two directions: use 'add' when you have a net price, and 'extract' when you have a gross price. However, the description never routes the agent among the sibling tools, and it does not explain when to use this instead of build_quote or calculate_selling_price.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds content-scope information (the workflow spans inquiry through collection), but says nothing about what an unknown or unsupported profession returns, whether the lookup is exact-match or fuzzy, or how many stages are typically produced.

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

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

The purpose is front-loaded in the first clause and reinforced by a concise English restatement. However, the parenthetical enumeration of roughly fourteen professions is long and largely duplicates the examples already present in the schema parameter description, so it does not fully earn its space.

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

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

For a one-parameter read-only lookup this is close to adequate, and annotations carry the safety contract. But with no output schema, the description should say what the response looks like (a list of stages/steps, keyed by profession) and how unknown professions are handled; that gap leaves an agent unable to anticipate the return value.

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 parameter already documents accepted forms ("spa", "nha khoa", "nha-phan-phoi-dai-ly"). The description's broader profession list adds some vocabulary beyond the schema examples, but no new syntax, mapping, or matching rules — 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 concrete resource — a step-by-step operating workflow for a specific profession, framed end-to-end 'from customer inquiry to cash collection' — and enumerates the supported professions (spa, nha khoa, agency, xưởng may...). An agent can tell this is a workflow lookup rather than a pricing or quoting tool, 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?

Usage is only implied by the purpose: call it when you need the operating process for a given profession. There is no explicit when-to-use vs. when-not guidance and no pointer to alternatives such as about_sulato_business, so the agent must infer the boundary itself.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds the 3-tier cap and the default rate programme, which is useful domain context. However, with no output schema present, it gives no indication of what the simulation returns (per-tier amounts, totals, rounding), leaving a real behavioral gap.

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

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

The Vietnamese and English sentences are essentially verbatim translations of one another, so roughly half the text is redundant token-for-token. It is front-loaded and free of hedging, but the duplication is real waste.

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

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

For a small read-only computation tool with 2 fully documented parameters, little is needed. Still, the absence of an output schema means the description should say what a simulation result looks like, and it does not; nor does it note whether rates beyond 3 tiers are truncated.

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

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

Schema description coverage is 100%, so both parameters (order_value in đồng, rates array defaulting to [20, 8, 5]) are already documented in the schema. The description only restates the default rates rather than adding constraints or interpretation beyond them, so the baseline 3 applies.

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

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

States a specific verb and resource: simulating referral commission on an order, capped at 3 tiers, with default program rates 20/8/5%. An agent can tell this computes multi-tier referral payouts. It does not, however, contrast itself with plausible siblings like build_quote or calculate_selling_price, so a 4 rather than 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 when-to-use guidance, no mention of preconditions (e.g. whether an order must exist or whether this is purely hypothetical), and no routing to or away from sibling tools. Usage is only implied by the verb 'Mô phỏng / Simulate'.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description doesn't need to repeat safety. It instead adds non-obvious behavior: account information is not stored, and the output is a standard EMVCo payload usable by any QR library. Return shape details (prefix, CRC) are omitted but are standard for the format.

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

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

The core purpose and the no-storage caveat are front-loaded in the Vietnamese sentence, which is efficient. The trailing English sentence largely duplicates it, which is a minor redundancy rather than bloat.

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 four-parameter, flat, non-networked tool with full schema coverage and annotations covering safety, the description covers purpose, optionality and downstream usage. It says nothing about the payload's format or failure modes for invalid BINs, but those are marginal for a straightforward builder.

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

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

Schema description coverage is 100%, so the schema already explains bank (BIN or abbreviation), amount, message and account_number. The description only restates that amount and message are optional, adding little beyond structured fields; 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 first sentence names a specific verb and resource: it creates a VietQR (NAPAS) bank-transfer QR payload string for a Vietnamese bank account, optionally with amount and message. No sibling tool (quote, VAT, pricing, referral) overlaps, and the English sentence confirms scope. An agent knows exactly what this produces.

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

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

It tells the agent what to do with the result — feed the string into any QR-generation library — which is the key downstream step. It does not state explicit when-not conditions or alternatives, but no sibling tool offers a comparable capability, so the practical gap is small.

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