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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the per-person payload (email and edit/view permission) and the auth requirement (Cotlet API key with access to this app). It omits pagination/result-limit behavior, which keeps it from a 5.

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?

Three short sentences, front-loaded with what is returned and followed by the actionable next step. There is mild redundancy between 'People with access to a presentation' and 'Returns each person with access to the deck,' but no wasted bulk.

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 single-parameter read tool with no output schema, the description covers what the agent needs: who is returned, what fields each entry has, and the auth requirement. It does not mention ordering, pagination, or empty-result behavior, but nothing critical to invoking the tool correctly is missing.

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% and the single parameter (presentation_id) is already documented as coming from list_presentations. The description adds nothing about the parameter's format or accepted values, so the baseline 3 applies.

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 identifies the resource precisely (people with access to a presentation, and whether they can edit or view) and the return contents (email + permission), so the agent can tell it apart from remove_collaborator and invite_collaborator. The verb 'list' lives only in the tool name/title, and the first sentence is a noun phrase that restates the same idea as the second, so it falls just short of a crisp verb+resource statement.

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 gives downstream guidance ('Use the email in remove_collaborator') and an access prerequisite, which implies the context in which the list is needed. However, it never states when to call this versus alternatives (e.g., invite_collaborator or create_share_link), so usage is inferred rather than explicit.

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