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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closure are covered elsewhere; the description adds that this is pre-written buying guidance rather than live data. It says nothing about whether the response is one consolidated answer or a list of matching FAQ entries, or what happens when the tag matches nothing — modest added value given the 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?

Two sentences, front-loaded with the topic inventory before the usage examples. The quoted example questions partially restate the topic list, but they serve a distinct routing purpose, so the mild redundancy is defensible.

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-required-parameter, read-only lookup with no output schema, the description gives sufficient coverage of subject scope and question mapping. The only shortfall is the absence of a return-shape or no-result hint, which is a minor gap at this complexity level.

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 sole 'tag' parameter is already documented with examples in the schema, so the baseline applies. The description's topic list ('MOQ', 'artwork', 'delivery', 'eco') loosely mirrors the tag vocabulary, which is mildly reinforcing but adds no new syntax or filtering semantics 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 opens with 'Practical buying answers' and enumerates the exact subject matter covered (MOQ, lead times, setup fees, decoration methods, samples, delivery, payment, eco/Australian-made), so an agent can tell this is a static FAQ/knowledge lookup rather than a product or quote query. It doesn't use an explicit verb like 'retrieve' or 'answer', but the content scope is concrete enough to separate it from siblings such as get_quote or search_products.

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 gives clear positive selection criteria by quoting the question shapes that should route here ('what is the minimum order', 'how fast can I get it', 'what file format for my logo'). There is no explicit exclusion or named alternative (e.g., 'for pricing on a specific product use get_quote'), so the agent must infer the boundary from sibling names.

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