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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. Beyond that the description adds meaningful behavioral context: identity binding, owner-only restriction, that inviteView 'grants no access', and that staff roles are excluded. It does not describe return shape or pagination limits, but for a read tool this is solid added value.

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 resource enumeration, and every subsequent sentence (owner-only, identity rule, staff exclusion, guide pointer) adds a distinct constraint. It is dense and run-on rather than cleanly structured, but little is wasted.

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, the description still covers actions, per-action inputs, permission boundaries, identity rules, and a workflow resource pointer. That is enough for an agent to select and invoke the right action, though return-value behavior remains undocumented.

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 only 50% and payload is a generic free-form object, so the description carries real weight. It annotates per-action parameters (cursor, reviewId, workspaceId, inviteId) and even enumerates review filter modes (view all/assigned_to_me), which the schema does not express. This compensates well for the thin schema.

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 ('Inspect') and enumerates the resources it exposes (workspaces, settings, members, reviewers, reviews, reviewDetail, reviewAssignments, inviteList, inviteView), matching the action enum almost one-for-one. It signals read scope via 'explicitly granted' and notes that all other email tools share the workspaceId, but it never explicitly names the closest sibling (inspect_email_workspace) or manage_email_team as the write counterpart.

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 real when/when-not conditions: inviteList is owner-only, inviteView requires the caller's verified Auth email to match, a workspace selector never overrides identity, and event staff roles do not grant access. It also points to a workflow guide resource. It stops short of explicitly routing the agent to alternatives for write operations.

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