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

Far beyond what the annotations carry: it discloses that `text` appears on the lock screen and persists on the pass, that lat/long pairs cause the pass to resurface near a place, that the reply's `noticeId` names the meetup, that preview mode is the default and sends nothing, and the exact rate-limit ceiling with the error string returned when exceeded. Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) agree with the described dry-run/send split and the `requestId` single-send semantics.

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?

Front-loaded with the action and audience, then requirements, then the preview/send rule, then limits — a sensible order with no filler sentences. It is tightly compressed to the point of telegraphese ('Six an hour per event, shared with event_pass_notice, then RATE_LIMITED'), which is efficient but crams auth, geofencing, and error codes into single long sentences.

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 15-parameter write tool with no output schema, the description covers the essentials an agent would otherwise get wrong: permissions, the preview-by-default trap, the geo pair constraint, persistence of the message, and the failure modes. Remaining gaps are minor — the optional `at`, `tier`, `intent`, and `serials` selectors are left entirely to the schema, and the reply's shape is only partially characterized by `noticeId` plus the preview's pass count.

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?

Schema coverage is 100%, so 3 is the baseline; the description adds real semantics beyond it — the lock-screen/persistence behavior of `text`, the both-or-neither coupling of `latitude`/`longitude`, the role of `noticeId` in the reply, and the preview/send meaning of `confirm`. It stops short of explaining when `audience: my_booth` or `noticeId` (the earlier-notice parameter) should be chosen, though the schema's enum listing covers the audience values.

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 names the specific action (announce a meetup), the actor (event organizer or personal event host), and the recipient set (holders of the event's Wallet pass). That is a concrete verb+resource pair an agent can match against a user request without opening the schema.

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 decision rule for the most consequential branch: without `confirm` it returns the pass count and exact line and sends nothing, with `confirm: true` it sends. It also states preconditions (host/organizer only), rate limits, and the `my_booth` → VENDOR_OFF failure. What's missing is an explicit comparison to `event_pass_notice`, which is the nearest sibling and shares the rate-limit budget — the relationship is implied rather than routed.

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