DMCommerce

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

Annotations already establish that this is a read-only, non-destructive, non-open-world operation. The description adds useful behavior beyond annotations: pagination is 20 per page, and the first page also returns available filters and the total. It does not describe authentication or rate limits, but for a read-only browse tool that is a minor 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 description is compact and front-loaded: it starts with the core scope, then enumerates supported browsing dimensions, then notes pagination and first-page metadata. Despite listing many capabilities, it does so efficiently without redundant explanation.

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 12-parameter browsing tool with no output schema, the description provides important context: page size, first-page filter/total metadata, and supported filtering and sorting dimensions. It still does not describe the shape of returned product objects, but the schema and annotations cover most other needs.

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 every parameter is already documented in the input schema. The description restates the main filter and sort capabilities in prose, including BRL price range and the available sort dimensions, but adds little semantic detail 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 clearly states the resource and scope: products from one store, browsable by category, tag, brand, filters, price, stock, sale/featured status, and sort order. It distinguishes itself implicitly from broader search by requiring a single store, but it does not explicitly contrast with sibling tools such as search_products or list_categories.

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 usage by framing the tool as browsing products of one store like the store website, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent can infer that this is for store catalog browsing rather than product lookup or search, but the routing guidance is not spelled out.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is handled. The description adds real behavioral value beyond that: a result cap of 20 stores and the shape of each result (website and main categories), which tells the agent what to expect and when results may be truncated.

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, no filler. The identification of the resource and domain comes first, then the query modes, empty-input behavior, and return shape — front-loaded in exactly the order an agent needs.

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 single-parameter read tool with no output schema, the description is complete: it names the domain, the search modes, the empty-query fallback, the result cap, and the returned fields. Nothing an agent needs to call it correctly 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 single parameter is fully documented in the schema, including the empty-string behavior and examples in Portuguese. The description's examples ("jeans", "suplementos") largely echo the schema's own, so it adds little beyond 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?

States a specific verb and resource ("Find online stores") plus the domain restriction (sell on DMCommerce, Brazil) and the two query modes (by name or by product type). An agent can immediately distinguish it from get_product, search_products, and quote_shipping, which all operate on different resources.

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?

"Leave query empty to list every store" gives explicit conditional usage, and the query examples clarify the two intended search modes. It does not, however, say when to prefer this over search_products or what to do when a store lookup returns nothing, so the alternative-routing guidance is incomplete.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description contributes behavior beyond that: the fixed 7-day horizon, that results include seats left, and that no booking is performed here. It omits timezone assumptions and whether results are cached or live, which keeps it from 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: the first front-loads the return shape, the second carries the prerequisite and the scope boundary. No filler and nothing an agent needs is buried.

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 and no nesting, so the description correctly shoulders the burden of describing returns (duration, 7 days of slots, seats left). The only real gap is lack of timezone/date-anchor detail for a time-sensitive read, which would matter for correct interpretation of the slots.

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 each parameter already documents its source field (find_store/search_products, get_product, search_products/browse_products). The description restates only the option→get_product link, adding no syntax or formatting detail beyond the schema, 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+resource (free days and times of a bookable service) and enumerates the return content: duration in minutes, next 7 days with free slots, seats left. It also bounds the tool's scope by saying the booking itself happens on the store website, so an agent can tell it apart from get_product or search_products 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?

Gives a clear usage condition: check free slots for an appointment/class/visit, then book externally on the store website. It also names the prerequisite source for the option id (get_product). It stops short of naming a sibling as an explicit alternative for the availability check, but the flow it belongs to is unambiguous.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds what the agent cannot get elsewhere: this returns narrative fields plus a conditional campaign object with dates and an open/closed status. It does not say what happens when the category or campaign is absent.

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 dense sentences with no filler. The payload contents are front-loaded and the cross-tool pointer is placed last, which is the right priority order.

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 has to carry the return-shape burden and it largely does, listing the fields and the conditional campaign block. Minor gaps remain around empty/missing results, but for a read-only two-parameter lookup this is close to sufficient.

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% and both required parameters are documented with their source fields (find_store/search_products and list_categories). The description adds a small amount of meaning by noting the id is shared with browse_products, but nothing about format or validation beyond the schema's maxLength.

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?

It names the resource (one store category) and enumerates the returned payload: description, image, subcategories and campaign data. It also distinguishes itself from browse_products by handing product retrieval off to that sibling. The only gap is that the retrieval verb is implied by the name 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?

Usage is implied rather than stated: fetch a single category by id. The one explicit routing hint is that products come from browse_products with the same id, which is a genuine alternative pointer. There is no guidance on when to use this versus list_categories or get_store_info.

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, destructiveHint=false, openWorldHint=false, and the description adds real value by disclosing the return content (options, BRL pricing, availability, deep link), which matters since there is no output schema. It omits any note on missing-product behavior or auth, keeping it 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?

A single front-loaded sentence that leads with the verb and resource before enumerating outputs. It is dense but every clause earns its place by describing the return shape, with no filler.

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 correctly compensates by describing the returned fields, which is what an agent needs for this simple two-param read. It is essentially complete, lacking only edge-case behavior such as invalid-id handling.

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% for both parameters, so the schema already documents store and product ids. The description adds no additional format or constraint detail, matching the baseline for fully documented schemas.

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 (get) and resource (one product) and enumerates exactly what is returned: description, options with BRL prices and availability, and the store link. It is clear this is single-item retrieval, implicitly contrasting with the sibling search_products, though it does not name that sibling 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: the schema notes the id comes from find_store/search_products, but the description itself gives no when-to-use guidance or exclusion against search_products. An agent can infer it fetches a known product id, but nothing is spelled out.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes the useful fact that the result merges two suggestion types, but says nothing about volume, ordering, or what happens when a product has no associations.

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?

A single front-loaded sentence with a colon-delimited breakdown; every clause carries information and nothing is repeated from the schema or annotations.

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 lookup with a fully documented schema, the description is sufficient to call it correctly and even hints at return contents. Only the empty-result and pagination behavior are unaddressed, which is minor here.

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% — both store and product are fully documented in-schema with provenance hints (find_store, search_products, browse_products). The description adds no parameter meaning beyond that, 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?

The description names the resource precisely — recommendations the store associates with a given product — and enumerates the two kinds (related items, "buy together"). This separates it from sibling get_product (single product details) without naming that sibling 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: an agent can infer this is the tool for cross-sell/recommendation lookups, but there is no explicit 'use when' statement, no prerequisites, and no mention of alternatives such as get_product.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds the meaningful detail that the payload is per-size measurements as displayed by the store (not a normalized catalog), but says nothing about the behavior when a product has no chart.

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?

A single compact sentence with the resource front-loaded and the purpose clause appended; no filler or redundancy.

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 lookup with no output schema, the description conveys what is returned (measurements per size) and ties the ids to sibling tools via the schema. Only the empty-result case is left unaddressed, a minor 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 coverage is 100% and both parameters already document their provenance ('store' from find_store/search_products, 'product' from search_products/browse_products). The description adds no further parameter meaning, which is acceptable given the schema does the work.

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 resource (size chart with measurements per size) scoped to a store and product, and adds the intent behind it (help the person choose a size). It is distinguishable from siblings like get_product or list_product_reviews by resource, though it never names an alternative.

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 via the phrase 'to help the person choose the size', which suggests calling it during size selection. There is no explicit when-to-use, when-not-to-use, or pointer to another tool when no chart exists.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the breadth of the payload (a large multi-section read), but says nothing about response size, ordering, or what happens if the store id is invalid.

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?

One dense sentence with no filler, and the most searched-for items (contact, payment, shipping) are listed first. It lacks a leading verb phrase, so the agent must infer the action from the name rather than the opening words.

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, enumerating the returned sections is exactly the right compensation, and the required param is fully documented in the schema. Only the absent routing guidance against overlapping siblings keeps it short of complete.

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% and the schema already explains that 'store' comes from find_store or search_products, so the description need not repeat it. 'of one DMCommerce store' reinforces the single-store scoping but adds no syntax or format detail 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?

The description enumerates precisely what the tool returns — contact details, payment methods, shipping rules, benefits, FAQ, offers and policy pages — for a single store, which is far more specific than the name alone. It scopes the result to 'one DMCommerce store' but never explicitly distinguishes itself from siblings like find_store or read_store_page, which also deal with store-level data.

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 statement of when to reach for this tool versus find_store, read_store_page, quote_shipping or list_promotions, all of which overlap with the returned content. Usage is only inferable from the enumerated payload.

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 and destructiveHint=false, so the safety profile is covered. The description still adds real value by disclosing the returned field set and the crucial temporal qualifier "now", signalling this is live/current state rather than history — important since no output schema exists. Minor gaps remain around emptiness, ordering, and pagination.

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?

One compact sentence with zero filler, and the resource scope is front-loaded before the field enumeration. It is a noun-phrase fragment rather than a verb-led statement, which slightly weakens the lead.

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 single-parameter read tool with a fully documented schema and read-only annotations, the description covers the essential unknown: what data comes back, since no output schema is provided. Nothing critical is missing for a correct invocation.

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?

There is a single parameter and schema description coverage is 100%, with the schema already explaining that "store" is the id from find_store or search_products. The description adds nothing about the parameter, 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?

The description clearly identifies the resource as store home-page banners and enumerates what each banner contains (title, subtitle, button text, link, end date), which tells an agent exactly what a call surfaces. It does not, however, distinguish this from the sibling list_promotions, which an agent could plausibly confuse it with.

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 "What the store highlights on its home page now" plus parenthetical examples (campaigns, launches, sales), so an agent can infer this is for current merchandising content. There is no explicit when-to-use statement and no exclusion pointing to list_promotions or read_store_page for other promotional or page content.

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 the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add behavior — and it does, disclosing newest-first ordering and a 10-per-page page size, which the agent would otherwise have to discover empirically. It doesn't mention what an empty or terminal page looks like, so it stops short of 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?

A single front-loaded sentence with no filler; ordering and page size — the two facts an agent needs — come first.

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 paginated read with full schema coverage and covering annotations, the description supplies the missing runtime facts (ordering, page size) and no output schema exists to require return-value explanation. Only an explicit statement of how pagination terminates is absent.

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 both the store id and cursor are already documented, and the schema even explains where each value comes from. The description adds only the page size, which is relevant context for the cursor but not meaningful parameter detail beyond 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 the resource (articles on the store blog) and its ordering, which lets an agent recognize this as the paginated listing counterpart to read_blog_post. It is clear but never states an explicit verb or calls out the sibling distinction.

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: the plural listing vs. read_blog_post's single-article read is inferable but never stated, and there is no explicit when-to-use or when-not 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the result is a hierarchical tree including category ids, which is useful context, but says nothing about depth, ordering, or size of the result.

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?

A single short sentence with no filler, front-loading the resource and the scope. Nothing 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, one-parameter read tool whose annotations carry the safety profile, the description covers what is returned (tree plus ids). Minor gaps around result size or ordering are acceptable given the tool's simplicity and the absence of an output schema.

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% and the store parameter is documented in the schema, including how to obtain the id. The description adds no parameter-level detail, so the baseline of 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 resource, the category tree, scoped to one store, and notes that each category's id is included. No sibling tool covers categories, so differentiation is implicit rather than stated, and the verb 'list' appears only in the title.

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 never says when to use this tool versus alternatives, nor any prerequisites beyond what the schema already states. It gives no exclusions or follow-on guidance such as using these ids with browse_products.

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 that this is a safe read-only operation. The description adds a useful behavioral detail beyond annotations: an empty result can mean the store does not use Q&A, which prevents misinterpretation of empty responses.

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 a single focused sentence with no wasted words. The core return content is front-loaded, and the parenthetical empty-case note is compact and relevant.

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 read tool with complete schema coverage and safety annotations, the description is largely sufficient. It explains what is returned and the empty-case condition, though it does not mention pagination or ordering.

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 two parameters are fully documented in the schema. The description adds no additional meaning about store or product identifiers, so the baseline of 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 clearly identifies the resource as product-page questions and their store answers, which distinguishes it from reviews and other product data. It does not explicitly say 'list,' but the name and sentence together make the operation obvious.

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 subject matter: fetch Q&A for a given store and product. However, there is no explicit when-to-use guidance or comparison to siblings such as list_product_reviews or get_product.

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 establish that this is a safe read-only operation. The description adds useful behavioral context beyond annotations: only published reviews are returned, results are newest first, and pagination is 20 per page.

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 a single front-loaded sentence with no wasted text. It efficiently combines the resource, returned fields, sort order, and page size.

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 list tool with complete schema descriptions and clear annotations, the description provides the key remaining context: what fields are returned, that reviews are published only, sort order, and page size. No output schema exists, but the description sufficiently indicates the shape of returned reviews.

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 all three parameters and their sources. The description reinforces that the tool operates on one product but does not add syntax or format details 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?

The description states exactly what is returned: published customer reviews for a single product. It clearly distinguishes this from sibling tools like list_product_questions by naming the review-specific resource and its scope.

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: call this when you need reviews for a known product, as reflected by the required product and store parameters. However, the description does not explicitly say when to use this versus alternatives or explain exclusions.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real value by disclosing what comes back — the rule expressed in words and the end date — which tells the agent results are human-readable rather than structured rules. Pagination and result volume are unaddressed.

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?

A single sentence that front-loads the core purpose and uses the parenthetical to enumerate promotion types without waste. Every clause 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?

With no output schema, the description usefully previews the return shape (rule in words, end date), and the annotations cover the safety profile. It is nearly complete; only result size/pagination behavior is left to discovery.

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% and the single `store` parameter is documented in the schema with a helpful hint about where to source the id. The description adds nothing about the parameter, 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?

The description names a specific verb (listing promotions running now) and resource, and enumerates the promotion subtypes (free shipping, buy X pay Y, combo, gifts) so the agent knows exactly what domain this covers. No sibling tool addresses promotions, and the phrasing distinguishes it clearly from product/store lookups.

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 for answering 'what deals are active?' questions, but the description never states when to call it or when not to. Since no sibling overlaps, the absence of named alternatives is tolerable 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine value beyond them with the 'nothing is reserved or bought' assurance and by enumerating the response content (carrier, price in BRL, delivery time in business days), which matters since there is no output schema.

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

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

Front-loaded with the action and object, then a compact clause describing returned fields, then a short no-side-effect sentence. Two sentences with essentially no filler; the only mild redundancy is repeating 'Brazilian postal code (CEP)', which is already in the schema.

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, read-only quote tool with no output schema, the description covers what is quoted, the units of the values (BRL, business days), the checkout-parity guarantee, and the absence of side effects. An agent has everything needed to select and invoke it 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?

Schema description coverage is 100%, so all four parameters (cep, store, quantity, variant_id) are already documented in the schema, including formats and defaults. The description adds only loose context ('a product option', 'Brazilian postal code (CEP)') and no syntax or constraint detail beyond the schema, so the baseline of 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 (quote) and resource (shipping) plus the exact domain of applicability (a product option to a Brazilian CEP). It is unmistakably distinct from find_store, get_product and search_products, which are lookup/browse tools rather than a pricing quote.

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 operating context — it returns the same carrier/price/delivery options the checkout shows, and explicitly notes nothing is reserved or bought. It also implies the prerequisite chain by tying a parameter to the get_product tool, but it never states when to prefer this over, say, a product lookup or what to do if the CEP is invalid.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description contributes the return payload (article text plus mentioned products), which is genuinely additive for a tool with no output schema, but says nothing about size, truncation, or missing-post 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?

A single short sentence with no filler, and the resource is front-loaded ahead of the secondary payload detail. It is terse almost to the point of being a fragment, but nothing is wasted or buried.

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 burden of describing return values, and it does so only at a high level — 'text' and 'products it mentions' — without indicating the shape of the product list or whether content is paginated or truncated. Adequate for a simple two-parameter read, but thin on the one thing the structured data can't cover.

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 document their provenance ('post' field from list_blog_posts, 'store' field from find_store or search_products). The description adds no meaning beyond that, so the baseline of 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 names a specific resource — a single blog article's text — and adds a distinguishing payload (the products it mentions), which separates it from list_blog_posts or read_store_page. It is a noun phrase rather than a verb statement ('read'), but the scope of 'one' article 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?

There is no statement of when to use this vs list_blog_posts, get_product, or read_store_page, and no prerequisites. The only implicit cue is the word 'one', which hints at single-record retrieval, but an agent must infer the list-then-read workflow entirely on its own.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that the result is scoped to exactly one page, but says nothing about size or pagination 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?

A single front-loaded sentence with no waste, though it is a sentence fragment and omits an explicit verb such as 'returns'.

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 tool with full schema coverage, no output schema and complete safety annotations, this covers what an agent needs: what it returns (page text), the granularity (one page), and the available content types.

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 the store and page parameters are already documented with their provenance (page id from get_store_info, store id from find_store or search_products). The description's page-type examples add only marginal meaning beyond that 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 states the resource and the scope: the text of one page of a store, with examples of the page types available (exchanges/returns, privacy, delivery, about us). It is clear enough to separate from metadata siblings like get_store_info, though the verb is only implied 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?

Enumerating the page types implies when the tool is useful, but there is no explicit guidance on when to call it versus get_store_info or the product/listing siblings, and no stated prerequisites beyond what the schema says.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: result cardinality ("up to 10 products"), currency (BRL), and the fields returned (price, stock status, store, product link), which is valuable given there is no output schema.

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

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

A single compact sentence with the action and scope front-loaded and no redundant filler. It is efficient, though the return-value details could be separated into a second sentence for easier scanning.

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 usefully compensates by summarizing what comes back (up to 10 products, BRL price, stock flag, store, link) and the geographic scope. It leaves minor gaps around whether results are ranked or paginated and how it relates to get_product.

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 query, store and max_price in detail, including Portuguese query examples. The description adds only the all-stores-or-one-store framing for the store parameter and does not elaborate on max_price or query formatting, 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 ("Search products for sale in DMCommerce stores (Brazil)") plus the scope (across every store or one store), which is enough for an agent to identify the operation. It does not explicitly contrast with siblings like get_product or find_store, so it falls 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?

Usage is implied by the scope statement (all stores vs one store) and by the store parameter's reference to find_store, but there is no explicit when-to-use guidance. An agent is left to infer that find_store should be called first to obtain a store id and that get_product handles single-product lookups.

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