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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is largely covered. The description adds genuinely useful context beyond that — that the tool performs no action itself and returns a procedure to be executed by the browser tools — but says nothing about what happens if the user has no events, no RSVPs, or is not authenticated.

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 point — where the data comes from and that the call returns instructions instead of acting — is front-loaded and the second sentence routes the agent to the right execution tools. The trailing 'Paperless Post's official API: Paperless Post has no public API' is awkwardly self-contradicting in phrasing and could be tightened, though the underlying fact (no public API, so browser automation is required) does justify the tool's existence.

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 output schema and zero parameters, the description carries the burden of explaining the return value, and it does so concretely ('screens, buttons, fields'). For a simple instruction-lookup tool this is nearly complete; only edge conditions (no events, missing login) are unaddressed.

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 there is no parameter meaning to convey and the baseline applies. The description correctly implies no inputs are needed by describing an argument-free retrieval of a procedure.

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 and resource ('Get RSVPs in the user's own Paperless Post account') and clarifies the actual deliverable is step-by-step instructions rather than a data fetch, which distinguishes it from execution tools like cotlet_browser_* or paperless_post_send_invitation. It stops short of explicitly contrasting with the other paperless_post_* siblings such as list_events.

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 states the workflow clearly: call this first to obtain the procedure, then perform it with cotlet_browser_* tools in the user's Cloud Browser, and notes it 'opens nothing by itself.' There is no explicit when-not guidance or named alternative among the paperless_post_* siblings, which keeps it from a 5.

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