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

Annotations only declare destructiveHint=false, so the description carries the rest of the behavioral load and does so: host-role permission required, data deliberately excludes contact details, private chat and internal notes, a hard cap of 20 re-evaluations per call, and the meaning of UNAVAILABLE as 'not yet judged'. Return shape and pagination are left unstated, but the disclosure boundaries are unusually explicit.

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?

It is packed into a few semicolon-separated clauses with no wasted words, but it is front-loaded with a login/permission note rather than a statement of purpose, and the telegraphic phrasing makes it harder to parse than a plain sentence would be.

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 an 11-parameter, no-output-schema list tool, the description covers permissions, privacy scope and the evaluation batch cap but leaves the filter parameters and the returned item structure entirely undescribed. An agent could not select or operate the filters correctly from this definition alone.

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 0% across 11 parameters, so the description must compensate and largely does not. It alludes loosely to read state and activity status and to an AI-judgment value filter, but says nothing about q, sort, limit vs the 20-batch cap, cursor, direction, includeDone, source or organizationId.

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 never states the action directly; it opens with a login/permission prerequisite and then describes disclosure scope ('only authorization reason, coarse read/activity state and AI judgment'). Combined with the name list_host_followups and the title, an agent can infer it returns follow-up candidates for hosts, but the verb and resource are never spelled out.

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 one useful when-not rule: UNAVAILABLE items are undetermined and must not be used to nudge, which is clear usage guidance. But no sibling tools are named (remind_host_followup, set_host_followup_done, log_host_followup) and there is no positive statement of when to call this versus those alternatives.

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