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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the bar is lower. The description nonetheless adds material behavior beyond them: the tool performs no side effect ('opens nothing by itself'), its output is procedural guidance rather than data, and the ManyChat API is plan-gated and narrow. What it omits is pagination/return shape beyond 'screens, buttons, fields.'

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?

Three compact sentences, front-loaded with the headline and immediately corrected with the key caveat. Minor waste in 'Returns how to do it in ManyChat step by step' (redundant 'in ManyChat') and the oddly specific '(checked 5 Nov 2026)' provenance stamp, though the latter does signal freshness.

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 no output schema, the description must explain returns, and it partly does (step-by-step screens/buttons/fields). But it never resolves whether contact records are returned at all, which is exactly what an agent calling 'list_contacts' needs to know; the gap is covered only by inference from 'opens nothing by itself.'

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 the baseline is 4. The description correctly implies no inputs are needed and nothing in the text misleads about parameters.

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 name and first sentence promise a data listing ('List contacts in the user's own ManyChat account'), but the second sentence reveals the tool returns step-by-step instructions ('screens, buttons, fields') and 'opens nothing by itself.' That internal tension means an agent must read past the headline to know it gets a how-to, not a contact list, and no sibling such as cotlet_app_guide or manychat_get_contact_profile is named to disambiguate.

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?

The description does route the agent forward: after this, act with the cotlet_browser_* tools in the user's ManyChat Cloud Browser. It also flags an API constraint (official API exists only on Pro plan or higher and is narrow), which is useful for deciding whether to use this path. However, it never states when NOT to use this tool or names the closest sibling alternative (cotlet_app_guide), leaving prerequisite logic implied.

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