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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond them: the tool 'opens nothing by itself', meaning it is a guide generator, not a browser driver. However, with no output schema, it never says what the returned guide looks like structurally (length, whether it includes URLs or selectors), leaving the return contract partly implicit.

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 critical disclosure ('opens nothing by itself') is buried mid-sentence rather than front-loaded, which weakens scannability for an agent that may act on the first clause alone. The opening 'from ChatGPT, Claude or any AI agent' is promotional filler, and the trailing API paragraph, while useful context, is long for a secondary point and includes a dated verification stamp of little operational 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, read-only tool with no output schema, the description covers what is returned (screens, buttons, fields of a walkthrough) and what to do next (cotlet_browser_*). It also preempts the obvious alternative path via the official REST API. The only gap is the absence of any detail on guide structure or expected follow-up sequencing beyond the browser tools.

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 and the schema is an empty object with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline for a parameterless tool is 4. It is appropriate that no parameter discussion appears.

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 states the resource (properties in the user's Breezeway account) and, crucially, corrects the expectation set by the name: it returns a step-by-step how-to guide, not the property data itself. The verb is a bit muddled because 'List properties' is followed by 'Returns how to do it', but the second sentence resolves it explicitly. It does not differentiate from sibling list tools like breezeway_list_people or breezeway_list_tasks, though the resource scope is specific enough.

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 gives an explicit workflow: call this to get the guide, then execute it with cotlet_browser_* tools in the Breezeway Cloud Browser, naming the alternative tool family directly. It also rules out the official REST API path by noting keys require a request form and no MCP server exists. What it lacks is a stated when-not-to-use case, such as what an agent should do if the user only wants the data and not a walkthrough.

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