Preview a company

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

Goes well beyond readOnlyHint/openWorldHint: it discloses the asynchronous two-call pattern (a preview_id is returned, call again with it to collect the read), the ~1 minute latency, and that no account is needed. It even describes the downstream handoff where the preview_id carried into signup_start turns the read into the user's first ICP — context no annotation or schema conveys.

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 trigger and beneficiary are front-loaded before any mechanics, and every sentence carries information. The style is choppy ('Send the website. No account needed.') and slightly chatty, but no sentence is expendable.

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, so the description carries the return-value burden and does it: the three content areas of the read are enumerated, plus the preview_id handle and how to collect the result. An agent has everything needed to make both calls 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 coverage is 100%, so baseline is 3, but the description adds real meaning: 'Send the website' identifies the first-call input and 'call again with it to collect the read' explains that previewId is the second-phase key rather than a filter. That sequencing is not obvious from the schema alone.

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 (preview a company's website read for its buyers) and spells out what the result contains: who the company sells to, the deciding buyers, and site-versus-need gap. The pre-signup framing ('before they have an Andru account') also separates it from account-dependent siblings like assess_company_readiness and get_pre_brief.

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 an explicit trigger ('Before any outreach') and a clear prerequisite state (person has no Andru account yet, just wants a preview of how the site reads). It does not name a specific alternative tool for the case where the person already has an account, so the boundary is implied rather than routed explicitly.

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