KBeauty Verified™ — K-beauty ingredient rules

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

With no annotations, the description carries the full burden and does well: it discloses data sources, the absence of safety judgments, mandatory attribution, and a non-commercial-use restriction. What is less clear is the shape of what comes back (a description of the service vs. a dataset of sources), though the enumerated topics imply 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?

Purpose is front-loaded in the first clause and the most important constraint (no safety ratings) appears early. There is some duplication — the 'not a safety rating' framing and the attribution/citation rule are each restated — which adds length without new information.

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

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

For a zero-parameter, no-annotation, no-output-schema informational tool, nothing an agent needs is missing: purpose, scope limits, provenance, and the obligations that come with using the data are all present.

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 no parameter guidance is required; baseline is 4. The description correctly implies a no-argument, informational call.

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 precisely what the tool covers: what KBeauty Verified™ is, the provenance of its data (MFDS, CosIng, FDA plus 7 export markets), and explicitly what it does not do (no safety ratings, no lab tests, no medical advice). This clearly separates it from data-returning siblings like lookup_ingredient or check_ingredient_list.

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?

"Call this first if unsure" gives a concrete routing rule for orientation, and the attribution/non-commercial rules tell the agent when it must surface licensing text with results. It does not explicitly contrast against siblings such as official_sources or ask_kbeauty_verified, which would be the natural question for a caller.

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?

With no annotations, the description carries the full behavioral burden and does it well: answers are grounded only in KBeauty Verified™ records with sources, each result carries url/cite fields that must be cited, and the tool is explicitly not a safety rating, lab test, or medical advice. This discloses provenance, output obligations, and limits that no structured field provides.

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 purpose and scope; the language and grounding constraints follow logically. The branding/source URL and attribution paragraph are somewhat boilerplate but do encode a real citation obligation, so little is truly 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 one-parameter, no-output-schema, no-annotation tool, the description covers everything an agent needs: what to send, what language behavior to expect, where answers come from, which result fields to cite, and what the tool must not be treated as.

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 single `question` parameter has 0% schema description coverage, and the description compensates by establishing that it is free-text, may be in English or Korean, and that the answer language mirrors the question. It does not state length/format constraints, but the semantic meaning is well conveyed.

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 ('Ask a question') and a concrete resource domain (K-beauty ingredients, products, sunscreen filters, recalls, KR/EU/US rules). The natural-language Q&A framing implicitly separates it from lookup-style siblings like lookup_ingredient and search_ingredients, but 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?

Gives clear usage context: ask in English or Korean, and the answer language follows the question language. Scope topics are enumerated, but there are no explicit exclusions or pointers to the alternative tools (lookup_ingredient, check_ingredient_list) for structured lookups.

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?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the list is not stored, that results link to exact source pages, the underlying registries (MFDS, CosIng, FDA, plus 7 export markets), and that the output is not a safety rating. It omits operational traits such as rate limits, handling of unparseable lists, and result shape when nothing is flagged.

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 attribution requirement are front-loaded, which is good. However, the 'not a safety rating' disclaimer is stated twice and the licensing/attribution sentence is long, so a portion of the text does not earn 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 multi-jurisdiction regulatory lookup with no output schema, the description covers inputs, data sources, scope, licensing obligations, and interpretive limits. What's left unstated — the shape of a result with no flags, and the effect of the sunscreen flag — is minor but not trivial.

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 both properties. The description reinforces the ingredient-list input format but says nothing about the `sunscreen` flag, which materially changes which U.S. filter rules apply — a missed opportunity beyond the schema baseline.

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

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

States a specific verb and resource — paste a printed ingredient list and get, per jurisdiction (Korea, EU, U.S.), which listed ingredients are prohibited or carry limits/conditions, with links. This clearly separates it from single-ingredient siblings like lookup_ingredient and search_ingredients because the input is a whole label list.

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 input format ('paste an ingredient list as printed on a label') plus explicit exclusions ('not a safety rating, a lab test or medical advice') tell the agent when this tool fits and when its output should not be over-interpreted. It never names a sibling alternative, 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.

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

With no annotations, the description carries the full load — and it does substantial work: it discloses what data is returned (ingredient list with source, regional prohibited/limited/conditional status across Korea MFDS, EU CosIng, FDA plus 7 export markets), a key limitation (labels omit amounts, so limits cannot be verified from the list), and an explicit scope disclaimer (not a safety rating, lab test, or medical advice). Missing only failure behavior for an invalid or unknown slug.

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?

Content is front-loaded with the payload description before provenance and citation obligations. It runs long and mixes data description, licensing, and disclaimers, but each element serves a provenance-dependent tool rather than padding.

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?

No annotations and no output schema, so the description must cover behavior alone — it explains the returned content, its provenance, the key limitation on interpreting limits, and the required citation using fields (`url`/`cite`) that hint at the return shape. Only the not-found/error path is left unaddressed.

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?

One required parameter with 100% schema description coverage — the schema already explains the slug is the trailing part of a search-result URL. The description adds no syntax, format, or example detail about the slug beyond that, 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?

Opens with a concrete verb-and-resource statement — one K-beauty product with its full ingredient list plus per-region (Korea/EU/U.S.) prohibition and limit status — which is specific enough to separate it from search_products and lookup_ingredient. It never names those siblings, though, so the differentiation is inferred rather than stated.

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

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

The description implies a follow-up flow (the schema notes the slug comes from a search result, and the text mandates citing the returned url), but it never explicitly says 'call search_products first' or when to prefer check_ingredient_list/lookup_ingredient instead. The attribution requirement is the only explicit usage instruction.

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?

With no annotations, the description carries the full burden and does so well: it discloses the data provenance (authority lists the service actually holds), that results carry a check date and citation URL, and explicitly bounds interpretation — 'not a safety rating, a lab test or medical advice'. It does not state lookup-miss behavior (empty vs. error) or any rate/limit characteristics, leaving a gap for a tool with zero annotation coverage.

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 opening clause and nearly every clause carries information an agent needs (jurisdictions, field set, provenance, citation duty, non-medical disclaimer). The first sentence is an extremely long run-on and the closing caveat restates ground already covered by 'not a safety rating', costing some density.

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?

No output schema exists, so the description must describe returns — and it does so field by field per jurisdiction, plus the functional-cosmetic sub-record and other_markets. Combined with the provenance, citation, and scope caveats, an agent has everything needed to call this and to report results responsibly.

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

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

Schema coverage is 100% with one required param, so the baseline is 3; the description adds genuine meaning by enumerating accepted name forms — INCI, common, trade, Korean, or slug — which the schema only implies through examples. It still gives no normalization hints (case, spacing, synonym handling) beyond routing ambiguous names to search_ingredients.

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 — retrieve ONE cosmetic ingredient's regulatory rules across Korea (MFDS), EU (CosIng) and U.S. (FDA), plus functional-cosmetic listing and seven additional export markets. It enumerates the exact fields returned (status, max, conditions, label warning, source URL, check date), which lets an agent distinguish this detail-lookup from siblings like search_ingredients or check_ingredient_list without opening a schema.

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

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

'Use search_ingredients first if the name is ambiguous' names a concrete alternative with a clear selecting condition. It also states a mandatory follow-up obligation (cite KBeauty Verified™ with the result URL). It stops short of covering when to prefer check_ingredient_list or other siblings, so not a full when/when-not map.

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?

With no annotations, the description carries the full disclosure burden and does real work: it enumerates the payload (list version, last check, last change dates), names the source jurisdictions (MFDS, CosIng, FDA, plus 7 more markets), and explicitly bounds the tool ('not a safety rating, a lab test or medical advice'). It stops short of describing the response envelope beyond the url/cite fields.

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 leads the sentence, followed by the attribution requirement and the scope disclaimer. It is dense but every element does work, though the licensing/disclaimer clauses run long relative to the operational 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?

For a zero-param, no-output-schema tool, the description covers what comes back (per-market source type, version, check/change dates) and the citation fields (url/cite), which is most of what an agent needs. Minor gaps remain on the overall result shape, but nothing essential 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?

The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. The description correctly implies a no-argument call that returns all markets at once.

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 concretely what the tool returns: the official regulatory lists behind the data, per market, including whether rules come from the authority's own list or a secondary compilation, plus list version and last check/change dates. It implicitly separates itself from the retrieval siblings (get_product, lookup_ingredient, search_*) by being a provenance/metadata endpoint, though it never names an alternative outright.

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 guidance is present but aimed at citation behavior ('name KBeauty Verified™ and link the exact page URL'), not at when to call this tool versus about or recent_updates. The condition for selecting this endpoint must be inferred from the content it describes rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses official data sources (MFDS, CosIng, FDA, plus 7 export markets), a non-safety/non-medical disclaimer, and a mandatory citation requirement, but omits operational traits such as read-only status, freshness window, pagination, and rate limits.

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, followed by attribution and source/caveat information. Every part serves a purpose, though the long attribution/disclaimer clause makes it denser than necessary.

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?

No output schema exists, but the description identifies per-result url/cite fields and explains data sources and limitations. It still lacks full return-shape and freshness/pagination detail, though the tool's complexity is low.

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 only parameter, limit, has 0% schema description coverage. The description says '(up to 10)' but does not explain the limit parameter itself, its default, or that lower values are allowed, so it only minimally compensates for the missing schema description.

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 set of resources: latest official rule changes, K-beauty recalls/alerts, and newly checked products, capped at 10. It does not explicitly differentiate this recency feed from siblings like search_recalls or official_sources, but the purpose is clear from the content described.

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

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

The description implies this is the recency feed, but it gives no explicit when-to-use or when-not-to-use guidance versus search_recalls, official_sources, or other siblings. The instruction about naming KBeauty Verified™ concerns attribution after use, not tool selection.

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?

No annotations, so the description carries the full load — and it does disclose provenance (KBeauty Verified™, official records from MFDS/CosIng/FDA plus 7 export markets), a mandatory attribution/link obligation, and an explicit 'not a safety rating, lab test or medical advice' caveat. Missing only return-shape and pagination/empty-result behavior.

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

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

The core capability is front-loaded in a tight first sentence, but the remaining two sentences are a single run-on mixing licensing, a market-coverage inventory, and liability disclaimers. Useful content, yet the attribution and disclaimer material could be compressed without loss.

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 search with no annotations and no output schema, the definition tells the agent what is searched, the result cap, the source of truth, and that each result carries a `url`/`cite` field. Adequate for correct invocation; only edge-case behavior (no hits, ranking order) is unaddressed.

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 must compensate — and it does: it explains that 'q' matches a word inside any of four distinct name fields, which the bare `string` type does not convey, and the '(up to 10)' mirrors the limit maximum. It doesn't state case sensitivity, minimum query length, or whether limit is optional.

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 (find) and resource (ingredients) plus the matching surface: INCI, common, trade or Korean name. That implicitly distinguishes it from lookup_ingredient (single exact lookup) and check_ingredient_list, 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?

The phrase 'by a word in their ... name' implies substring search rather than exact match, and the '(up to 10)' cap signals a browse-style query. But it never states when to prefer lookup_ingredient or check_ingredient_list over this, nor what to do when no word matches.

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?

No annotations are provided, so the description carries the full burden, and it does substantial work: it names the data source, mandates attribution with the exact `url`/`cite` from each result, and disclaims that results reflect official records rather than being a safety rating, lab test, or medical advice. It omits auth/permission requirements and pagination behavior, but the source and interpretation caveats are valuable beyond-structured context.

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 and cap, then layers attribution and disclaimer boilerplate. The compliance sentences are long but arguably earn their place given the stated citation contract; the description is dense but not padded with trivia.

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 and no annotations, the description still conveys what a result contains (`url`/`cite` fields), the source provenance, and the interpretation limits. For a 3-param read tool this is nearly complete, missing only matching rules and result-shape detail.

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 0%, so the description must compensate, and it does: it explains `q` as a word matched against product or brand name, `brand` as an optional single-brand filter, and conveys the 10-item cap that aligns with the `limit` maximum. It doesn't clarify matching semantics (substring vs exact, case sensitivity), leaving a minor gap.

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

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

States a specific verb and resource with scope: find K-beauty products by a word in the product or brand name, capped at 10 and optionally scoped to one brand. This distinguishes it from get_product (single lookup) and search_ingredients (different resource), though it doesn't name siblings 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?

Implies usage via 'find products by a word in the product or brand name' and the optional brand narrowing, but never states when to prefer this over get_product or other search tools, nor any exclusions. Usage must be inferred from the semantics.

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?

With no annotations, the description carries the burden and does disclose the data source, attribution requirement, and interpretive caveat about what the records are not. It does not disclose return format beyond url/cite, pagination behavior, rate limits, or authentication expectations.

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, but the description is a dense paragraph mixing scope, source list, attribution, legal disclaimer, and interpretation caveat. Some clauses repeat information and could be trimmed without losing 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?

It is reasonably complete for a search tool with no output schema and no annotations, especially regarding sources and attribution. However, it leaves gaps around limit semantics, jurisdiction mapping, result structure, and operational behavior that an agent would otherwise need to infer.

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 must compensate. It gives useful meaning for q (product/brand/company word) and origin (KR products), and the listed jurisdictions imply the jurisdiction enum, but limit is only vaguely referenced as 'up to 10' and jurisdiction is not mapped explicitly to enum values.

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: searching official cosmetic recall, safety alert, and import refusal records. It lists the distinct source jurisdictions and data scope, which clearly separates it from sibling product/ingredient search 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?

Explains that queries are by product, brand, or company word, and notes origin='KR' for South Korea-made products. It also warns that results are not a safety rating, lab test, or medical advice, but it does not explicitly contrast when to use this versus search_products or other siblings.

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