Tell Andru what you sell

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

The annotations already disclose a non-read-only, open-world, idempotent operation. The description adds useful context beyond that: it saves and remembers product information, triggers an approximately 3-minute process, produces a product description and first ICP, and is reused by later calls. It does not clarify overwrite behavior or failure modes, 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?

The description is front-loaded with the triggering condition and is tightly structured. Each sentence adds operational value: when to use it, what to send, what gets produced, how long it takes, and how to inspect the saved result.

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 setup tool with full schema coverage and annotations, the description covers the essential context: purpose, trigger condition, inputs, side effects, timing, and no-argument inspection behavior. It leaves a small gap around whether calling again updates or overwrites existing product context, and what the immediate response looks like.

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 each parameter. The description still adds value by framing website and productDescription as alternatives and by explaining the no-argument behavior for inspecting saved context. It does not discuss vertical or targetRole, but the schema covers those.

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 gives a specific verb and resource: tell Andru what the company sells so it can save a product description and generate a first ICP. It implicitly distinguishes this from later retrieval tools by saying 'Every later call uses it,' but it does not explicitly name siblings such as get_icp_profile, so it falls short of full sibling differentiation.

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 clearly states when to call: when the person tells you what they sell, or Andru does not know the product yet. It also says to send a website or product description once, and that calling with no arguments shows what Andru has saved. It stops short of naming alternative tools or explicit when-not conditions.

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