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

The most important non-obvious trait is disclosed plainly: it 'opens nothing by itself' and only returns screens/buttons/fields, which matches readOnlyHint=true and prevents an agent from assuming the conversation is actually resolved. It also tells the agent the exact channel to use for execution, which annotations alone cannot convey.

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 behavioral core is front-loaded and clear, but the final sentence about Chatwoot's REST API and lack of an official MCP server is vendor trivia that does not help an agent select or invoke this tool. It adds length without decision value.

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 a zero-parameter, no-output-schema tool, the description covers what is returned and what to do next, which is the full workflow. The one gap is that with no inputs it is unclear whether the returned steps are conversation-specific or generic, which could mislead an agent expecting targeted guidance.

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?

There are zero parameters, so the baseline is 4 and the schema already covers the input contract fully. The description adds no parameter guidance because none is needed, but it also never addresses how a conversation is identified given the empty input 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 names a specific verb pair and resource ('Resolve or snooze conversation in the user's own Chatwoot account') and immediately clarifies that the tool returns instructions rather than acting. It is distinguishable from the cotlet_browser_* executors, though it does not differentiate itself from the chatwoot_* action siblings like chatwoot_assign_conversation.

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 an explicit follow-up path: call this first to get the step-by-step procedure, then perform it with the cotlet_browser_* tools in the Cloud Browser. What is missing is negative guidance - when to skip this tool and go straight to the browser, or how it relates to the other chatwoot_* tools.

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