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 cover readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: a character ceiling, a literal 'đã cắt' truncation marker in the output, and that source plus product version are returned. That truncation disclosure is exactly the kind of trait annotations cannot express.

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 sentences are front-loaded and information-dense, with the slug source first and the section/truncation caveats after. The trailing English sentence restates the Vietnamese rather than adding content, a small redundancy that costs a point.

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 carries the return-value burden and does so reasonably: text content, truncation marker, source, and product version. For a three-parameter read tool this covers what an agent needs to call and interpret it, with only the max_chars default left unclear.

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 67%; the description adds meaning for anchor ('để lấy đúng một mục') beyond the schema's terse 'Mã mục', and explains the truncation context tied to max_chars. It never names max_chars or its default explicitly, so the third parameter remains only implicitly documented.

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 verb and resource ('Lấy nội dung văn bản của một bài công khai theo slug') and notes the section-level variant via anchor, so it is unambiguous about what is fetched. It points to kb_list_pages for slug discovery, which distinguishes it from the listing sibling, though it never contrasts with kb_search.

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 parenthetical '(xem kb_list_pages)' tells the agent where slugs come from, and the anchor clause explains when to fetch a single section instead of the whole article. There is no explicit exclusion against kb_search, so routing guidance is good but not exhaustive.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is settled. The description adds that only public articles are returned and which fields come back, but says nothing about ordering, default page size, or what happens when category is omitted.

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

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

Two sentences, front-loaded with the verb and resource, then the filter. The Vietnamese/English duplication is a mild redundancy but justified for a bilingual Knowledge Center tool; 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 simple, read-only, two-parameter list tool with no output schema, this is close to complete: scope, returned fields, and valid categories are all covered. The only real gap is default/limit behavior for the `limit` parameter.

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 0%, so the description carries the burden. It fully compensates for `category` by enumerating all eight accepted slugs (a real value-add the schema lacks), but it never explains `limit` — no default value, no note that it caps at 60 — so compensation is only partial.

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 ('Liệt kê bài công khai' / 'List public Knowledge Center articles') and even names the returned fields: slug, tiêu đề, tóm tắt. It does not explicitly distinguish itself from siblings like kb_search or kb_get_page, 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?

Filtering by category is described, and the eight valid category slugs are listed, which implies the browsing use case. However, there is no explicit when-to-use guidance versus kb_search (query-based retrieval) or kb_get_page (single article fetch), and no 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 declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. Beyond that, the description adds genuinely new behavior: a hard cap of 8 returned items, the return components (short excerpt, source URL, applicable product version), and an explicit fallback of stating no information exists when no source is found — an important signal about how to interpret empty/low-confidence results.

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 short and front-loads the resource and language scope before the return-value details. The Vietnamese and English sentences partially duplicate each other, but the bilingual pairing is deliberate for a Vietnamese-facing tool and the English line adds the 'public' qualifier.

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 correctly carries the burden of describing return values (max 8 items, excerpt, source URL, product version) and the no-source fallback. Nothing essential for calling the tool is missing, though a pointer to kb_get_page for full article retrieval would close the remaining 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 both parameters (query, limit) are already documented in the schema with bounds and defaults, so the baseline is 3. The description does add one meaningful semantic note — queries accept Vietnamese with or without diacritics — plus the 8-item ceiling, but it does not explain the query length constraint or how limit interacts with the returned result count beyond the cap.

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 pairs a specific verb ("Tìm"/"Search") with a specific resource ("Trung Tâm Tri Thức SB"/"public Knowledge Center") and states the answer shape (cited excerpts from articles). It is clearly distinguishable from kb_get_page and kb_list_pages by being a query-based search, though it never names those siblings to make the contrast explicit.

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 this is the tool for keyword/question lookup in the knowledge base. There is no statement of when to prefer it over kb_get_page or kb_list_pages, and 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 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.