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 largely covered by structured data. The description still earns credit for adding what the annotations cannot: that this is a public-only view, that no checkout session is opened, and that no customer identity is captured. It does not disclose pagination defaults or result ordering, which is a minor 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 tight sentences, front-loaded with the core action and followed by the scoping constraint. Nothing is redundant, though the second sentence packs both a filter rule and a safety guarantee into one clause, which slightly blurs the structure.

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 5-parameter, all-optional search with no output schema, the description covers what is returned (public products) and the critical non-effects (no checkout, no customer record). Missing details on pagination behavior and language selection are modest, since the schema constrains both and defaults are optional.

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 40%, with query and filter documented in-schema; limit, offset, and language carry no description anywhere. The description partially compensates by explaining the direct-vs-scope distinction that the filter enum encodes, but it says nothing about page size, offset semantics, or what the language enum changes. Baseline 3 is appropriate given the partial coverage and partial compensation.

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 and resource ('Read current public products') and adds a scope distinction between immediate Stripe hosted products and quote-based custom services. It doesn't name any of the adjacent siblings (acorn_public_catalog, acorn_offer_details, acorn_compare_offers), so an agent must infer the boundary from the title rather than the text.

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: this is the read-only search for public products, and the 'no checkout is created and no customer is identified' clause signals it is the non-transactional path. However, no alternative tool is named and no explicit when-not condition is given, so the agent gets context but not routing guidance.

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