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

Annotations only supply readOnlyHint=false, so the description has to carry most of the load. It usefully discloses that an invitation is actually sent to the member and that the call is confirm-gated, but says nothing about what the preview returns, what happens if the member was already invited, or what permissions are needed.

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 verb+resource in the first clause, with the confirm-gate caveat immediately after. Slightly wasteful because the confirm-gating is already spelled out in the schema description for 'confirm', making the parenthetical redundant rather than additive.

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 mutating, externally-visible action (sending an invite email) with only a readOnlyHint annotation and no output schema, the description leaves key questions open: what the preview shows, error behavior for already-invited members, and the meaning of coachId. It is not sufficient to call the tool safely without guessing.

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 only 33%: only 'confirm' is documented in the schema, and the description adds nothing about it beyond repeating the gate. The two string parameters, memberId and coachId, are entirely unexplained in both schema and description, so the agent gets no guidance on whose id coachId should be or how to obtain a memberId.

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?

States a specific verb (invite) and a specific resource/scope (an already-imported gym member), plus the side effect (an invitation is sent). It is distinguishable from generic siblings like send_invitation or invite_gym_staff by the 'imported member' qualifier, though it never names an alternative tool.

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?

The 'imported member' qualifier implicitly scopes usage and the confirm gate tells the agent it runs as a preview first. But the description never states prerequisites (e.g. the import must be committed), exclusions, or which sibling to use for non-imported members or bulk invites.

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