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

With no annotations provided, the description carries the full disclosure burden, and it delivers: it states what is destroyed (scanner + observations tab), what is preserved ($recording_observed events), the connectivity requirement, and the write-tier approval model. For a destructive operation, this is exemplary transparency — an agent knows exactly what side effects to expect.

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 core content is two tight sentences with the action and scope front-loaded and the caveat following naturally. The bracketed write-tier approval paragraph adds useful context but is a slight distraction from the core purpose and might fit better in annotations; still, nothing is wasteful.

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 simple 2-parameter delete tool with full schema coverage and no output schema, the description covers purpose, preconditions, scope of destruction, and authorization behavior. The only minor gap is that it doesn't describe the success response/return value, but for a delete operation an agent can reasonably infer success from the absence of an error.

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 both parameters (id as 'Scanner UUID' and companyId with its company-scoping note) are already fully documented. The description adds nothing new about the parameters, which is acceptable given the high schema coverage — baseline 3 applies.

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 states a specific verb-resource pair ('Delete a Replay Vision scanner') and precisely scopes what is removed (the scanner and its observations tab) versus what persists ($recording_observed events stay in the event stream). This clearly distinguishes it from the create/get/list/update vision scanner siblings without needing to open 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?

'Use when retiring a scanner' gives an explicit trigger condition, and 'Only works if PostHog is connected' states a useful precondition. It also names the intended audience (operator or analytics agent). It doesn't explicitly address when *not* to use it or suggest alternatives like posthog_update_vision_scanner for a softer disable, but the core guidance is clear.

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