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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with the concrete clarification that nothing is opened and no reply is actually sent by this tool itself. That two-step behavior is genuinely useful context an agent would otherwise have to infer. It stops short of describing what the returned instructions look like or their format.

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 operative behavior is front-loaded in the first sentence, which is good, but the sentence is a long run-on mixing behavior, invocation path, and a dated aside. The 'ChatGPT, Claude or any AI agent' marketing clause and the 'checked 23 Oct 2026' note add length without helping tool selection.

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 the essential contract (returns instructions, does not act) and names the follow-up tool family. It still leaves out how the subscriber is identified and any expected structure of the returned steps, so an agent lacks full context on the call's outcome.

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 needs no elaboration. A minor gap is that with no inputs, the description never explains how the target subscriber/conversation is determined, which is a natural question an agent would have.

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 first clause states a specific verb and resource (reply to subscriber in Postscript) and immediately qualifies that the tool returns instructions rather than executing anything. It is clearly distinct from siblings like postscript_create_campaign_draft or postscript_find_subscriber, which mutate or look up data directly. Slightly diluted by promotional phrasing ('from ChatGPT, Claude or any AI agent').

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 does route the agent: get step-by-step instructions here, then execute them with cotlet_browser_* tools, and it explains why the official Postscript API/MCP server is not an alternative. However, it never states prerequisites (e.g. that the subscriber must first be located with postscript_find_subscriber) or when-not-to-use conditions.

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