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

With only readOnlyHint=false, destructiveHint=false and openWorldHint=false available, the description carries the full behavioral burden and does so richly: it discloses the exclusivity rule, the silent-failure guard for end <= start (and why it exists), the maxDeferHours fallback, and the `warning` field returned when `both` mode strands contacts. This is exactly the mutation-safety context an agent needs.

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 definition is long but justified by an 8-parameter nested tool, and it is structured with a clear gating model first, then the prospect-local windows section with explicit defaults and a recommendation. A few clauses editorialize (the 3am-follow-up aside), which is charming but not strictly load-bearing; still, almost every sentence conveys a rule or default.

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 write tool with a nested object, an enum, and no output schema, the description covers the full behavioral contract, provides defaults for every prospectWindow field, states the read path (li_list_accounts), and notes the returned warning. Nothing an agent needs to invoke it correctly appears to be 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?

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds meaning: it explains that `end` is exclusive with a worked example (20 permits 19:59, refuses 20:00), and that end <= start is coerced to start+1 rather than stored. It also elaborates on how `sendWindowMode` values interact and how `maxDeferHours`/no-timezone contacts fall back, going beyond the schema's terse per-field text.

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 definition names a specific resource (the account's sending window) and precisely scopes what it controls, but it opens by defining the resource rather than stating the action ('set/update the window'), so the verb is inferred from the title and parameters. An agent can still tell this apart from siblings like li_hold_sending or li_pause_account, which affect sending state rather than the hours during which sends are permitted.

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 operational context — which queues are gated (invite drip, scheduled drips, cleanup sweep) and which are not (ad-hoc, bulk, inbox replies) — and even offers a concrete recommended configuration for prospect mode. It stops short of explicit when-to-use/when-not routing against alternative tools, but the conditions that select each mode are spelled out.

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