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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, open-world mutation, so the bar is lower, and the description adds real context beyond them: alerts fan out to the site plus named channels, free accounts cap at 5 watches on hourly/daily digests while Plus allows 50 instant ones, and re-watching the same target mutates the existing watch. It stops short of saying what happens on an uncovered or unresolvable target, or whether the call is rejected when the quota is exhausted.

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 purpose is front-loaded in the first clause and the following sentences layer scope, extension behavior, delivery, and quotas without padding. The trigger illustration sentence is syntactically broken ('is triggers [{...}]'), which slightly interrupts readability of an otherwise dense, efficient block.

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?

With an output schema present, return values need not be described, and the annotations plus a heavily annotated schema handle most structural detail. What is missing for a five-parameter watch-creation call is failure-mode framing: what 'covered' means, whether an unlisted trader or unknown condition ID errors, and what the quota-exceeded path 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 coverage is 80%, so the schema already carries target variants, channel enumeration, trigger kinds, and frequency semantics; the description mainly restates those. Its one genuine addition is a worked smart_money trigger example illustrating how maxTier/minUsd/side combine into the predicate 'a Tier 1 trader buys'. target and idempotencyKey get no added explanation beyond the schema.

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 opens with a specific verb and an enumerated set of target types (question, option, trader, forecaster, category) and states the effect: the owning account is alerted when the target moves. That is far more precise than the title alone. It does not, however, contrast itself with the obvious sibling kellian_delete_watch (or with read-only watch-listing behavior), so an agent must infer lifecycle handling.

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?

Useful implied guidance is present: re-watching the same target extends rather than duplicates, and plan tier determines how many watches exist and how alerts are delivered, which helps an agent decide whether creating a watch is feasible for this account. There is no explicit 'use this instead of X' or stated prerequisite (e.g., the trader must already be listed, the question must be covered), so the when-to-use picture is inferred rather than stated.

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