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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the bar is lower. The description still adds real value beyond them: it discloses that the tool 'opens nothing by itself', that the payload is procedural instructions with screens/buttons/fields, and that the actual execution is delegated to browser tools. That is a meaningful operational contract an agent would otherwise not infer.

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 core is front-loaded and efficient, but two clauses waste space: 'from ChatGPT, Claude or any AI agent' is marketing filler, and 'Paperless Post's official API: Paperless Post has no public API (checked 10 Oct 2026)' is clumsily phrased and its date is oddly future-dated. The substance survives, but the wording is not tight.

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 no-parameter guide tool with no output schema, the description covers what matters: what it returns (step-by-step screens, buttons, fields), that it performs no action, what to do next, and why no direct API path exists. It stops short of specifying output format or pagination of events, but the essential behavioral picture is complete.

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. No parameter meaning needs to be conveyed and the empty schema is self-evident, leaving nothing for the description to compensate for.

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 sentence states a specific verb and resource (list events) scoped to the user's own Paperless Post account. The second sentence significantly reframes the tool as returning a step-by-step guide rather than performing the listing, which an agent can only resolve by reading on. Purpose is clear overall, but the name/description mismatch between 'list events' and 'returns how to do it' creates a small initial ambiguity.

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 give the follow-on workflow: after getting the guide, invoke cotlet_browser_* tools in the Paperless Post Cloud Browser. What it lacks is routing against siblings — it never says when to use this versus paperless_post_get_rsvps or cotlet_app_guide, or whether this guide is required before any browser call. Usage is implied rather than explicitly framed.

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