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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: answers are grounded in the team's real support history + verified policy, and the tool degrades gracefully by returning escalate:true on no match. It doesn't mention grounding failures or confidence/rate behavior, keeping it below 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?

Front-loaded with purpose, then return behavior, then usage examples — a sensible priority order with no filler sentences. The long enumerated topic list is the bulkiest part but each entry maps to a real query class an agent might route here, so it earns most of its space.

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

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

For a single-parameter, read-only Q&A tool with an output schema present (so return shape needs no explanation), the description covers purpose, scope, fallback/escalation behavior, and triggering examples. Nothing an agent needs in order 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?

Only one parameter with 100% schema description coverage ('the customer's support question, in their own words'). Per the baseline rule, the schema already carries the parameter meaning and the description adds nothing about phrasing, length, or formatting constraints. A 3 is correct.

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?

Specific verb+resource ('Answer a customer's support / FAQ question') with explicit scope: an enumerated list of covered topics (turnaround, proofs, artwork specs, pricing, delivery, cancellations, reorders, guarantee). This lets an agent distinguish it from narrower siblings like vivid_order_status, vivid_proof_status, or vivid_contact_team without opening any 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 four concrete trigger questions ('how long does it take?', 'what file format do you need?', etc.) and states the handoff condition when nothing matches (escalate:true). It lacks explicit when-not-to-use guidance, and a phrase like 'how long does it take?' plausibly overlaps with vivid_delivery_estimate / vivid_fulfilment_production_stage, with no stated boundary.

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