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

Annotations already declare readOnly/idempotent/non-destructive, so the description is free to add what they cannot: the auth requirement (API key or OAuth session; unauthenticated deployments get an `unauthorized`/`not_configured` error envelope rather than data) and per-row enrichment behavior (name/sector/market_cap via the same lookup get_company_profile uses). It also discloses graceful degradation — an unresolvable/delisted symbol returns as a bare row instead of failing the whole call — which is exactly the partial-failure behavior an agent needs to interpret results.

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?

Front-loaded with the trigger and scope, then error semantics, then return shape — a sensible order. It loses a point for restating the same trigger twice ('Use this when the user asks what is on their DalalOS watchlist' and then 'Use this whenever the user asks what's on their (DalalOS) watchlist'), which a single tighter sentence could cover.

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?

No output schema, so the description carries the return-shape burden and does so: bare `symbol`/`added_at` plus best-effort `name`/`sector`/`market_cap`, with the delisted-symbol edge case spelled out. Combined with the auth failure modes, an agent can call this and interpret every likely response without further lookup.

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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description reinforces this by framing the call as caller-scoped with no filtering arguments.

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 ('Get the caller's DalalOS watchlist') and pre-empts the most likely confusion by explicitly excluding brokerage holdings ('a saved list of stock symbols (not brokerage holdings)'). Also clarifies ownership scope ('tied to the caller's DalalOS account'), which distinguishes it from other market-data siblings that take a symbol argument.

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 both a trigger ('whenever the user asks what's on their watchlist') and a sequencing condition ('before adding/removing symbols to check current state'), which routes the agent correctly against add_to_watchlist and remove_from_watchlist. Nothing about when to reach for it is left to inference.

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