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

Annotations already cover the safety profile (readOnly/idempotent/destructive=false), and the description adds substantial context beyond them: the visibility model for anonymous/non-members vs members, audience-based relaxation, that invited userId is withheld, that submissionCount appears only when canManage is true, the organization_not_found error, and the requiresAppActivation phone-login requirement. This is rich behavioral disclosure.

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?

Very information-dense with no filler, front-loading the visibility rules. It is telegraphic and run-on with arrows and abbreviations, which slightly impairs parseability, but virtually every clause carries distinct information.

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 complex, permission-sensitive list tool with no output schema, it covers visibility, field gating, an error case, an activation caveat, and workflow routing. It is nearly complete, though it does not describe the paginated return shape (nextCursor) beyond a passing reference.

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 description coverage is 100%, so q, limit, cursor, and organizationId are already documented in the schema. The description adds return-side semantics (submissionCount gating, items.slug) but no additional parameter-level meaning. Baseline 3 is appropriate.

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 name/title plus the visibility model make clear this lists activities belonging to one organization, and it explicitly distinguishes itself from list_my_activities (reserved for OWNER/ADMIN/EVENT_MANAGER handling). However, the description never states the core verb+resource in a clean sentence; it launches straight into permission rules, leaving purpose to be inferred from the name.

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 names explicit alternatives and the condition selecting them: organization OWNER/ADMIN/EVENT_MANAGER handling should use list_my_activities and bulk_review_signup_submissions, and it sketches the signup workflow (get_organization→items.slug→get_signup_activity→submit_signup). This is strong routing, but it does not plainly state the positive 'use this when you want to browse an org's public activities' case.

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