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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: the return value is a procedural walkthrough rather than data, and no browser session is opened or mutated by this call. It also preempts a likely dead end by noting Mews has a Connector API but no official MCP server.

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 key operational facts (returns a step-by-step guide, opens nothing, follow up with cotlet_browser_*) are front-loaded and useful. However, the opening clause 'from ChatGPT, Claude or any AI agent' is promotional filler, and the dated parenthetical about Mews's official API, while mildly useful for avoiding a wrong path, is tangential to invoking this tool.

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 parameters, no output schema, and rich annotations, the description covers enough to call the tool and knows what comes back at a high level. What it leaves unresolved is the gap between its name and its actual return (instructions, not a guest list), plus whether a browser session or login must already exist before the follow-up cotlet_browser_* steps can run.

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 schema baseline is 4 and there is nothing parameter-specific the description needs to add. The description does not introduce any undocumented inputs, which is consistent with the empty 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 resource and scope (guests in house in the user's own Mews account) and then explicitly redefines the output as a step-by-step procedure (screens, buttons, fields). It distinguishes itself from the cotlet_browser_* tools by stating it 'opens nothing by itself.' The only friction is that the verb 'List' in the name implies returned data, while the text says it returns instructions.

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 workflow: call this first to get the steps, then execute them with cotlet_browser_* tools in the Mews Cloud Browser. It also sets a boundary ('opens nothing by itself'), so the agent knows this call alone will not produce the guest list. It does not address when to prefer this over direct Mews siblings like mews_search_reservations, but that omission is outside what the text can reasonably cover.

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