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

Beyond the annotations, the description discloses substantial behavior: login and host-permission requirements, that returned fields are restricted to authorized reasons/read-activity status/AI judgment and exclude contact info, private chat, and internal notes, and that each call tops out at 20 supplementary evaluations. This explains why readOnlyHint=false while destructiveHint=false (the call triggers AI evaluation rather than being a pure read), so no contradiction. It stops short of describing pagination or outcome shape.

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 text is dense and front-loaded, leading with the login/permission gate before field scope and limits. Every clause carries a distinct constraint (auth, field policy, batch cap), though a few terms remain cryptic without parameter context.

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 tool with no output schema and no annotation-level field detail, the description covers the access gate, data-scope policy, and per-call cap. It omits the many filter/pagination parameters and the shape of returned records, so an agent can call it but not confidently exploit its filters.

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 carries the burden, yet it explains none of them. It gestures at the read-state and activity concepts and references an 'UNAVAILABLE' state that is not even in the enum lists, but gives no meaning for q, sort, limit, value, cursor, source, direction, includeDone, or organizationId. This is well below what 11 undocumented params require.

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 implies a listing of host follow-up items but never states the verb+resource explicitly, leaning on the name/title for the core action. It focuses on permission, field scope, and limits rather than telling the agent plainly what it returns. It also does not distinguish itself from close siblings log_host_followup, remind_host_followup, or set_host_followup_done.

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?

There is one predictive when-not cue ('UNAVAILABLE仍未判断，勿据此催促' - do not use this to prod when a record is still unjudged), which gives partial usage context. However, it never says when to prefer this tool over the sibling follow-up tools, nor describes prerequisites beyond the host-permission note. Usage is only implied.

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